Case study 06 Cross-program, REI Systems
REI Design System
A component library built to win federal coding challenges.
- Client
- REI Systems
- Role
- Designer and author of the system
- Platform
- Figma, React and Storybook
- Status
- Version 1.0.1 · 111 documented frames
Summary
The something already built.
A federal coding challenge works like this. An agency describes a problem, competing teams get a short window, and what gets judged is a working prototype and the story told around it. There is no requirements document and no time to build one. Some windows are measured in hours.
You cannot design an interface from nothing inside that. So the firm either shows up with something already built, or it spends most of the window drawing buttons.
RDS is the something already built: a Figma library and matching React component library, covering foundations through full-page templates, so a proposal team starts assembling screens on day one instead of starting a design.
The interesting part is what it had to look like. Federal prototypes are expected to follow the U.S. Web Design System, and every competing team follows it too. The design problem was staying recognizably compliant while looking clearly better than the other bids on the table.
The problem
A shared standard can make every submission look the same.
The U.S. Web Design System is genuinely good. It is accessible by default, well documented, and tells a federal evaluator that a team understands the standards their agency has to meet. Not using it raises a question you do not want raised during an evaluation.
It also means that when four teams submit prototypes for the same challenge, all four look like the same prototype: same blue, same typeface, same spacing, same components in slightly different orders. Nothing is wrong with any of them, and nothing argues that this particular team is the one to hire.
The move that unlocked it was noticing that the federal system is two things wearing one name. It is a set of accessibility and interaction standards, and it is also a visual style. Those are separable. RDS kept the first entirely and replaced the second.
The sameness problem
Everyone bidding uses the same design system. That is the point, and it is the problem.
Four simplified federal prototype cards look nearly identical: the same navy header, pale content lines, and blue button. A callout explains that compliant submissions are indistinguishable, then two panels separate non-negotiable standards from replaceable visual style.
What the evaluators see across the submissions
Compliant, and indistinguishable
Stock components, stock blue, stock spacing. Nothing is wrong with any of it, and nothing about it argues that this team is the one to hire.
The move: treat it as two things wearing one name.
The U.S. Web Design System is a set of accessibility and interaction standards, and it is also a visual style. Those are separable. The standards are the part evaluators actually need, and they are not negotiable.
The standards
Contrast ratios, focus behavior, keyboard order, target sizes, semantic markup, form and error patterns, responsive behavior. Keep every one of these.
The style
Typeface, color, corner radius, elevation, density, proportion. None of this is a standard. All of it is what makes four submissions look like one submission.
The decision
Compliance is not a look. It survives a change of typeface.
Every decision went through the same test: would an evaluator, a screen reader user, or a keyboard-only user lose anything they are entitled to expect? If yes, it stays. If no, it is a default, and a default is something you are allowed to improve on.
Contrast, focus, keyboard order, target sizes, semantic markup, form patterns, inline validation and error summaries stayed. Typeface, color identity, density, proportion, elevation and corner treatment were redesigned.
What was kept and what was replaced
Compliance is not a look. It survives a change of typeface.
Eight decisions are listed as kept or replaced. Kept are color contrast, focus and keyboard order, target sizes and spacing rhythm, and semantics and form patterns. Replaced are typeface, color identity, density and proportion, and elevation and radius.
| Status | Decision | Reason |
|---|---|---|
| Kept | Color contrast | Every pairing meets WCAG 2.1 AA. The palette was rebuilt as ramps so a designer picks a step rather than guessing a hex value. |
| Kept | Focus and keyboard order | Visible focus on every interactive element, logical tab order, no keyboard traps. Rewriting this would have been both wrong and pointless. |
| Kept | Target sizes and spacing rhythm | Minimum target sizes preserved. The spacing scale was retained as a scale, with the values retuned. |
| Kept | Semantics and form patterns | Label placement, required-field marking, inline validation, error summaries. Patterns federal users have been trained on across every agency site. |
| Replaced | Typeface | The default federal typeface is functional and instantly recognisable as government. A different family on a proper type scale changes the register without touching legibility. |
| Replaced | Color identity | A deliberate accent range replaced the default blues, with full ramps for status and data. Still compliant, no longer anonymous. |
| Replaced | Density and proportion | Tighter vertical rhythm and a reconsidered container and grid model. The default reads as a public information site rather than a working tool. |
| Replaced | Elevation and radius | A defined elevation scale and consistent corner treatment make the system read as current rather than as five years old. |
The test that decided every row
Would an evaluator, a screen reader user, or a keyboard-only user lose anything they are entitled to expect? If yes, it stays. If no, it is a default, and defaults are there to be improved on.
The palette rebuild deserves a note. It is built as ramps, so a designer picks a step on a scale rather than guessing a hex value. When every step has known contrast behavior, passing becomes the default and failing takes effort.
The value
The library changes what the challenge hours get spent on.
Without one, a serious share of a short window goes to setting up a project, drawing primitives, and discovering accessibility and responsive problems late, when they are expensive. What is left over is the time for the thing that is actually being judged.
With one, configuration and theming are quick, screens get assembled from components that already work and are already accessible, and most of the window goes to understanding the agency’s problem and building the walkthrough that has to convince a room.
Why the system exists
A federal coding challenge does not give you time to design.
Two groups compare how a short coding challenge window is spent without and with the REI Design System. Without the library, setup and drawing primitives consume most of the time. With the library, configuration and assembly take less time while designing the actual solution and walkthrough take more.
Without a library
- Set up a project and pick a stack 12%
- Draw buttons, inputs, tables, navigation from scratch 34%
- Fight accessibility and responsive behavior late 18%
- Design the actual solution to the agency’s problem 24%
- Build the walkthrough that has to convince the room 12%
With the library
- Configure the library and theme it to the agency 6%
- Assemble screens from components that already work 12%
- Accessibility and responsive behavior already handled 4%
- Design the actual solution to the agency’s problem 48%
- Build the walkthrough that has to convince the room 30%
The library does not make the team faster. It changes what they spend the time on.
Nobody wins a challenge with a beautiful button. They win by understanding the agency’s problem better than the other bidders and showing it working.
Nobody has ever won a challenge with a beautiful button. They win by understanding the problem better than the other bidders and showing it working. Every hour spent redrawing a date picker is an hour not spent on that.
How it was built
A library only works if people can keep it alive.
The process started with the objective, research and benchmarking, then foundations and tokens. Components were built in Figma and React, exercised in Storybook, documented, taught through workshops, and given a route for maintenance and contribution.
The last two stages are the ones that get skipped. Building a library is the visible half. Training people to use it, keeping it current, and giving other designers a way to add to it determines whether it is still alive a year later or a folder somebody inherited.
How the system was built
Nine stages, from objectives to proposals.
Nine-stage process from defining the objective through research, foundations, component construction, development integration, documentation, rollout, maintenance, and proposal use. Each stage has an activity description and an output.
| Phase | What happened | Output |
|---|---|---|
| 01Define the objective | Simplify interface creation so the firm can produce consistent, high-quality work quickly across government and commercial projects. Reuse and scale as the point rather than a side effect. | Stated purpose and audience |
| 02Research and benchmark | Studied Material Design, Carbon and the federal system. Interviewed internal teams about workflow problems, then audited existing patterns and reusable code before rebuilding anything. | Benchmark findings and an inventory of existing patterns |
| 03Set the foundations | Three principles: consistency across projects, flexibility for varied client requirements, and accessibility at WCAG 2.1 AA as a floor. Then the visual identity and design tokens. | Principles, identity, and a token set |
| 04Build the component library | Built in Figma on atomic design. Buttons and inputs first, then modals, navigation and full patterns. Components were tested against screen readers and keyboard navigation as they were built. | Figma library, 111 documented frames |
| 05Integrate with development | Components written as reusable React code, with Storybook for isolated states, a shared repository, and pipelines to keep the code clean. | React component library and Storybook |
| 06Document it | A playbook covering usage, code standards and best practice for every element, with accessibility policies and checklists inside the workflow. | Usage playbook and accessibility checklists |
| 07Train and roll out | Workshops introduced the Figma library and showed teams how to work from it, with starter templates for common project types. | Workshops and starter templates |
| 08Maintain and grow | Feedback loops, scheduled updates, and a route for any internal team to propose a component or an improvement. Every frame carries an author, version and status. | Versioned components and a contribution route |
| 09Use it to win work | The system is evidence in proposals: reusable, accessible, proven, and the reason a working prototype can exist inside a challenge window. | A repeatable proposal asset |
Stages seven and eight are the ones people skip
Building the library is the visible half. Training people to use it, keeping it current, and giving other designers a way to add to it decides whether it is alive in a year or a folder somebody inherited.
The inventory
One hundred eleven frames, with enough metadata to trust them.
Foundations cover color ramps, design tokens, elevation, spacing, grids, breakpoints, type, iconography, logo rules, state layer colors and slot components. Components run from buttons through modals. Patterns and templates cover form layouts, registration, navigation and responsive frames.
The detail I would point at is not any individual component. It is the header on every frame: author, last updated, version and status. That is the difference between a library and a folder of drawings.
What is in the library
One hundred eleven documented frames.
Three inventory columns cover foundations with twelve areas, components with eighteen areas, and patterns and templates with six areas. A metadata strip lists author, last updated, version, and status on every frame.
Foundations
12 areas documented
- Color, built as ramps
- Design tokens
- Elevation scale
- Spacing scale
- Grid and containers
- Breakpoints
- Font family and weight
- Type scale
- Iconography and guidelines
- Logo usage
- State layer colors
- Slot components
Components
18 areas documented
- Buttons, all states
- Text inputs
- Password fields
- Select and dropdown
- Checkbox and radio
- Switch
- Sliders
- File input
- Chips and badges
- Avatars and avatar groups
- Alerts
- Tooltips
- Progress indicators
- Step indicators
- Dividers
- Tables
- Cards
- Modals
Patterns and templates
6 areas documented
- Form layouts
- Registration flow
- Page templates
- Navigation patterns
- Guide header, table and markup
- Desktop, tablet and mobile frames
The header that appears on every single frame
Why the metadata matters more than it looks
A designer picking up a component under deadline needs to know whether it is finished and whether anyone still owns it. Without that, every reuse starts with a question.
Design and code
A design system that only exists in Figma is a mood board with better naming.
The value appears when a designer’s choice and a developer’s import resolve to the same object. Tokens sit underneath everything. The Figma library is built on those tokens, React components are the same components in code, Storybook exercises them in isolation, and the shared repository means teams import rather than copy.
At the end of that chain is the thing it was built for: a proposal team assembling working screens on day one. After a win, the prototype is not thrown away because it is built from the same components the delivery team will use.
From token to prototype
The path a decision takes before it reaches a challenge.
Six connected stages show the RDS path from design tokens to Figma library, React components, Storybook, shared repository, and finally a challenge prototype. Two panels explain what the chain buys before and after a proposal win.
Design tokens
Color, spacing and type expressed as named values rather than repeated decisions. One place to change, everywhere updates.
Figma library
Atomic components built on those tokens, with naming and hierarchy planned so the library stays navigable as it grows.
React components
The same components as reusable code. A designer’s choice and a developer’s import resolve to the same thing.
Storybook
Every component exercised in isolation, including its states, behavior and visible focus before it lands in a page.
Shared repository
One import, versioned, with pipelines keeping it clean. Not a copy that drifts.
Challenge prototype
A proposal team assembles working screens on day one instead of drawing primitives.
What this buys a proposal
The prototype exists early enough to be tested, changed, and rehearsed. A team can show a working thing on day two instead of arguing from evidence while still arguing from slides.
And what it buys after the win
The prototype is not thrown away. It is built from the same components the delivery team will use, so the gap between what was promised and what gets built is smaller.
Outcomes
What the system produced.
- A Figma component library of 111 documented frames, versioned and status tracked, covering foundations through page templates
- A matching React component library with Storybook, in a shared repository
- A restyled implementation of the federal design standard that keeps its accessibility and interaction requirements and replaces its visual defaults
- Design tokens for color, spacing and typography, with the palette rebuilt as ramps so accessible pairings are the default
- A usage playbook with accessibility policies and checklists, workshops, and starter templates
- A reusable asset for proposals, used across the firm’s competitive challenge work
Attribution
A shared system with clear design ownership.
The design system was built for and used by teams across the firm. The React implementation, repository and pipelines involved engineering throughout.
What is mine: the research and benchmarking, principles and foundations, token set, visual identity, Figma component library, the decision about what to keep and replace from the federal standard, documentation and playbook, and the workshops that got it adopted.
Challenge wins belong to the teams that won them.
The system was never instrumented, so the benefit is described rather than measured.