Turning repeated states into reusable product patterns
Teams should promote a component into the design system when they keep solving the same product decision and the underlying rules have stabilised.
I developed this review from repeated platform work across Kolibri: status patterns, side panels, forms, accessibility, localisation and Arabic RTL. It helps teams move from one-off screens to patterns with clear states, content rules and implementation boundaries.
Start with the repeated decision
Visual similarity is only the first signal. A reusable pattern needs a stable product decision underneath it: the same user question, state lifecycle, permission boundary or recovery rule appearing across several parts of the product.
| Signal | Question to answer | Promotion response |
|---|---|---|
| The screens look alike | Do they help the user make the same decision? | Keep them local until the shared behaviour and meaning are clear. |
| The same decision repeats | Are teams solving the same question with different language or controls? | Document the common decision and the legitimate variants. |
| The same state lifecycle repeats | Do empty, loading, partial, error and success states follow the same rules? | Promote the state model together with the visual treatment. |
| Permissions change the answer | Which roles can see, start, edit, approve or recover the action? | Make permission behaviour part of the pattern contract. |
| Accessibility or localisation keeps drifting | Are focus, reading order, labels, long text or RTL behaviour being solved repeatedly? | Standardise the behaviour and test it as part of the pattern. |
| The answer is still experimental | Has the team used it enough to understand the exceptions? | Keep it in the product until the decision has stabilised. |
Write the pattern contract
The component file is only one part of a reusable answer. The pattern contract explains when to use it, what states it supports, what content it needs and where teams may vary it.
- Purpose: the user decision or product problem the pattern resolves.
- Entry and exit conditions: when the pattern begins and what counts as completion.
- State model: empty, loading, partial, error, success and interrupted states.
- Roles and permissions: who can see, start, edit, approve, retry or recover.
- Content rules: labels, status language, helper text, errors and confirmation.
- Accessibility: focus order, keyboard behaviour, announcements and contrast.
- Localisation: long text, mixed-language content and Arabic RTL behaviour.
- Responsive behaviour: what changes when space, input method or device changes.
- Implementation ownership: who maintains the pattern and reviews exceptions.
Separate component, pattern and workflow
Teams create brittle systems when one component is expected to own an entire workflow. Keep the layers explicit so each one can change at the right speed.
| Layer | What it owns | Example |
|---|---|---|
| Component | Rendering, interaction mechanics and accessible behaviour. | Button, field, progress indicator, alert or side panel. |
| Pattern | A recurring product decision, its states and the rules around use. | Destructive confirmation, interrupted transfer, bulk action or approval state. |
| Workflow | The sequence of decisions, handoffs, permissions and recovery across a task. | Importing a channel, settling a payment or approving a user change. |
Use the worksheet
The worksheet records the repeated decision, where it appears, shared states, permission rules, content, accessibility, localisation, responsive behaviour and implementation owner. Use it before promoting a product-specific solution into the design system.
A useful design system carries product decisions teams should not have to rediscover screen by screen. Pixel reuse is only the implementation layer.