Material’s color system is no doubt impressive, but that doesn’t necessarily mean it’s compatible with yours.This post was initially published on the Pinterest Design blog.
One of the major challenges of systems design is communicating the rationale of decisions — why you landed on certain choices, and why they make sense in the bigger picture. I’ve found language is an effective metaphor to explain my rationale: Creating a system is, in essence, creating a language.
Let’s look at the definition of the word “language”: The method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.
We can tweak that a bit to apply to design systems: The method of human communication within a user interface, consisting of interface elements in a structured and conventional way.
I’ve found the rules of language to be a great way to vet my own ideas…and to critique other people’s work, too. Using language metaphors to describe system tenets keeps things tangible. Language is as common a denominator as there is — the translation (no pun intended) is straightforward.
What’s less straightforward, however, is the English language. From first-hand experience, I know English’s rules are not fun to learn. It’s riddled with inconsistencies and irrational rules. It’s also a gold mine if you’re looking for examples on how to not design a system. Here are some ways that language can translate to and help explain your system’s design.
The words doppelgänger and depot are adopted into the English language. Doppelgänger originates from German and depot from French. By adopting these words, we’ve also adopted the rules for how those words are constructed. Now all of a sudden we have umlauts and silent t’s in our language that we need to make sense of. There’s nothing wrong with this (who doesn’t love an umlaut?), but they don’t fit the foundational rules of English. The result is they don’t feel as though they’re a natural part of the language.
The common equivalent in systems is the classic, “Design System ABC did XYZ — we should just do what they do!”
Material’s color system is no doubt impressive, but that doesn’t necessarily mean it’s compatible with yours.
Everything in a design system should originate from its fundamental rules. Pulling ideas from other systems is expected, but those ideas need translation to conform to your system’s underlying thinking. So it might have made more sense for Doppelgänger to become Doppleganer in English and for Depot to become Deepoe (or Deepow? or Deapoh?). Just sayin’.
Flammable and inflammable mean the exact same thing — just look it up. But then…why do both exist? Should I use one over the other in certain contexts? Do people even know they mean the same thing? I have so many questions! Couldn’t we have settled on one word and moved on?
The go-to example of this principle in design systems is the checkbox and switch. Systems often provide both these solutions to address the same need. This makes you ask: When do I use one over the other?
There are good reasons to have both a checkbox and a switch. For instance, you use a switch in the mobile context and a checkbox in the web context. In that case, you’re providing a single solution (per platform) to solve a single need.
Our design system at Pinterest system has supported both checkboxes and switches on the web platform which led to unnecessary variance in usage. We’re working to consolidate to one single treatment.
When people have many options to do the same thing, they’ll usually end up using every option. That almost always leads to poor outcomes, and the design system’s job isn’t to provide a buffet of options, but to provide the solution for specific use cases.
Design systems, just pick “flammable” (or “inflammable”) and move on.
Come on…you knew this example was coming.
English is full of nearly identical homonyms and they cause constant confusion. It sure would be nice if English had distinct words for distinct concepts.
A common example of breaking this rule is link treatment. Due to accessibility, color alone isn’t enough to signify a link. There should be a clear and distinctive way to tell the user, “Hey, this text here is a link.”
Another example using Pinterest’s design principles. We could improve upon this.
Distinct interface elements should have something which makes it distinct. Elements that look the same but are different in purpose will always cause confusion. It’s simple: If things are different, they should look, sound and feel different. Don’t go their (sorry…there).
Accept (əkˈsept) and except (ikˈsept) have technically different pronunciations. But let’s be honest, they sound the same. Unfortunately, they mean drastically different things: “It was excepted” means something very different from, “It was accepted.” Given how diametrically opposed those two words are, it’s safe to say the words should be more clearly differentiated.
A similar example in design? Using color as the only differentiator between statuses like success and error. Given how fundamentally different these are, there should be a strong distinction between the two. Color is one way, but it should go well beyond just that. For maximum accessibility, we should differentiate error messages through messaging and iconography as well as color.
Well, we got 1 out of 3 differentiators here. Sure, the text is different, but there aren’t any distinguishing features in how the text is constructed with our error toast’s text (something like Oops! at the beginning) to differentiate it at a glance.
You don’t need to be a rocket scientist to know the three words above are related. The phobia suffix makes these three words immediately relatable: They share a commonality, yet represent distinct concepts.
Families of design components should have shared traits that make it clear they’re related. This often happens naturally, but it’s important to be intentional about what those traits are. Doing so will help you make system-friendly decisions when you add to the family.
Pinterest’s form inputs share a set of visual traits (corner radius, border treatment, sizing, etc.), but each also has a distinct trait that makes it unique. The shared visual traits also act as a contrast from other components, such as our buttons.
Elements that are a part of a family should intuitively and consistently feel that way. The more intentional you are on how related components are visually communicated, the easier it’ll be to add your next phobia.
Avoid being fancy when you can use a simple word — say “good” rather than “transplendent” so people stay on your page. The same goes for design: Don’t complicate basic concepts. You’re only going to make it harder for people to understand how to use the system.
This was one of Pinterest’s guiding principles for our initial dark mode rollout. We were set on keeping things simple and not overthinking. So our dark mode was in essence a palette flip with a super minor tweak to one of our grays for accessibility. And it worked (For the most part, I’ll get into that later.) It also allowed us to ship extremely quickly with minimal overhead.
We kept our dark mode simple and it paid off.
Anyone that’s had to learn English is familiar with the classic “i before e” rule. They’re also keenly aware of how silly the rule is, and that it’s not even reliable. A language is useless if no one can learn its rules. The harder a language’s rules are to learn, the greater chance people will:
Systems are especially difficult when components have different properties depending on its context. If you use words like “if,” “but,” and except” to explain how a component works, it’s time to reevaluate. Either streamline the component to remove conditional rules or break it up into separate, easier-to-use ones. I’m guilty of the example below.
About that dark mode effort… Our initial palette forced some unfortunate one-offs, specifically how our inputs and buttons needed to slightly lighten on elevated surfaces to remain accessible. That treatment is something I’d love to take back.
Complicated or nonsensical rules won’t be followed. If you want to make a system that no one uses, make it hard to understand.
Slang happens. People make up words. In a perfect world, those words still feel like they’re a part of the language. But they shouldn’t rehash another word for a different meaning (see: salty) or be gibberish (see: ROFL).
Custom components that aren’t a part of your system are like slang — and they can and should conform to the system’s rules. Plan for design-slang deviations and find a way to guide them to be compatible with the system. This is where higher-level guidance of how to design components is so helpful. If you don’t provide guardrails, you’ll be dealing with the UI equivalent of Thicc. Come on, two Cs?
Above is an example of a custom combo button created by one of our product designers. It lets people combine a list and a button (the “OMGLOL” in this situation), and easily fits into the system’s aesthetic rules.
It’s easy to overthink design systems. This isn’t to say that creating a design system is a piece of cake — it’s not — but we don’t need to make it harder than it already is. At the core of a design system, we’re trying to create logical, repeatable rules that allow people to “speak the language” competently, salty slang and all.