How Building a Design System Backwards Worked
Weekend Bonus Issue: What began as a confusing pile of YAML and JSON turned out to be the smartest way to build a scalable, token-driven design system — even before the first mockup existed.
Hi there, and happy Saturday!
As a little make-good for not publishing a standard issue earlier this week, I’m sharing one from the archives — a piece that still feels as relevant today as when I first wrote it.
My regular publishing schedule resumes on Tuesday with a new essay: The Great Usability Recession.
And a fun update: I can finally share the project referenced below — the Fifth Third Bank mobile app, which went on to become JD Power’s #1 rated regional banking app. We developed it alongside the bank’s next-generation branch design, which gave us the opportunity to retroactively apply a unified omnichannel design language. This was only possible thanks to a robust design token architecture that emerged from our decision to “build the design system backwards.”
I’m still deeply grateful for having had this experience and for the incredible cross-functional team of geniuses I learned so much from along the way.
Starting at the End
A handful of years ago, I joined a Fortune 500 as a design leader, excited to work within an organization that had invested in a new design system. My first meeting with my design system designers was a review of YAML and JSON files. There was no style guide, no audit of existing components with inconsistencies called out, no mock-ups of any kind yet. Just… code. I put on my best stone face and thought: “Something is seriously off here; why are we talking development before aligning on common patterns and visual styling?” We had started at the end of the process, not at the beginning. In hindsight, starting with the end in mind was the best possible decision the team could’ve made despite my initial dismay.
What is a Design System, Really?
First, let me clarify what I mean by “design system” to set the stage. Here’s the Nielsen Norman Group’s definition, with my extension in italics:
A design system is a set of standards intended to manage design at scale, using reusable components and patterns while bridging designer and developer workflows to deliver rapid experience improvements.
Without tight integration into developer workflows, even the best design system is little more than a detailed digital style guide. While valuable for aligning designers and providing individual developers guidelines (think on the level of mock-up inspection tools in Figma), it does little to eliminate redundancy and inconsistencies in the built experience. Each designer is responsible for adhering to the guidelines, as is each developer — assuming clear front-end guidelines exist and are tied back to the system guidelines. There are several built-in points of failure. An ideal design system is architected across both design and development workflows to truly realize the value in the definition above: managing design at scale, from the initial pixel placed in design software to the delivered experience.
Introducing design tokens, and just a little existential dread
Design tokens are the great enablers of flexible, scalable design systems. Like a physical token, a design token is a stand-in representing a value. The ribbon of tickets won playing skeeball are similar; they represent a value set by the arcade and are meaningless outside that context. Suppose you want to have an existential crisis. In that case, money’s physical and mental constructs are also tokens — the value they represent fluctuates constantly based on external factors, but a $1 bill is always a $1 bill. Or, if you prefer a more designer-y simile: tokens are the sub-atomic particles in the Atomic Design model; the protons, electrons, and neutrons that build atoms or components. A button’s shape, color, and drop shadow can change, but it’s always a button.
Examples of the “sub-atomic particles” that design tokens can represent:
Color
Spacing
Stack order
Fonts — color, size, decoration
Shadows
Shape
…really, anything that makes up a designed element.
For your consideration: an absolute nightmare
Let’s say your company’s brand team one day decides to change the company’s primary colors to magenta and olive green. First off, I’m sorry. Second, ask yourself: how much work will it be to implement this change across every digital touchpoint in the customer’s journey? If lucky, the development teams thought ahead and architected web, mobile, and other (potentially in-store) applications to absorb this change seamlessly. In reality? There’s probably a lot of hard-coded styling in the ecosystem that requires a ton of manual effort. And that’s just color. The re-brand also requires a re-think of the entire visual layer over top of the core experience.
Sound like a nightmare? I lived it. Our brand color changed at the company mentioned above, which led to two different primary brand colors throughout our experiences. We also learned we had more than 50 shades of gray in one of our mobile applications alone through the audit spurred by the brand updates. There were dozens of other examples. We had inadvertently built a patchwork quilt of an experience far below the industry standard. The solution? Update the most critical screens and punt on the rest; we were re-platforming anyway.
Develop before design, but in a good way
It was too late for the existing codebase to make meaningful changes to eliminate all the inconsistencies built up over six years. Luckily, executive leadership had recently won buy-in from the Board of Directors to completely re-platform all consumer-facing experiences to more modern technologies. A window of opportunity opened: we integrated design tokens from the start of the re-build, affording maximum design flexibility and control in the built experience. Remember those YAML and JSON files I reviewed in my first weeks at the company? Those were the humble beginnings of the design token approach that powers the company’s new experiences today. Consider my initial perspective re-calibrated.
Enough tech talk, you say — what about the design in the design system? Here’s the other benefit of taking a tokenized approach: final decisions on design and related guidelines can be deferred until a new design language and associated guidelines are ready. Given the multitudes of stakeholders at the Fortune 500, approval of a new digital design language was a long, drawn-out process. We didn’t have all design decisions codified down to the token level when the re-build began, but that didn’t matter. When the new design language was finalized, a single developer, working alongside a designer, would be able to update design tokens and, like magic, change the look and feel of the total app experience in a matter of minutes, not weeks or months.
If you are trapped in a cycle of mock-ups not matching reality, I strongly suggest talking to your development partners about the power of design tokens. While my example above is extreme — not everyone will get the opportunity to re-architect an entire front-end ecosystem — there are many options to improve design-to-development workflows that can take advantage of tokenization. And if you’re starting fresh with a new product, there’s no reason not to build in tokens from the start and make them a core part of design and front-end development practices.