When creating a physical structure like a building, a foundation is pretty dang important, for lots of reasons. Most importantly, in the words of This Old House, the foundation “should last forever.”
It’s way less important when making a digital product.
In fact, there’s a good argument to be made that many software development practices exist to decouple reliance on as many “forever” pieces as possible. Merging capabilities in version control systems allow us to edit, remove, or augment any part of the product at any time without damaging the rest of the codebase. Removing the first line of code ever written in any given piece of software is only ever one pull request away. Digital products are our modern day ships of Theseus.
I’m not entirely sure where the idea that the first step in creating a good digital product starts by establishing “foundations” like color and typography came from. Perhaps it’s a relic of the waterfall methodology that implies that creating digital products is a series of dependencies that build upon each other.
The danger of thinking about anything in a digital product as a “foundation” is that it implies you must focus on this thing first, that everything else needs to be built on this supporting structure.
Lest we get too pedantic here, I’m talking as much about the idea of “foundations” as the specific word. The logic still applies whether you call them “foundations,” “base,” “core,” “fundamentals,” or any other synonym.
Whatever the reason, our sample size of prospective clients and customers suggest this is a legitimately preconceived notion. One of the most frequent questions we got when we launched our Design System in 90 Days workbook is about the lack of content about establishing color, typography, and spacing guidelines, referred to by most of the people asking as “foundations.” The main reason it’s not in the workbook is because we think there are at least 52 more important things to focus on in the first 90 days. Blasphemy, I know!
Many of our prospective client inquiries contain stories like this:
We’re honing in on our initial design language and some of our basic components, but we haven’t gotten much further than that. We’ve been chipping away at it for a while but we just can’t ever seem to make the progress we want to make. We’re planning an offsite for our design team soon to finish laying the foundations. Once we’re through that, can you help us with establishing our contribution and governance models?
In my experience, this “if you build it, they will come” mindset is the largest contributor to what ends up as a design system graveyard.
At it’s simplest, it’s inaccurate and impractical. Humans are awful at accurate predictions. Have you ever tried to design a screen by first picking a color palette and a typeface and then creating the screen? Inevitably, you have to change it once you’re actually applying those choices to a particular context. That it changes disqualifies it as a “foundation.” (More on this idea below.)
If not working on “foundations,” what, then, should the first step be? There are two ends of a spectrum that suggest different starting points:
Start by identifying existing useful patterns in your current sites and applications. The chances that a brand team or product team have already picked a brand typeface are pretty high, which is how it should be. It’s the brand team’s job to establish brand standards. It’s the design system team’s job to help make those standards easy to implement in user interfaces. A design system is a system for creating interfaces that needs to work in conjunction with other organizational systems.
Creating a design system first for a new company is premature optimization.
Sure, you need a typeface and a color palette to create your first MVP. But pick quickly. Spend 30 minutes on this decision, not 30 days.
I’ll pick for you. Pick a color palette from Adobe Color. Use Helvetica. Don’t like Helvetica? Use Inter. Don’ like Inter? Use Roboto. Don’t like Roboto? You’ve already spent more time on this decision than is valuable for your startup. Any time not spent on pursuing product-market-fit is probably a waste of time at this point.
Over the last decade, I have yet to find an article that better describes the product creation narrative better than Michael Lopp’s “Stables and Volatiles:”
The birth of a successful 1.0 is a war with convention and common sense. It is built around a handful of Volatiles who believe that “We can bring this new thing into the world,” and no one believes them.
This is the story of my experience with design systems too. It’s near-impossible to ship the first version of a design system without a Volatile or two willing it into existence through unconventional decisions and brute force.
Starting a design system with “foundations” is logical and rational. It feels like common sense. And it rarely ships or finds traction and adoption.
I’ve seen a high correlation between those who overvalue the importance of “foundations” in design systems and those who are actually trying to create a style guide, not a design system (even if they’re not aware of that or the difference).
Style guides are a collection of rules. They tell you what you’re allowed to do and not allowed to do within a given context. Use this blue. Geometric patterns aren’t permitted. Cool colors only. While the best style guides allow you to create within the rules, most only succeed at enforcing consistency by censuring and eliminating unwanted variation. Useful, but restraining.
Design systems instead should be a collection of processes. The best ones focus more on what you can do and give you the tools to do it.
Perhaps the most important difference between a style guide and a design system is their approaches to the idea of change. Most style guides try to limit change. Design systems lay the groundwork for change to happen easily, elegantly, and scalably. Design systems are at their most valuable at the moment of change. When a big rebrand comes along, a well-connected design system can reduce that effort from months or even years of individually modifying and refactoring existing application code to a few weeks or even days of changing a few design tokens.
Within the context of design systems, I find it difficult to reconcile the ideas of “foundations” with continually pursuing a framework for elegant, organizational change.
So, if not first, when do you get to pick colors and typefaces?
Later. Or whenever. Maybe first, but also maybe not. Anytime.
I’m not saying colors and typography aren’t important. I’m saying they don’t have to be the first thing you do—and they often shouldn’t be. I’m suggesting we loosen our reliance on the sacredness of things like colors and typography in the beginning stages of design system work.
If colors and typography are foundations, then surely we should choose a color palette and a typeface before we move any further, right? And, if this is what we build everything on top of, shouldn’t we take ample time to do some color and typography studies to ensure we’re making a decision that lasts? Suddenly, you wake up 6 months later to realize you haven’t actually made anything that an end user can interact with.
The idea of “foundations” in design system work is a black hole. For systems-minded designers and engineers, the gravitational pull of spending months studying to find a perfectly harmonious set of colors, workhorse type family, data visualization library, or animation suite is near impossible to resist. When done too early, these are self-serving (and often selfish) activities that distract from the real focus of design systems: making it easier and better for feature teams to create things that further the organization’s mission.
A design system is a product, so the process to create an adopted one should resemble the process that startups use to create adopted products: create a minimum viable product to test a particular hypothesis, measure how customers respond, and learn whether to pivot or persevere. Picking primary and secondary colors isn’t a test of any particular hypothesis, not one that matters when you’re first starting anyway.
Spending time on “foundations”reveals its own hypothesis: that an objectively better design system will find traction. That, if the code is cleaner and the design is tighter, designers and engineers will naturally make the wiser choice to use it. Perhaps of any common assumption I’ve seen in design system work, this is the one I’ve found to be the least true.
I’ve seen design systems gain adoption for a number of unorthodox—and honestly contradictory—reasons:
The reason I’ve seen least was that the design system was simply better. “Better for me” or “better for our team” wins over “better.” The fidelity, comprehensiveness, or even existence of “foundations” seems to make little difference.
The exception to this is the specific scenario where leadership has mandated upgrading to a rebrand within a certain timeframe. In this case, simply having the new brand attributes like colors and typefaces in the design system is the primary draw to adopt it.
If “foundations” is a misleading label for things like “color” or “typography,” what should we call them instead?
Nothing.
Call them what they are: “colors” and “typography.” A growing trend in design system work is that everything is a component—thanks React—so these can be components too. File them alphabetically like you do everything else.
If you really need an umbrella term, consider something like “Identity” that doesn’t imply a hierarchy or sequence and allows these pieces to be independent, reusable, and modifiable like every other component.
We worked with a client recently who came to us because they weren’t seeing enough traction with their design system, despite it being up and running for the past year with a handful of components and “foundations” built in. We ran a few internal pilots with them to set some benchmarks for how much a design system could help if more widely adopted. Within that pilot work, we barely talked at all about colors and typography and instead spent most of our time on team culture activities, brainstorms for fun internal tools to build, and hot potato-ing. After seeing some pretty compelling proof points at the end of our work together, leadership decided to invest more in design system work—but with the mandate that they spend more time developing out more of the “foundations,” against our final recommendations.
Six months later, the team launched a beautiful, new, custom-built reference website—probably the most beautiful one I’ve seen yet—featuring a restructured set of design tokens and a lot of documentation about the design language. Not much has changed in the design system support Slack channel; questions from feature designers and engineers about how to use the small set of components available and when new components that meet their needs continue to pour in, around 3–5 each day.
A month later, the design system team announced that they’re cutting back their availability for design system support and co-creation with feature teams to instead dedicate that time to making “foundations” their top priority.
Almost two years after they initially began design system work, they’re taking applications from feature teams who’d like to try out the new library of foundations once it’s ready… whenever that might be.
Join 57,400+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!