Component Checklist
Search the component library

Component Checklist

Go to checklist folder

Aug 15, 2019



Must keep in mind all Pearson products, not just one specific product

This requirement means you should consider what other products might also use a component and how that could change your design. It’s a best practice to engage other teams mock up the component in several different product contexts.

You should also consider the various audiences for a component (student, instructor). Where possible, a component should be designed to work for the broadest group of users, rather than specifically for one audience.



Should not duplicate the same functionality found in an existing component, either in whole or in part

New components should leverage existing work by declaring dependencies on useful components which are already in the library.


Must have a consistent visual style similar to other components

This requirement will be updated in the near future to specify that components must align with the rebranded visual aesthetic (currently in progress). Rebranded components will also need to support the Pearson Brand Accessibility Guidelines.


Must have minimal configuration options

This generally means you should not allow consumers of your component to customize the appearance, style, or behavior of the component. Only add options when different modes or configurable features are needed to meet the core purpose of the component.

For example, the header component has a few different modes which are needed to meet the use cases of a signed out user vs. a signed in user. This is appropriate configuration. On the other hand, options to change the color, font, or corner styles of a component are extraneous and will perpetuate a fractured and disjointed experience.


UX writer must review UI copy in images

Usable and Effective


Must go through user testing if complex

The necessary depth of user research increases with the scale, complexity, and novelty of a component. Atomic components such as simple buttons may only require internal documentation (including a UXD Accessibility Checklist). More complex components should be evaluated internally and externally through user feedback. Contact a User Experience Researcher if you have questions about the appropriateness of research for your component design.

A non-exhaustive list of resource includes: Open Labs, Learning Design Research, Student and Educator Advisory Boards, and dedicated UX Research. Also, don’t forget about the extensive collection of previous reports and findings.


Should reflect Learning Design Principles where applicable (e.g., content, assessment, etc.)


Developer must review design and documentation



Must comply with WCAG 2.0 AA standards

The Pearson Accessibility Guidelines are a company-wide implementation of the Web Content Accessibility Guidelines (WCAG) 2.0. WCAG 2.0 is a global product of the Worldwide Web Consortium that mandates specific accessibility minima and features for compliance at Levels A, AA, and AAA. The Pearson Accessibility Guidelines ensure Level AA compliance by providing a design and development framework of 42 guidelines specific to learner needs and Pearson products.

The UXD Accessibility Checklist specifies a subset of the 42 Pearson Accessibility Guidelines which must be addressed during the design phase. Not every item on the UXD Accessibility Checklist will apply to every design. However, each should be carefully considered and documented for clarity and to ensure the accessibility needs of the component are understood downstream.



Must function properly at each of the standard breakpoints defined by the UX Framework


Must ensure that all touch targets be at least 44 x 44 pixels in size

It may be difficult to implement this for inline links, which can typically be excepted from this requirement.



Documentation must include:

  • Description
  • Sketch file
  • Dependencies
  • Usage
  • Responsive behaviors (if applicable)
  • Redlines
  • Links to redlines and content
  • Changelog

Must reference any dependencies with links where they are used in the design


Must be added (except for the icons) to the UI Kit. The Sketch instances must match the specs in the documentation, and be crafted for easy adoption, resizing, and content overrides


Must include images and videos (if applicable) that load correctly and links that work



Should use the Component Archetype as a starting point for standalone components

The archetype implements best practices like testing, linting, bundling, transpiling ES6 to ES5, etc. It codifies a long list of decisions that you no longer have to make, saving you from wiring it all together into an automated development environment and build process.


Should be responsive

Responsive web design allows pages to format correctly on any size screen. An application must balance the rich functionality associated with desktop usage with the ability to function on less powerful mobile devices.

A responsive web design includes:

  • A flexible, grid-based layout. This allows the layout to reflow to any device's screen size.
  • A relative sizing of grids. This allows the grid layout to adjust to the viewport size.
  • Flexible images and media: This allows the images and videos to reflow with the layout.

Must function properly at each of the standard breakpoints defined in the Breakpoints component


Should not duplicate the functionality found in existing components

Reuse available components from the Elements SDK in the npm registry. Before you develop a new component, check the npm registry to see if a similar component already exists. If one already exists, then contact the appropriate team to discuss potential updates to the original component before you create your own component.

When creating a new component, please use existing subcomponents and elements. It's always best to reuse components whenever possible.


Must be accessible

All components must go through an accessibility review to ensure that minimum accessibility requirements are met as defined by the accessibility team.

Compatible with Pearson supported browser


Must support all optimized browsers

Optimized browsers are OS/browser combinations tested and certified by QA. These generally represent the newest versions of major OSs and browsers.


Must be tested for functionality on supported browsers

Supported combinations will no longer be tested and certified. Any issues with supported combinations will be addressed as S1 and S2 issues as they arise.



Must externalize all strings


Should display long strings correctly when they are localized


Should allow international currency


Should allow international dates and times

Meets Conventions


Must support UTF-8

Character encoding can cause problems, especially on sites that are predominantly in English with a few foreign characters here and there, where issues with character encoding can easily go unnoticed.

Ensure that your pages are UTF-8 encoded, using both an HTTP response header and an HTML meta tag: <meta charset="UTF-8" />. Place this as the first tag within the <head> section of the page, before <title>, since it’s important that the browser knows the right character set to use before it gets to any content.


Should use ES6

The ES6 or ES2015 syntax is recommended be used to create components. Presentational components must not call a backend service directly to get data. The architecture is designed for the components to be loosely coupled from the service to provide highly reusable front end components. The components would need data in a certain expected format. It is the responsibility of either the consuming application or a container component to fetch and aggregate data from a RESTful API.


Must must comply with the HTML5 specification



Must not collect data on unsecure pages

When prompting the user for personal data such as email address, username, password or payment information, always serve the page with the form on it using HTTPS, and send the form submission to an HTTPS URL.

It’s often considered OK to serve forms on unsecure pages as long as the form posts to a secure destination. This is not acceptable, because an attacker can modify the page that serves the form and change the form post destination.



Must include a README file with each implementation

A README file helps other teams to install and use the component. A README should include:

  • Introduction
  • Installation
  • Versions
  • User Guide
  • Implementation
  • Testing
  • Related Resources

Passes QA


Must have at least 80% code coverage


Must include automated tests and test scripts

Click the following link for the tools used for Automated testing and test scripts


Must include contributributions to the QA library for each component

How to contribute: You can fork the repo or create a branch out of master and make your changes, create a Pull Request for your changes to merge into the master branch. See how to contribute.