# How to build components ## 👋 Introduction 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. *** ## 1️⃣ Abstract component design 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. ### Identify existing use cases Find existing use cases during the discover process and pilot exercise. Don't over optimise for future use cases.

### Abstract what's common 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.

### Iterate based on the team's input 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**. {% hint style="info" %} 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. {% endhint %} *** ## 2️⃣ Detailing a component Once you've abstracted a component and tested with pilot teams, it's time to detail it out. Cover the following: 1. Usage - A short description about the component. 2. Anatomy - Breakdown of all the elements and building blocks of the component. 3. Variants - Overview of all the configurations the component can have. 4. Behaviour - This section elaborates on all the interactive details useful for the team 5. Specs - Detailed breakdown of spacing and structuring of the component. 6. Accessibility - Details about how the component should support assistive technologies.

***