Design system checklist examples

NHS digital service manual

https://service-manual.nhs.uk/community-and-contribution/contribution-criteria

Criteria	Description
Useful	You have evidence that the component or pattern would be useful for many NHS digital teams or services. Evidence could be screenshots or links to versions in different services.
Unique	We do not already have something similar in the service manual. If you're proposing that it replace an existing component or pattern, it should be better than the existing version.
Usable	You have tested it in user research and shown that it works with a representative sample of users, including people with disabilities. If there is not enough research yet to show that it's usable, it can still be published as "experimental". But it must be clearly based on relevant user research from other organisations and best practice, and meet the other criteria.
Consistent	It uses existing styles and components in the service manual where relevant. The guidance and any content in examples follow the content style guide. If there is code, it follows the NHS.UK frontend coding standards and is ready to merge into the NHS.UK frontend library.
Versatile	The implementation is versatile enough to be used in a range of different services. For example, a versatile date input component could be set up to ask for: a year only a month and year only a precise date any other combination The component or pattern has been tested and works with a range of browsers, assistive technologies and devices.
Clinically safe	You have asked for feedback from an appropriate clinician and have addressed any clinical safety issues they raised. The working group includes a clinician trained in clinical safety. We will ask them to approve the component or pattern from a clinical safety point of view.

Fem Design Systems

https://fem-design-systems.netlify.app/design-system-checklist

Before a component is considered complete, it must meet several design and development requirements:

Design Requirements

Criteria	Description
Accessibility	All users, regardless of circumstance, must be able to accomplish the same tasks within our product. Our designs must account for users with visual impairments and must ensure all facets are consumable.
Interaction	How should a component respond when a user interacts with it? Is there validation feedback that must occur? The interaction definition must be defined.
Context	How and where should this component be used? When should I use a link versus a tertiary button, for example?
Completion	Are all states, including neutral, hover, focus, and disabled, defined?
Content	What type of content does this component rely upon? Does it accurately embody the brand identity?
Customization	Are aspects of this component customizable? If so, how? For example, if my design system serves multiple products, the primary button might have a different background color for product A versus product B. We must define these customizable parameters.
Resolution	How does this component look on varying screen resolutions? How does the layout change?

Development Checklist

Criteria	Description
Accessibility	In addition to an accessible color palette, we must develop our components with semantic HTML elements in order to ensure compliance with assistive technologies. We also must account for keyboard navigation.
Responsiveness	Our components must respond to browser window resizing and varying screen resolutions.
Completion	Does this component account for all aspects of the design? Have we implemented a near pixel-perfect component?
Customization	Have we implemented all of the customizable aspects of this component?
Error Handling / Data Validation	How do our components respond when something breaks? Have we incorporated type checking with React Prop Types or TypeScript to ensure our parameters comply with expected data types?
Browser Compatibility	Do the technologies we use work across all supported browsers or must we include polyfills?