# 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. 

<figure><img src="/files/IIe3wUG9ANXQMhJK999K" alt=""><figcaption><p>Identifying use cases </p></figcaption></figure>

### Abstract what's common&#x20;

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.&#x20;

<figure><img src="/files/h1GxcZEyRNzxlMTsBM5V" alt=""><figcaption><p>Abstracting what's common</p></figcaption></figure>

### Iterate based on the team's input&#x20;

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.

<figure><img src="/files/QWmOBU0c7kjL77LV1Y8b" alt=""><figcaption></figcaption></figure>

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://university.obvious.in/product-design/design-system/how-to-build-components.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.