5️⃣How to build components
Last updated
Last updated
Post the pilot exercise, it's time to construct and document the components we've recognized. But before releasing v1 of a component, we should think about how the component helps with existing uses and test in progress work with the teams to make sure it's a valuable addition to the design system.
For a design system component to be truly useful, it needs to support a range of use cases. Abstracting a components design enables that. However, it’s easy to over abstract a component.
Find existing use cases during the discover process and pilot exercise. Don't over optimise for future use cases.
When you're abstracting the design, keep in mind that a component must be useful for three or more teams/features. Don't deviate too far from the original samples to keep all components recognisable. Making them too different can create a mismatch with the rest of the interface not using the design system.
Before getting too far on your component design, share progress of your abstraction work with the pilot team that will eventually integrate it. Get a gut check from them about whether you’re headed in a direction that fits with what they’re doing.
There may be input from teams regarding changes and additions. However, consider these requests only if three or more teams currently need this component.
Remember that your job as the design system team is really to solve the common problems. The more the design system team tries to accommodate one-off problems, the less focus you can have on solving problems at scale. These one-off requests can be maintained as possible future iterations in separate doc.
Once you've abstracted a component and tested with pilot teams, it's time to detail it out. Cover the following:
Usage - A short description about the component.
Anatomy - Breakdown of all the elements and building blocks of the component.
Variants - Overview of all the configurations the component can have.
Behaviour - This section elaborates on all the interactive details useful for the team
Specs - Detailed breakdown of spacing and structuring of the component.
Accessibility - Details about how the component should support assistive technologies.
