Storybook · Demonstration scenario
Design System Operations: From Request to Release
One request, followed until it becomes a governed pattern: a decision about what the system should own, a live component with its states, and a release note a team could check against. The scenario is fictional. The component is real, and it lives in my Storybook.
A self-initiated demonstration using fictional sample data. The team, the request and the people in it are invented, and nothing on this page describes how an existing company operates.
Open Approval Task in StorybookThe request
A fictional field-service team asks for an approval screen. Technicians request parts for a work order, and someone has to approve or reject each request before the part ships.
The obvious answer is one more screen. In this scenario that isn't enough: the same decision happens at a desk, on site and on a phone between jobs, and each surface was about to get its own version.
- Who decides
- A supervisor, within a personal approval limit.
- The task
- Approve or reject one parts request, with a reason when rejecting.
- Where
- At a desk reviewing a queue, on a tablet on site, on a phone between jobs.
- The constraint
- The decision has to be unmistakable on every surface, including when this person isn't allowed to make it.
- States
- Pending, approved, rejected, blocked by permission, error.
- The exception
- A request above the supervisor's limit. They can see it; they can't approve it.
What the system owns, and what it doesn't
Before drawing anything, the question is what belongs in the system and what stays in the product.
Reused
Button and Spinner from the site's own components, the semantic color and type tokens, and an existing rule: state is told apart by wording and icon, never by color alone.
Adapted
Actions grow to 44px on tablet and phone. Rejected uses a neutral tone, because it is a decision, not a failure, so red stays reserved for the one state where something actually broke.
Not a component
The queue, its filters and its sorting stay product code. They change with each team's workflow; freezing them into the system would create the drift it exists to prevent.
No new warning color. The system deliberately has none: pending and blocked are carried by wording and an icon.
Out of scope: delegation, multi-step approval chains and partial approval. The pattern covers one person deciding one request.
The component, live
This is the same component the Storybook entry documents, rendered here, not a picture of it. Switch states to see what changes and what doesn't.
Approval Task
One parts request, in the tablet variant. Approve and Reject work; so does Try again.
components/demos/approval-task.tsx → ApprovalTaskRQ-0142
- Item
- Pump seal kit × 2
- Work order
- WO-381
- Requested by
- Field technician
- Note
- Seal failed during a routine inspection.
Try it
Only the actions change shape between states. The summary never moves, so the person never loses track of the request they're deciding on.
Anatomy
- 1. Request summary
- 2. Status (badge, icon and text)
- 3. Context line
- 4. Actions
Semantic tokens only: text, surface, border, success and danger. No raw color values.
Three surfaces, three jobs
The answer isn't one layout scaled down. Each surface keeps the task that matters most there and drops what doesn't.
Desktop · Row
Review in volume.
A dense row inside a queue: summary, status and inline actions on one line, so a reviewer can move through many requests without opening each one. Blocked requests stay in the queue with their reason visible instead of disappearing.
Queue — product code, not part of the component
- Sample data
RQ-0142 · Pump seal kit × 2
Requested by Field technician · WO-381
Awaiting your decision - Sample data
RQ-0139 · Compressor valve
This request is above your approval limit. A regional manager can approve it.
Needs a regional manager - Request approved.Sample data
RQ-0136 · Filter cartridge × 4
Approved by you · sample time
Approved
iPad · Detail
Stay on the task.
On site, the request opens beside the list with its full context (work order, requester, note) and 44px actions. In this scenario, an interruption doesn't lose the open request.
- RQ-0142 · Pump seal kit × 2
- RQ-0139 · Compressor valve
- RQ-0136 · Filter cartridge × 4
RQ-0142
- Item
- Pump seal kit × 2
- Work order
- WO-381
- Requested by
- Field technician
- Note
- Seal failed during a routine inspection.
Phone · Focus
Decide one thing.
One request, status first, actions stacked full-width at the bottom. No queue and no table: between jobs, the only job is to decide the request in front of you, or to learn who can.
This request is above your approval limit. A regional manager can approve it.
Pump seal kit × 2
RQ-0142 · WO-381
All three are one component with three variants, chosen for the task, not by screen width alone.
The contract lives in Storybook
The Storybook entry is the versioned contract: what an engineer builds against, and what a reviewer checks a change against. It holds:
- The live component, with every state and variant behind Controls.
- The real source file in the Code tab, not a snippet written for the docs.
- Props, states, variants and responsive behavior, written down.
- Accessibility: how each state is announced, focus order, 44px targets, and contrast measured on the surface the component sits on.
- When to use it, when not to, and what is deliberately out of scope.
This Storybook is my own. It shows how I document and version a component; it is not code shipped for any team I have worked with. In those engagements, Engineering implements.
Release, and how a team would know it worked
Approval Task — demonstration release, 14 October 2026
- Added
- One component, three variants (row, detail, focus), five states.
- Decided
- Rejected is neutral, not red. Blocked replaces the actions with who can act; there is no disabled Approve button. No warning color.
- Not included
- Delegation, multi-step approvals, partial approval.
- Before use
- Design checks wording and states; Engineering checks props, focus order and announcements.
The component and its Storybook entry are real and dated. Everything below is hypothetical: the checks I would set up with a team.
Adoption — what I would look for
- New approval flows import the shared component instead of building a local one.
- Blocked requests explain who can act, in the system's wording.
- Rejections arrive with a reason.
Drift — what I would watch for
- A yellow or orange “pending” badge appears, a color the system doesn't have.
- A disabled Approve button replaces the blocked explanation.
- Rejected turns red and can no longer be told apart from an error.
- The phone version brings back the full queue.
None of these are measured results. They are the checks I would agree on with a team before calling a change adopted.
The states no component library ships:Read the full article on Medium
I write about these decisions in more depth.Design system as code, fixed scope:Check the price on Contra