How to build a bad design system
I didn’t realize this until it was far too late, but one of the biggest mistakes that’s made on a design systems team is a common mismanagement issue: there are too many people in a meeting and they have too many dang opinions.
Is there a conversation about the color of your buttons that’s taking place? Great! Everyone needs a consistent set of colors so that users know what to click and so that designers don’t have to choose from a smorgasbord of options. But the tough question at the beginning isn’t what colors we should choose and when to pick them, but rather this: how many people are in that dang room?
How many people are making decisions about your design system?
Are three people talking about the buttons in your design system? Wonderful. Are there 20? Woof! That’s a serious problem because it shows that far too much energy is being spent on the wrong things; it’s nothing short of mismanagement, in fact.
(This is why I reckon design systems aren’t about design or even about systems. It’s actually about managing people and their time, attention, and focus. But that’s a rant for another day.)
Anyway, the hard call that someone on a large design team will have to make at some point or another is deciding which people need to leave the room. And that sounds really mean, I get it, but it’s the kind thing to do. If everyone has opinions then, first, nothing will get done and, second, you’ll end up causing rifts when some opinions are shunned and others are heard.
It was thoroughly shocking to me when I started my first big design systems project that the more people that joined any given meeting, the less effective we were. It was like the IQ of the room dropped by ten thousand points. And I was also shocked that the hardest problem wasn’t about building the system; learning about TypeScript, making sure components were accessible, doing audits, etc. Instead it was this: the whole too-many-people-in-a-meeting thing.
Everyone cannot possibly be allowed to voice their opinions about every tiny detail of the UI and at some point someone needs to come in and draw a line as to who is allowed to care about what things. That’s not to say that people aren’t allowed to have feedback — feedback should always be welcome! — but one of the main advantages of having a design systems team is to offset all those decisions onto someone else.
I was listening to this livestream of Jason Fried and DHH the other day and they mention that:
If you want to be even less sure about something, all you have to do is ask one more person what their take is.
That’s definitely the feeling I had when too many people were talking about buttons or borders or anything, really. This sort of hopeless feeling that change just isn’t possible. And that you can’t make a decision about something because you need to massage the egos of everyone in the room.
This also reminds me of this great post by Paul Ford about what the web is:
“Why wasn’t I consulted,” which I abbreviate as WWIC, is the fundamental question of the web. It is the rule from which other rules are derived. Humans have a fundamental need to be consulted, engaged, to exercise their knowledge (and thus power), and no other medium that came before has been able to tap into that as effectively.
Working in a big organization is shocking to newcomers because of this, as suddenly everyone has to be consulted to make the smallest decision. And the more people you have to consult to get something done, the more bureaucracy exists within that company. In short: design systems cannot be effective in bureaucratic organizations. Trust me, I’ve tried.
Anyway, the way to fight that is by drawing that line, by kicking people out of meetings that don’t need to be there. It’s really the kindest thing to do because it will make your design system much faster to build, and less stressful for you.
The post How to build a bad design system appeared first on CSS-Tricks.
