Library Membership Specification
Version 1.0.0
Every component listed in the Component Library must satisfy all the requirements contained in this document. To learn about submitting components for inclusion see the Component Creation Guide.
Requirements are divided into two sections, Design and Development. Your component definition will be approved based on the design requirements and the implementation is approved based on the development requirements.
U1: Components must reflect the needs of Pearson as a whole rather than just the needs of one 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.
C1: A component should not duplicate functionality found in an existing component, either in whole or in part.
New component should instead leverage existing work by declaring dependencies on useful components which are already in the library.
C2: A component must not duplicate functionality found in the following components: Buttons, Breakpoints, Colors, Icons, or Typography.
New components must leverage the existing functionality in these components by declaring them as dependencies, where needed.
C3: A component should reflect the current overall design aesthetic in use across the next gen products (e.g. Console, ILP, Pi, Exchange).
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.
C4: A component must be versioned according to the Component Versioning Specification.
C5: Components should keep configuration options to the minimum possible.
This generally means you should not allow consumers of your component to customize the appearance, style, or behavior or 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.
UE1: A component should be evaluated for usefulness, usability, and accessibility through feedback from users with the widest possible range of abilities.
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.
UE2: Where applicable, a component’s design should reflect the Learning Design Principles.
A1: Components must conform to the Pearson Accessibility Guidelines (PAG). Designers must provide a UXD Accessibility Checklist with each component that ensures that PAG has been considered during the design phase. This checklist also functions as fulfillment of PAG 42 - Documentation of Accessibility.
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.
R1: All components must function properly at each of the standard breakpoints defined in the Breakpoints component.
R2: All touch targets should be at least 44 x 44 pixels in size (minimum dimensions 36 x 36 pixels).
It may be difficult to implement this for inline links, which can typically be excepted from this requirement.
D1: A component must include a set of redlines that completely detail every aspect of the design and behavior.
D2: All features, configuration options, and usage guidelines for a component must be documented.
D3: Any changes in a new version of a component must be documented in a changelog.
D4: Any dependencies for a component must be listed and referenced at each place where they are used in the design.
D5: Each component must include a completed UXD Accessibility Checklist.
Initial version