Help Center

Design system checklists – Vetting components and patterns

Michelle Chin

At face value, a button seems like a simple component. But then we must consider the different states – loading, disabled, active, hover, pressed. We realize we must think about what a button looks like next to other buttons or within the context of a screen full of buttons. Next thing you know, we’re trying to figure out what other buttons we might need beyond primary or secondary ones. Before we even arrive at answers, we remember that we need to consider mobile devices, responsiveness, accessibility, and localization. Suddenly a button isn’t simple anymore. 

To help you navigate all the considerations, we’ve created a checklist you can reference when vetting a component. This might look intimidating, but not all of these items apply to every component. Referencing the list will help you avoid costly mistakes if you forget something. After you go through the checklist with a few components, it’ll become second nature to you. 

How to use this checklist

There are a few ways you can use this resource. 

• If you’re designing a component, run through the checklist to ensure you’ve considered everything. It might help to create a Figma file that shows all your explorations. You can then use the file to present your component ideas and variations. People often like seeing what components look like in context and other options you’ve explored before deciding.
• Reviewing components, reference the checklist to ensure you haven’t forgotten anything.
• When testing components, use this checklist as a guide to confirm your components and patterns are working as designed.

Vetting a component checklist

1. Design variations – Are there variations…

• In size?
• In color?
• With states? (Think about default, active, disable, hover, loading, etc.)
• For confirmation of success, warning, error, or information?
• With or without visuals? (Think about icons, illustrations, images, etc.)
• For different themes? (e.g., light mode, dark mode)

UI scenarios – Answering these questions might be more common with complex components or patterns. What does it look like…

• By default?
• When it’s empty? (If different)
• When there aren’t any results (If different)
• When the system is thinking?
• When there are a few items?
• When there are several items? (Does it scroll? Are there hints to show there’s more? Is there pagination or continuous load?)
• When it scrolls? (Is it sticky? Does it float?)
• When there are errors? (Are there different kinds of errors?)
• Are there similar components? Is it clear how you might use this component instead of the others? (This helps when you need to document usage guidelines.)
• When confirming success, warning, error, or information?

Responsive design – What does the component, its variations, and scenarios look like…

• On desktop? (On Windows, macOS, or Linux?)
• On tablet? (If different)
• On mobile? (On native Android or iOS? On an Android or iOS web browser?)
• On other devices? (Such as SmartTVs, watches, smart home hubs, etc.)

Interaction – What does the functionality look like…

• When creating?
• When reading or displaying? (If not already addressed)
• When updating or editing? (If not already addressed)
• When deleting?

Accessibility – Try to make the component accessible from all relevant aspects. If this isn’t possible, make sure you have an alternative mechanism in place to ensure your product is accessible.

• Is there enough color contrast when comparing two colors?
• Is the element visually distinguishable in more than one way beyond just color?
• How would someone navigate this with only a keyboard? Or with only a mouse?
• What is the alt text for the element(s)?
• Can users comprehend what they’re interacting with?
• What ARIA attributes does the component need? You might need to work with your engineering team to figure this out.
• What labels do the elements have?
• Is the copy written in plain language? (Both for comprehension and translation.)
• Is their sound that needs to have a visual alternative?
• Are there animations, and how can users turn them off?

Localization – If you translate your app or site into different languages, it’s important to consider how the design system components adjust to text lengths, measurement units, and other culturally significant aspects.

• What does the component look like when there are longer or shorter text lengths? Is there a minimum or maximum width? When the component adjusts, does it poorly distort the UI?
• Based on the design, can the copy be converted to strings for grammatically correct translation? (You might need to work with a translator or engineer. The idea is not to insert UI elements in the middle of text strings because of how different languages place verbs and nouns in a sentence or how they have other adjustments for pluralizing items.)
• Do more extended lengths of text wrap or truncate? Do they truncate on the left, right, or middle if they truncate? When the component adjusts, does it poorly distort the UI?
• Do the font sizes need to be increased or decreased for different languages? (For example, increasing the font size for East Asian languages)
• How does the UI behave from left to right or right to left?
• For units of measurement, what does it look like for
• 12-hour or 24-hour time? Or UTC?
• Metric or imperial units?
• Currency?
• Number formatting?
• Phone number and address formats? (Do you have all the fields?)
• Are the images or icons you’ve used universally understood?
• Are colors appropriate and inoffensive?

Did we miss anything?

We’ll update this checklist as design systems evolve. Is there something you also include in your vetting process? Let us know on Twitter @zeroheight or on zheroes in our Slack community. You can also chat with other design system makers. Sign up here for free.