Back PJ Onori’s blog

Making a design system is a people job

Designs systems are all the rage. They’re discussed to the nth degree and their benefits can be very real. Yet, there’s nothing easy about building a successful design system. There are a million different things that can steer you off the road and many of them have nothing to do with design.

I’ve worked on a design system or two in my time and have learned a lot through each process. The most important lessons I’ve learned uncoincidentally have little to do with design. Instead they’re are about the factors and approaches that set teams up for success.

With that said, these are my personal learnings. There’s ample room for disagreement or different conclusions. Like most things, your mileage may vary.

Design systems help good teams work better

Design systems are great, but they are nothing more than a tool. Like any other tool, they are an amplifier of strong fundamentals. Design systems won’t fix people/cultural problems. They won’t help you get along with your colleagues. They won’t make those who don’t value design to magically see the light. Design systems are a tool to use — when adeptly wielded, they can help people be more effective.

It’s critical to not put the cart before the horse. Get the foundational aspects of your practice right. You need that strong foundation to ensure your tool is adeptly used. Design systems, like any other tool wielded in the wrong hands, can do a lot of damage. The dysfunctions within your team/org will manifest in your system. If there’s no cross-functional collaboration or teams can’t drive to actionable decisions, those problems will plague your design system.

Your team’s output is a reflection of your company’s culture and the people that work in it. Nail down the fundamentals of a strong design practice — its people, culture and relationship with the greater org. This will set you up for success when you create your design system, or anything else for that matter.

Design systems need commitment and a mandate

I’m not the kind of guy that enjoys the idea of forced mandates. I think it’s often abused and employed for the wrong reasons. But I do believe design systems need commitment and (yes) a mandate for them to take hold. The bigger the company, the more explicit that mandate should be. Let me explain why.

Building a design system is tough in the best of times. It’s all the more difficult in large orgs with disparate/disconnected teams. That’s ironic as they’re where systems can provide serious value. You’re going to push up against human dynamics like skepticism, disagreement and territorialism. You’ll face nuts-and-bolts challenges of making a system that actually works for all involved. There will be hiccups, mistakes, misunderstandings — you name it. You’ll struggle with the transition pains as teams move to your new, fledgling system. None of these no fall within the realm of “fun” — for anyone.

Any of the issue above will make it tempting for teams to bounce when the project hits a pothole. The rationale will be rational; Team A needs to ship a new feature now and migrating to the design system will slow that down. Team B’s designer is a rock star and your system will stifle her ability to deliver tailor-made solutions. The tough thing is their concerns are valid — when assessed in a vacuum.

That’s why there needs to be a clear message — from leadership — that states, “This is what we’re doing. We need everyone to help make it succeed”. It has to be a collective understanding that the system is for the collective benefit. While each team is going to feel a little pain, the goal is a net positive effect. The only way for that net positive effect to take hold is if everyone is pushing in the same direction.

Without that mandate, there’s a good chance you’ll be herding cats. Cats that don’t report to you.

The hypotheticals will kill you

It’s easy to see need for another component, another color, another xyz. Need is a strong word and usually confused with desirable. The more colors, type treatments, or whatever, you add to the system, the more complexity you own. More complexity means more maintenance, bugs, regressions, confusion, misinterpretation and general headaches. Be very careful what you commit to. It’s much easier to add things to a system than it is to remove them. Complexity is the rope you’ll hang yourself on.

Discipline yourself to keep your system as small as possible. Focus on existing, real-world team needs and address them with the simplest solution. Yes, you won’t have everything people want. Yes, there will be gaps. And, yes, those gaps mean you may need to re-evaluate past decisions (more on that later).

I’d argue a little thrash is far more healthy than a bloated system that can no longer get out of its own way.

Design systems are a product with three distinct and equally-important cohorts of users

Design systems are not only for people interacting with its byproduct. These systems are as much for the designers and developers using it to build interfaces. If the system doesn’t help designers create better solutions, they won’t design with it. If developers hate building with it, they won’t build with it. If either design or developers resist, there’s a good chance it the end-consumer won’t see it either.

Design systems need to equally serve three cohorts — designers, developers and end-consumers. Designers and developers need the tools (e.g., interface components) and resources (e.g., usage guidelines) to help them succeed. The system needs to objectively make them to be more effective at their job. It doesn’t hurt if it makes work more enjoyable as well.

The challenge is to provide enough tools/resources to help them succeed. But not too much where it becomes restrictive. Your system is never going to have all the answers. But, it can and should be your team’s design philosophy made manifest. Meaning your system should communicate the principles needed to guide going “off-script”.

There will be thrash, so have a plan to mitigate it

You’re going to get a lot wrong in your system out of the gate. It’s just going to happen. You’ll discover you had no idea what you had no idea about. Then you’ll have to make changes — sometimes drastic ones. Meaning there will be thrash. And thrash is not fun for the people consuming your system.

I am fully committed to the notion that thrash is a good thing. It means you’re committing to a direction, learning from its execution and then adjusting. But for the sake of the people using your system (and your relationship with them) it can’t be a constant. You shouldn’t fear thrash, but you need to know when it’s useful and how to help mitigate its downsides.

One of the best way to mitigate the downsides of thrash is to start small — with everything. Keep the system small, keep the documentation small, keep its user-base small. It’s crucial to limit how many people you involve. Any major thrash (like the near-180-degree turns) should occur as early as possible in the system’s lifespan, before the cement fully “hardens”.

It’s also important to only expose teams to thrash that are comfortable with it. You often need as many champions as you can get in the infancy of a design system. The last thing you want to do is create unneeded doubt and frustration.

Here’s how I like to go about kicking off a design system:

The above assumes you’re constantly evolving the system based on learnings and communicating them out. All this is in the spirit of maximizing learning while mitigating risk. As you learn from these small iterations, you’ll gain confidence that the system is ready for broader use. You don’t need to go out the door with everything if teams can see it’s headed in the right direction.

The “big reveal” approach is not advisable. You’ll be at the pre-release stage forever if you try to solve every potential solution from day one. Which means no one is using your design system — which defeats the point.

Making it is the easy part

So your design system hit the 1.0 milestone and is in circulation. Now comes the hard part. You’ll deal with training, governance, avoiding bloat and maybe the trickiest, managing progress.

Let me clarify — when I say managing progress, I’m not talking about the progress you see from 1.0 to 1.0.1 or 1.1. I’m talking about the progress from 1.0 to 2.0. It’s inevitable that almost everything that you make in the system — no matter how good — will run its course. Interface paradigms change, new platforms show up and the product you built the system for evolves. There will come a time when you’ll have a critical mass of ideas to improve your system based on the new reality of today.

If your system stagnates, your product will as well. Meaning you risk you design system becoming a liability. You can’t stop improving the system, but it also can’t be an agent of chaos within your org. I haven’t come across one-size-fits all solutions for these problems. You need to have an idea of what works for your system and your stakeholders. It doesn’t need to be a perfect answer, but you need to at least plant a flag in the sand. You may end up supporting multiple versions to give teams some flex on when they migrate. You may risk creating more forward-thinking solutions so they have a longer half-life. You can do a lot of things, but what’s most important is you have a plan that works for everyone invested in the system.

In short, you’re never done with your system. That’s something that everyone needs to be keenly aware of before committing.

Bonus: We’re designing with systems backwards

This point is a little less actionable, but I’m putting it here for folks to chew on. I posit that the way we apply design systems within the design practice is 180 degrees from where it should be. The value of code-backed design systems (what I like to call “design systems”) is that it’s theoretically a single source of truth. That’s not the case for 99.9% of teams though. In reality, we have two sources of truth. We have the the code-backed design system and an ancillary library of symbols for our design tool du jour. This is a big problem.

It’s a big problem because we’re not working from that elusive single source of truth. This is humorous since it’s one a core selling point of design systems yet it’s rarely ever the case in practice. It’s all too easy for a code-backed design system and its supporting design library to bifurcate. Bifurcation starts small and then all those small things add up. Then the questions and confusion begin. Sure, you can dedicate processes and time to keep the two in sync. But then you’ve dedicated processes and time to keep the two in sync. Meaning you’re losing out on other areas of opportunity that aren’t (dare I say) busywork.

The source of truth in product development needs to be whatever is going to show up in production. That happens to be code. The problem there isn’t a go-to solution to design with code-based components. We’re just limited by what’s possible. But there’s movement to meet this need and it’s well worth keeping an eye on. AirBnB’s Sketch React and Framer X show the promise of a very different future. But they are still very much in that promise stage. I look forward to when something makes good on it.

Let’s wrap this up

So that’s it. Those are the most important things I’ve learned in my time creating systems. Adobe XD, Figma or Sketch? Who cares. React or Angular? Whatever. Design tokens? Sure. The thing about those things is that they’re all temporary. The real, immutable challenge involves people and the people-stuff that’s always hard. It’s hard to get buy-in, align teams and create a shared understanding that everyone is embarking on a ride. A ride that’ll likely involve turbulence.

Make sure your team is ready, willing and able (in the literal sense). Get everyone to commit. Have a healthy fear/respect for complexity and hypotheticals. The rest is downhill from there.

So, to try to sum this all up in one sentence — Make it small, make it real, make it quickly — when your org is ready.