HASTE
A headless, tokenized design system and methodology for starting every client design system from the same place.
What HASTE was for
Every new client engagement at the agency started from zero. Designers reinvented foundations from scratch, or stitched together components borrowed from past projects and adapted them by hand. The output was inconsistent, the kickoffs were slow, and the same architectural problems were being solved over and over again by different people.
HASTE was scoped as an R&D initiative to change that. The goal wasn’t just a component library. It was a tokenized foundation, a documented methodology, and a workflow for igniting new client design systems from a shared starting point. The brief I owned was both to build the system and to make it adoptable.
The system
HASTE is a tokenized component and pattern library built in Figma with Tokens Studio. The token architecture covers color, typography, border radii, spacing, sizing, and line-height, structured in primitive and semantic layers from day one. Components and patterns cover the foundations of typical client engagements: buttons, forms, navigation, content layouts, and the structural elements that appear on most projects.
The library was architected to support web, mobile, and web-app projects through shared primitives. Coverage was deliberately partial. Most components were single-platform; a smaller subset had multi-platform variants. The architecture made room for the system to grow as new client work demanded it, rather than locking HASTE into web-only assumptions before that breadth was needed.
The pipeline ran tokens through Tokens Studio and Figma, exported to JSON, transformed through Style Dictionary, validated in Chromatic, and shipped through Storybook. The same operational shape every client engagement would inherit when they spun up a system on top of HASTE.
The methodology
The library was the smaller half of the deliverable. The bigger half was making sure HASTE could actually be used. Three artifacts carried that work.
The HASTE Handbook
A detailed reference that documented the architecture, naming conventions, token logic, and component usage. The handbook included video tutorials so anyone learning the system could see Tokens Studio in motion, not just read about it.
Workflow diagrams
Diagrams showed exactly how to ignite a new client design system based on HASTE. They covered the steps from forking the foundation to establishing client-specific tokens, plus troubleshooting paths for the situations teams ran into most often.
A training program for designers
Two-hour sessions every week for two months, working from a shared Tokens Studio repo, with hands-on practice on real component scenarios. Sessions were recorded so they could be referenced after the fact, and the same material was woven into the handbook for self-serve learning.
Together, the system and the methodology were designed to outlast any single person on the team. The handbook, the recorded sessions, and the workflow diagrams gave the agency a complete starting kit that could be picked up by new designers without requiring a live walkthrough.
The methodology also traveled outside the agency. I co-presented HASTE with the dev lead at a Storyblok webinar attended by around a hundred people, walking through the token pipeline live and showing how a tokenized foundation flows from Tokens Studio into Storybook in practice.
What I learned about adoption
Designing the system was the smaller half of the work. Getting it adopted was the harder half, and HASTE taught me that adoption is a tooling problem and a communication problem at the same time.
Tokens Studio has a learning curve, and under deadline pressure, people default to what they know. The training program was built around that: hands-on tooling practice and documentation written to be useful in the moment, not just as reference.
Designing the system was the smaller half of the work. Getting it adopted was the harder half.
Where the architecture had a cost
HASTE shipped as a fork-per-brand system. Each new client engagement forked the headless foundation and customized the token layers for that client. The architecture worked, but every engagement required the team to internalize the fork-and-retokenize flow, which made onboarding slower than it needed to be.
If I were starting HASTE today, I’d architect it around theming. The operational model is simpler: the foundation stays put and brand layers swap on top. That simplicity helps adoption, but only if the team commits to the tooling it requires. Without that buy-in, the abstraction adds complexity without delivering the benefit.
Used on projects including the Australian Federal Police and Relate. The system, the handbook, the recorded training, and the workflow diagrams remained as the agency’s starting kit when I transitioned out. Day-to-day stewardship moved to the team.
Working on Relate as an interaction designer, I experienced HASTE from the consumer side: the foundation made room for brand-specific components rather than basic ones, which is exactly the value the system was designed to deliver.
What HASTE taught me about systems work
Documentation is part of the system, not something you write around it. The HASTE Handbook and the workflow diagrams weren’t supplementary materials. They were what made the system usable by someone who wasn’t me. Without them, the architecture lives in one person’s head and stops there. I now scope documentation as a deliverable alongside the system work.
The other thing HASTE made clear is that adoption is its own design challenge. A system the team can’t confidently use is just overhead. Getting there means choosing the right operational model, pacing the training, and writing documentation people actually want to open. That work isn’t separate from building the system. It’s part of it.