Creating Meaningful Design Systems: Embracing the Box and Reaping the Benefits

Soon I will be working on, not one, but two different design systems consultations. It’s a bit of a new venture for me. I’m used to helping build design systems, but in these two cases I’m helping the design teams plan and re-build a better design system.

In getting ready to kick these two projects off, I’ve found myself wondering - and like any sane designer with imposter syndrome; questioning - if I am qualified to say what makes a design system good… or not. I’ve worked on a dozen different design systems pver the years - big and small, good and bad - so maybe what I’ve learned from these past encounters would help guide me? It wasn’t until I found Amy Hupe’s excellent post on Building Conscious Design Systems that I was able to formulate a better point of view.

The baseline

A couple of years ago, design systems were these shiny new thing that would solve all the problems we used to encounter when designing and building products. Commonly, the advantages that were promised with a design system were (thank you Amy!):

• Efficiency: it will allow designers to move forward faster because they would not have to spend time on redesigning the same components over and over.
• Consistency: and because all designers would use the same components, we’d automatically achieve consistency across everything.
• Scale: and with consistency, we would be able to scale design decisions more easily.

You’ve all heard this before. If you are or have been a designer or product manager, chances are that you’ve argued these exact points to someone skeptical of the value of a design system.

But here’s the thing we rarely ever say: None of this has any inherent value.

Efficiency is only valuable if it helps us move faster towards meaningful outcomes for the people using our products and services.

Consistency is only valuable if we standardise things to a good level of quality.

And scaling things is only valuable if they’re actually worth reproducing.Amy Hupe: Building Conscious Design Systems

Playing the devil’s advocate

When talking to companies about their design philosophy, or design principles, a recurring theme is always to make things ‘simple’. As a designer, I’m a fan of making things ‘simple’. I also know that making things ‘simple’ is extremely difficult. I also feel like that it’s important to highlight that we’re making things ‘simple’ for the user. So if your design principle is ‘simple’, what is the process to make it simple for your customer to cancel their account or pick what communication they want to receive from you? Simple is not just about a frictionless checkout experience, simple is removing any type of friction from any process regardless if it’s one that is in your favor or not.

So back to design systems.

If we can use our design systems to speed up meaningful work, standardise things to a high quality, and scale the things we actually want to reproduce - then the reverse is also true.

It means that, if not built correctly (we’ll come back to this in a sec), our design systems can also:

• speed up problematic work
• make things consistently poor quality
• scale patterns that we don’t want to reproduce

Ouch.

Think of this way; using a calendar is great for organising your schedule and a tool like Notion can provide wonders for both structure and access to information. But none of these tools will make you organised unless the input is organised and, the rules and patterns you obey to are consistent. A design system is just like your calendar, it can provide miracles if used correctly. What’s the right way? One that empowers you.

It’s a parallel process

I’ve worked on projects where we’ve tried to define the design system first and, in doing, argue that we know 90% of the components that we’ll need. If that’s true, we should be able to start by designing that design system and then successfully use it to build the product, right? I don’t think this has ever actually worked. Designing components in isolation is a recipe for disaster. Design is not just the individual pieces, but it’s aso when you combine the pieces together.

Not quite as bad, but let me say it loud and clear, the opposite is just as bad - when you design the full product only to afterwards create the design system. It’s good in the sense that you know what components you’re actually going to be using, but it’s terrible in the sense that you’ll end up having to rebuild everything using the new components. Let’s face it, we don’t have time to do that. It also means that you’ve ignored all of the possible benefits of a utilizing a design system (efficiency, consistency and scale) by only working in an old-fashioned, waterfall-y style.

So in terms of process, a design system needs to be designed in parallel with the product. As soon as you have something ready to go, I think it makes sense to start building the design system. Remember, if done right, this living thing is made of components that are allowed to change over time! That is, in fact, one of the benefits of a design system. We can change it and we’ll still have consistency. If I update the radius of a button in the system, it should update everywhere that component is used.

Embrace the box

Almost a decade ago, my friend Pål Katsler and I held a course at Hyper Island. We both argued the notion that true creatives ‘think outside the box’ is not just tiresome, but can be dangerous in some cases. Creatives should embrace the box and make the most out of it. That’s creativity, being able to produce spectacular work with what you’ve got or been given.

Similarly when designing a design system, I believe it’s valuable to define the constraints and requirements early on. If we aim for our design system to make us efficient, doesn’t it make sense for us to build the design system efficiently? This starts with planning and requirements setting. If we aim for our design system to bring us consistency, the design system itself and the component setup needs to be consistent. If we want our design system for scale, we should allow our design system to scale. It’s intentional work.

What this means practically is consideration of the setup for the components. Do you want to build the components using atoms, molecules, and organisms? Do you want to separate out design tokens (colors, type, etc)? Do you want desktop and mobile components to use the same component or separate? What approach do you want to take for variations like different sizes and different states? What about light and dark mode? Seeing how this can get overwhelming? Defining these requirements will make the build more efficient, the design system more consistent, and better allow for better scalability!

Chaos is not good for creativity

Just like a painter needs their colors organized and a chef needs their mis-en-place - all ingredients gathered, prepared, and ready to use - to create a wonderful dish. Designers should have an organized design system to create really great digital experiences. In fact, if you think about nearly any profession, great work comes from order and structure, whether that is a lawyer, a surgeon, a housekeeper, or a pilot. Why would the work of designers be any different?

The philosopher Lewis Mumford said: “Order and creativity are complementary.”