What is it?
Industry analysis, best practice and accessibility review.
Why do we do it?
To gain a more substantial perspective of how we can improve on what we have by looking at the outside world.
How do we do it?
Where to research
- Industry standards and best practices
- Accessibility considerations
- Other Design Systems and component guides
- Competitors to your product
- Inspirational sites for ideas
- Tech, design, UX articles and books
What to research
Basic standards of how the component is designed and its different variations and states.
Consider and outline the different contexts for the design examples you find and consider their relevance to your use cases.
Where is this component going to be used in the experience?
Are there single or multiple types/variants for this component? If so, do they have different use cases or contexts?
Is there a particular placement for this component?
Is there another component that performs a similar function to the one you’re making? If so, what are the rules around when to use what, and which case best suits the problem you’re trying to solve? This is important to get right up front. Otherwise, teams will use different components in the same use case, creating a disjointed experience.
Example Tabs and Segmented Control The lines between these two components can quickly become blurred without the proper guidance.
Tabbed interfaces are a way of navigating between multiple panels, reducing clutter and fitting more into a smaller space.
A hybrid somewhere between a button group, radio buttons, and tabs; segmented controls are used to switch between different options or views.
Interaction and animation
Consider what kind of interactions are available for the different states of this component. Are there any other additional features you need to accommodate when designing?
What are the different options for animation on this component? Does it require any?
Accessibility isn’t just adhering to WCAGs colour contrast guidelines. It’s understanding how to design components for everyone best. Each component will be different, so reviewing each as you go is best.
For example, the text input component, which has a fundamental accessibility consideration, is often overlooked —
Placeholders are problematic
Tone of voice
How have others considered tone of voice in this particular component?
Does the micro-copy on this component need to be straight to the point, or can you inject more of your brand into it?
Example error messages
Avoid using a cheerful tone of voice on an error message. The goal is to be as straightforward as possible so the user can reach their end goal without getting frustrated with your content.
How have others considered guidance of this component? What areas are heavily highlighted that might indicate Design System users require more support or information? What can you learn from other guidance sites for this component?
- A deeper understanding of accessibility for the specific component.
- Ideas for naming conventions.
- A collection of best practice examples and visuals to help structure the design phase.
- Research to support design decisions