What is a #designsystem? You’ve probably heard lots about them. You may have even worked on one, but you still struggle to define it.
Here’s how I talk about #designsystems to anyone who will listen: 🧵
There are many great design system books out there. Let’s see what their authors have to say about design systems:
“A design system is a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product.” — @craftui, Design Systems
“Design systems bring order and consistency to digital products. They help to protect the brand, elevate the user experience, and increase the speed and efficiency of how we design and build products.” — @andrewcouldwell, Laying the Foundations
“A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.” — @MarcoSuarez, Design System Handbook
Here’s what other industry experts had to say about design systems:
“Design systems are any set of decisions governed across an organization.” — @hayhughes,
“A design system is a library of visual style, components, and other concerns documented and released by an individual, team, or community as code and design tools so that adopting products can be more efficient and cohesive.” — @nathanacurtis, medium.com/eightshapes-ll…
Why so many definitions? Perhaps it’s because the term “design” is broad and the term “system” is broad, so the combination is fitting broad too.
In my work, I’ve found 6 different kinds of things that can be described as design systems:
1. Brand identities/visual languages 2. Tools 3. Products 4. Process 5. Design system as a service 6. Design system as a practice
For more info on each, check out my new video on the topic (and subscribe to the channel for more soon-to-come videos like this):
I’m fortunate to receive lots of emails and DMs from people looking for advice or mentorship from me. But 90% of these messages have a major mistake that would have otherwise made me interested.
Here’s the crucial ingredient to getting what you want from someone you admire:
🧵
Many of these messages have this kind of structure:
> Hi Dan, I’m looking to connect with you to learn more about how I can grow as a designer.
or
> Hi Dan, I’m wondering if you’d want to be on my podcast. I’d love to have you on if you’re interested.
What’s missing here?
The thing that bugs me about them is that THERE’S NO ACTUAL QUESTION ASKED. There’s no request. I can infer and assume what they’re looking for, but I assume you know what happens when we assume.
The crucial ingredient to getting what you want is actually asking for it.
One of the biggest pain points for #designsystem teams is naming (components, patterns, tokens… anything).
Here are my most useful tips for naming design system things (part 1).
🧵
A few years ago, I was lucky enough to help @RFERL with their design system. They had—and still have to this day—this component all over the site. What would you call this? A carousel? A banner? A slider?
Wanna know what they called it?
They called it “Fred.”
Seriously.
Look at the source code. The element is called <div class="fredContent">.
I’ve worked with #designsystem teams at companies like Amazon, Netflix, Google, and more. The most common blocker about #designsystems I hear from them is, “I never really looked at it that way.”
My biggest tip for reframing #designsystem work to make it more approachable:
🧵
Do less.
Almost every team I work with tries to make their design system do everything. They stress themselves out, trying to tackle too much and end up accomplishing nothing.
Pick a handful of things, and do them really well.
Many mature #designsystem teams I talk to have one thing in common: they’re REMOVING components from their design system. They’ve realized they can’t support everything, so they’re trimming down to just the things they know they can fully support.
Warren Buffet once famously quipped, “Risk comes from not knowing what you’re doing.” If improving your #designsystem is one of your goals for 2023, make sure lack of knowledge isn’t one of your blockers.
A new resource for you in this thread 🧵
There are so many resources out there now for learning more about #designsystems! A wealth of public information is great, but it often comes with analysis paralysis. Where do you start? How do you separate the signal from the noise?
I’ve been working on a simple resource to help with this. I’m launching my Design System Advent Calendar today, my own customized lesson plan of 24 valuable and short lessons to help improve your knowledge of #designsystems.
Many design system teams think their job is to define best practices for the rest of the organization. Excited about being blessed by leadership as the team to enforce these best practices, the team often resorts to their wish list of things they’ve always wanted to have or try:
“Let’s reduce our color palette to just the essentials!”
“Typescript might be a great thing to try.”
“This seems like the right time to define some motion guidelines.”
“We’re finally all switching from spaces to tabs!”
This smells like the classic xkcd comic about Standards: xkcd.com/927/