A design system starts with a shared question

It is tempting to begin a design system with a tidy inventory: buttons, fields, colors and spacing. An inventory is useful, but it is not yet an agreement. Two teams can use the same component and still mean different things by it. The work starts earlier, with the questions a shared system should make easier to answer.

Name the decision before the pattern.

Take a familiar interaction: confirming a payment. One team may treat the confirmation as a receipt, another as a moment of reassurance, and another as the start of a support journey. A consistent button cannot resolve those different expectations. Before choosing its shape, discuss what a person needs to know, what has happened and what they can do next.

Write the decision in ordinary language. For example: after a successful action, show what changed and give a clear route back to the task. That sentence can guide a screen, a notification and a help article. It is easier to question than an abstract principle, and easier to reuse than a screenshot.

Build a small agreement that can travel.

A useful pattern includes its purpose, the situations it fits and the situations it does not. Add an example with real constraints: a long label, an interrupted connection, a keyboard user moving through the flow. These details reveal whether the agreement is practical or only attractive on a blank canvas.

Keep the first version small enough to change. A short explanation beside a working example is often more valuable than a large documentation site that no one can maintain. Ask the next team to use it in a real task, then watch where they hesitate or invent a new answer. Those moments are evidence about the system.

Let consistency earn its place.

Consistency should reduce the decisions people need to repeat. It should not erase a useful difference between products or force a team to hide a problem inside an approved component. When an exception appears, record the reason. Over time, those reasons become a map of the product rather than a list of rule breakers.

The library is the visible part. The more durable work is the conversation that lets people make a decision together. Start there, and the components have something clear to carry.