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">.
Working with this team, I learned one of my most valuable and most used lessons to date about #designsystems (and about working with people in general):
It doesn’t matter what you agree on. It only matters that you agree.
I encounter many teams that stress out searching for “objective” and “intuitive” names. They run week-long workshops, dozens of surveys, and mounds of card-sorting exercise, all with little return.
Stop it. In my experience, there’s no such thing as an objective/intuitive name.
Sure, there are CONVENTIONAL names that have emerged, but convention is dependent on context, history, and many other political and social dynamics.
Within a context—like a team or a company—we can GIVE any word meaning.
The @RFERL team DECIDED and AGREED that “Fred” was an acceptable name for this component. That decision—regardless of how silly WE think it is—allowed them to move forward on more important tasks.
Loosen your requirements of finding intuitive names and start noticing what your teams can agree to, even if not objectively “good.” The more you can open your mind to different versions of what successful naming looks like, the more success you’ll find in your naming endeavors.
In part 2 of my naming suggestions, I’ll share my top 2 strategies for getting people to agree (on anything).
If you enjoyed this thread:
1. Follow me @danmall for more of these 2. RT the tweet below to share this thread with your audience
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/
There’s a scene in Harry Potter where he and his friend Ron arrive late to their first class of the year of Advanced Potion Making. Harry tells Prof. Slughorn that they don’t yet have textbooks, so Slughorn sends them into the closet to get books.
There are 2 books left: a brand new one and an old, beat-up used one. Ron and Harry fight over it, and Harry gets stuck with the old one.
The article is a summary and commentary on @johnmaeda's "Design in Tech Report": designintech.report. The phrase that has seemed to polarize its audience is in the title: "Design is not that important."
As a designer—one that has spent years trying to be a good designer (whether or not I've succeeded—this hurts my feelings! Who are you to tell me my many-year pursuit isn't important?!