Judge a design system in the actual flow
Component counts reveal little about usefulness. An order button shows which states need shared rules and which belong to the product.
Judge a design system by whether its building blocks reliably support recurring tasks. The number of drawn components is a weak measure. A single order button already shows how much lies between an attractive view and useful behaviour.
This example is fictional. A customer portal receives a carefully designed “Send order” button. Spacing, colour and typography are right. The design considers the component finished. What happens after a request is triggered remains undecided.
One appearance cannot cover different outcomes
Situation in the example | What the interface must communicate |
|---|---|
Request is processing | The operation is running; repeated activation is handled appropriately for the flow. |
Server confirms the order | Order reference B-42 and its confirmed status are shown. |
Server rejects an invalid quantity | The quantity remains visible and can be corrected understandably. |
Connection breaks after submission | The outcome is uncertain; the order status needs checking. |
A red button does not explain the final situation. The order may already exist. Equally, a green tick without a confirmed response does not establish success. This concerns correct information as well as visual design.
Connect shared behaviour with product rules
The component can provide visible focus, room for longer labels and a processing presentation. The ordering flow must know which quantities are valid and how to resolve an uncertain server outcome. A generic button cannot solve those rules.
The WAI-ARIA guide explains a similar relationship: a role communicates expected meaning but does not implement keyboard interaction. Shared design values, such as a named text colour stored as a design token, likewise replace neither behaviour nor the connection between design and code.
A disabled button is not the right response to every error state either. GOV.UK points out potential comprehension problems. If an action is blocked, the person needs an understandable explanation and a reachable next step.
The required depth depends on use
A static information page needs no order status. A purely presentational logo needs no state machine for server requests. Forcing identical variants onto every component would create unnecessary maintenance.
Conversely, an existing, tested component library may already cover these needs well. Appropriate integration can then make more sense than rebuilding it. The assessment would change if actual flows demonstrably cannot be represented understandably with the available components.
Accept a recurring flow in the implemented interface, including errors and longer translations. In this example, the component is usefully integrated only when a person with an uncertain order outcome also knows what to do next. Preventing duplicate orders additionally requires suitable server rules; disabling a button alone is insufficient.
Sources
Read more
All articles
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.