Starting a Design System? Talk to a Developer Friend First

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 stoneface 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.

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:

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 InVision and 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, was 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. 

For a far better explanation of design tokens and the power they afford design and product teams, I suggest checking out the below explainer video by Jina Anne. She also covers why we don’t simply refer to design tokens as “variables.” If you're unfamiliar, Jina Anne is the mind behind design tokenization and was instrumental in creating the Salesforce Lightning Design System, widely considered the original and golden standard for design systems to this day.

What experiences have you had implementing design systems? What are your gotchas and successes? Have you worked with your software engineering peers to tokenize the experiences you and/or your teams design? Leave a comment below or tweet at me @justindelabar. Would love to hear from you!