Most design system articles describe what to add. This one describes what to subtract. I maintain a design system for a one-person creative-tech practice, and I built a similar system last year for a DTC client's internal brand team. Both converged on the same shape: five layers, fewer than eighty tokens, and a single source of truth that mirrors out to Figma rather than the other way around. These are the field notes across three weeks of keeping it honest.
- Tokens78 tokensColor, type, spacing, radius, motion, shadow
- Typography8 tokensThree families, three display, three body
- Components14 tokensDocs via production pages, no Storybook
- Motion5 tokensThree durations, two easings
- Voice1 tokenOne markdown file in the repo
- GridmergedLives inside tokens as spacing scale
- IconographymergedTwo rules, live in the component using them
- IllustrationcutHandled per-engagement, not systematized
- UsagecutREADME next to each component, not a separate layer
2026-03-22: the nine layers I cut to five
A conventional agency design system spec has nine or ten layers. Color, typography, spacing, grid, motion, iconography, illustration, voice, components, usage. I cut mine to five: tokens, typography, components, motion, voice.
The cuts are not ideological. They are operational. At one-designer scale, every layer has a maintenance cost that shows up whether you ship artifacts from it that week or not. If I am not publishing new illustrations this quarter, the illustration guidelines layer is rot by the end of it. The layers that survive are the ones I touch every week.
Tokens stayed because everything else depends on them. Typography stayed because type is half of brand recognition on a text-heavy site. Components stayed because I would otherwise rebuild the same section three times. Motion stayed because unprincipled animation is the fastest way to break a brand. Voice stayed because it takes as long to write a paragraph as to design a page, and the output quality is the same kind of work.
What I cut was not "missing." It just did not earn its own page in the system. Grid is described inside the token layer. Iconography has two rules (weight and size) that live in the component pattern that uses them. Illustration is handled per-engagement without a systematized rulebook.
2026-03-25: the tokens that survived
Under eighty tokens total, across six categories.
Twelve color tokens. Four brand hues, four ink-on-paper neutrals, four state colors (success, warn, error, info). That is not enough range for a sprawling marketing site with ten subpages; it is exactly enough for one brand with an opinion. I know because I have tried larger palettes. They read as less confident, not more.
Eight type tokens. Three display sizes and three body sizes, plus mono and serif. Three font families. The scale is one-off, not a modular typographic ratio. I tried a 1.25 ratio for six months and cut it because the intermediate sizes never justified themselves on real pages.
Seven spacing tokens on a 4px base. Four radius tokens. Three motion durations and two easings. Three shadow tokens. That's the kit.
The naming convention stays plain. --signal, --pink, --ink, --paper for brand colors. Scale tokens for the rest. Nothing is named "primary" or "secondary" because there is only one designer deciding what is primary, and that designer does not need a hierarchy lookup to remember which color is the brand.
2026-03-28: component coverage without a component library
Fourteen components with documented usage. A header, a footer, a card, three button variants, a table, a callout, a quote, a reveal heading, a ticker, a terminal window, a form layout, a pricing tile. That covers roughly ninety percent of what the practice ships.
No Storybook. No Figma component variants. A README that lists each component name, a one-paragraph description, a link to the React file, and a link to the production page where it lives in the wild. When I need the card component, I open the README, click through to a real page using it, and copy the pattern. The production code is the documentation.
I tried a Storybook instance for six weeks last year. Maintaining it required more time than linking to the live page. The only advantage Storybook had was isolated stress-testing, which I get more cleanly by just opening the component file and writing a quick test page. Cut.
2026-04-02: the hub app that made it real
For a DTC healthcare client, I built the internal brand asset hub I shipped last year to solve the same problem at a five-person-team scale. The marketing team was running brand requests across email, shared drives, and a print vendor portal. Tokens drifted between the Figma file, the website, and the PDFs.
The fix was a single source of truth. CSS tokens in a tracked file. The Figma variables were a mirror of that file, not a parallel universe. The PDF generator pulled the same tokens. The team could not accidentally drift because there was only one place to change the truth.
That engagement is the real test case for this article's thesis. Five layers work at solo scale because they work at small-team scale for the same reason: the cost of an extra layer is maintenance, and maintenance is the first thing that breaks when work volume spikes.
“Five layers work at solo scale because they work at small-team scale for the same reason. The cost of an extra layer is maintenance.
”
2026-04-09: the tools I tried and cut
Style Dictionary for token transformation. I used it for a quarter. It is a serious tool for teams that ship tokens to iOS, Android, web, and print in different formats. I ship to one format. CSS custom properties plus a handful of Tailwind theme overrides covers it. Cut.
Figma variables as the source of truth. I tried this first, before I knew better. The problem is that code is the actual surface; Figma is a preview. Every token I changed in Figma, I also had to change in code, which meant the Figma file drifted every time I shipped a CSS change. Reversed it. The CSS tokens are authoritative; Figma imports them via a small script I run quarterly. That flow is one-way and has not drifted in a year.
A dedicated design system tool (one of the commercial ones at $30 per month). The pitch is managed tokens with versioning and approval workflows. I am one designer. I do not need an approval workflow. Cut.
A brand voice system documented in a shared doc instead of in the code base. I moved the voice guidelines into the repo as a plain markdown file. Writers who work with me read it at the start of each engagement. Documentation next to code gets updated; documentation in a shared drive rots.
Net effect of cutting: about $40 per month saved, a lot of meta-work eliminated, and one source of truth across everything that ships.
What the week taught me
Three observations that have held across iterations.
The first is that small systems work because they match the shipping cadence. If I ship three pages this month, my design system updates three times. A nine-layer system updates three times in the three layers that got used and stays frozen in the other six. Those frozen layers are the ones that lie.
The second is that tokens are cheap and layers are expensive. Adding a token is a one-line diff. Adding a layer means authoring it, maintaining it, enforcing it, and deciding when to retire it. A hundred tokens across five layers is less work than fifty tokens across nine.
The third is that Figma mirroring, not Figma sourcing, keeps you sane. Code is the thing the reader sees. Figma is a place to draw the thing the reader will see. If Figma is the source of truth, every shipped change requires a sync step that will eventually fail. Code as source of truth inverts that: Figma is allowed to drift, and a quarterly import pulls it back.
How I keep it honest
One pass per quarter. Every layer answers the same question: did you earn your maintenance cost this month? If I did not open the file, the layer is either unused or the docs are rotting. Either way it is a signal.
Every token answers the same question: did you appear in a production file this month? If not, it is on probation for the next quarter. A second quarter of no-shows and the token gets cut. Anything I cut and later need, I can add back with a specific production use case.
The pattern-catch rule. If I build the same section twice, it is a component. If I build the same color pairing twice, it is a token. If I write the same sentence twice, it is a voice rule. The design system accretes from the work, not from a Figma file I maintain in parallel.
All of this is a subset of the broader pattern I documented in the hybrid-operator playbook I catalogued. Solo operators carrying more context per unit of time than the role was priced for. The design system is one of the surfaces where that concentration shows up, and the weekly cadence that keeps it honest is described in the weekly shipping cadence for solo creative ops.
Frequently asked questions
Is this approach appropriate for a team larger than one?
Up to about five people, the structure translates directly. Past that, you need stronger enforcement (linting, design review, token automation) because the number of decisions made per day exceeds what one head can audit. The brand asset hub engagement I described ran this structure for a marketing team of five. It held, but only because the code base was the enforcement layer. Without code-level enforcement, larger teams will silently diverge.
How do you handle designers who work in Figma first?
You do not force them out of Figma. You ask them to treat Figma as a sketch surface and code as the final surface. When they finish a concept, someone (them or me) translates the values into the token file. If the value they picked is not in the token set, we either pick an existing token that is close enough or we add a new token with a specific production use case. Figma drift is fine as long as it is one-way and periodic.
What about accessibility and contrast tokens?
Four of the twelve color tokens are state colors (success, warn, error, info) and each is paired with an ink-on-paper contrast partner in the token file. Contrast ratios are documented next to the color. A designer picking a color never has to compute a ratio; they pick the token pair that is marked compliant. The token layer carries the accessibility constraint so the component layer does not have to.
How long did it take to get to this system from a larger one?
About eighteen months of iterative trimming. I started with the conventional nine-layer approach that an agency-trained designer defaults to. Every quarter I cut one layer or rewrote one that was not holding. The current five-layer shape stabilized in Q4 2025 and has not changed in the two quarters since. Stabilization took longer than the initial draft; most of the work was unlearning that bigger systems are better.
Does this approach work with a tool like Tailwind?
Yes. Tailwind's theme file becomes a consumer of the token file rather than the source. I set the CSS custom properties in globals.css and reference them from the Tailwind theme via the theme.extend block. That way Tailwind utilities and raw CSS both read from the same token truth, and I only update the token once to see it propagate.
Sources and specifics
- The five-layer structure (tokens, typography, components, motion, voice) is what stabilized on my own practice after about 18 months of iterative trimming through 2024 and 2025.
- Token count is approximately 78 across color (12), type (8), spacing (7), radius (4), motion (5), shadow (3), and a handful of utility tokens as of April 2026.
- The small-team validation is from the internal brand asset hub I shipped last year, where the same structure served a marketing team of approximately five at a DTC healthcare client.
- Tools tried and cut include Style Dictionary, Figma-as-source-of-truth, a commercial design system tool around $30 per month, and a Storybook instance maintained for six weeks. Net savings roughly $40 per month, documented alongside the tooling line items I keep honest every quarter.
- The productized version of this methodology is the Operator's Stack methodology.