Design systems are flawed
3 actions to get the most out of design systems
Back in the spring of 2021, the CCP (Clube Criativos Portugal) invited me to talk about design systems. At the time I wasn’t focused on design systems, but I decided to accept the invitation anyway. I thought that I could still speak to my own experience, as someone designing a new product and referencing one of the most well-known design systems around: Shopify Polaris.
Funnily enough, a couple months after my talk I found myself on the Polaris team, and adopting this new perspective helped me evolve my understanding, and develop my opinions when it comes to design systems. I figured I could share some of that with you.
Design systems are hot!
Everybody seems to be talking about design systems nowadays (#guilty) and they have become a bit of a hot commodity. It’s easy to understand why.
- They help with consistency, so there are fewer unique solutions for similar problems.
- They make design and development faster.
- They free designers and developers to focus on bigger, and more specific, problems.
At least, that’s the theory…
In practice, I think design systems are a bit misinterpreted, which isn’t fertile ground for the best design results, because:
- Consistency becomes monotony and we lack variety and intent in our solutions.
- Speed is overrated and the momentum hinders teams from building outside the bounds of the system.
- Designers and developers become imprisoned within the system boundaries.
Does that mean we should burn our design systems?
Heck no! It just means that in order to reap the benefits of a design system, we need to tweak our perception, and the way we build and use them.
In this article I’ll share 3 facts I hope everyone can accept, and 3 actions I believe we need to take to make the most out of our systems.
The facts
1. A design system is more than a library
Most people will define a design system as a collection of components that can be assembled to build digital products, but is that all? I think not.
The library is just the what. We can’t forget about the how and the why.
I believe people focus on the what because that’s the artefact we interact with the most. Time and time again I see designers saying they built a design system, when in fact, all they produced was a UI kit. Don’t get me wrong, UI kits are extremely impactful tools to accelerate execution, but that’s just a part of the equation.
Another important part is the how. Because people need to understand how the system is supposed to work and be used. Currently, we do this by documenting our solutions, but I believe there’s room to improve.
More than stating the obvious or describing things in lengthy paragraphs, we should lean on our superpower as designers and show, before we start telling.
If we want our documentation to be consumed, and more importantly, to be impactful, we must put as much care into it as we put into our actual design solutions. A design system is also a product.
The how goes beyond documentation though. It’s also about practices and processes.
A design system team can’t evolve a system on its own. Thus, they need to establish clear ways of working with other teams across an organisation, so they know how to contribute and help evolve the system. We need tight feedback loops between product and system.
Last, but not least, the why. This is the one I think we disregard the most, and the one we need to get a whole lot better at.
Like any product, a design system needs to evolve continuously. To be able to do that, designers need to understand what led to the status quo. Only with that context are they able to know whether they should question a decision or just trust it.
We must fuel designers with relevant context and insights because the relationship we want them to have with the systems should be based on trust—not blind faith.
We want people to question and improve things, otherwise why should we hire skilled intelligent professionals? Just to do as they’re told and copy-paste pre-baked design components?
In a past article I elected our brains as the best design tool, and I meant it. But that tool needs fuel, in this case, everything that leads to the decisions baked in a system.
2. A design system is just a tool
I like to draw and I post stuff on Instagram from time to time.
Since I started doing that, there’s a typical question I get asked a lot: “What app or brush did you use?”.
I’m pretty sure this sounds familiar in many other fields. People ask photographers or videographers what camera they use, or ask athletes what shoes they run in.
Some people believe that skills come with the tools, but the truth is that tools, at their best, can only augment what is already there. Kipchoge ran a marathon in under 2 hours because of decades of training and dedication. His shoes were just a little help; they didn’t run for him.
I think the same can be said about our design systems.
A lot of designers and organisations believe they can lean on the system for design quality, but having a good design system isn’t a synonym of design quality. A design system is just a foundation, a tool to help you get started and move faster.
Kipchoge still needs to run when he wears Nike’s latest shoes; they don’t run for him. Like I still need to convert my ideas into drawings; the iPad doesn’t do that for me.
When you design, whether you’re referencing a design system or not, you need to be intentional in every decision you make, even if that decision is trusting a decision someone else made.
In interviews, I’ve seen designers blame poor design decisions on a design system, on a manager/client, or even on another designer, but that always makes me ask:
“If you believe there’s a better way, what stopped you?”
As a designer, your job is to advocate for the best possible solution, and own whatever compromises need to be made along the way.
All this to say that, a design system is a tool for accelerating and scaling design, and as a tool it still requires the user to come with the skills and to be able to think for themselves.
3. A design system is always incomplete
You can’t really predict future problems and needs, so you’ll never be able to say a design system is complete. Because of that, a design system will never be enough, and we shouldn’t expect it to solve all our problems.
A product remains relevant by continuously evolving and adapting to fulfil user needs, and design systems are no different.
However, I think we still approach system design like we’re building bridges: after you build it, you maintain it. But I don’t think that’s ideal.
This bridge in Honduras is a good example why.
The bridge became useless after a hurricane changed the course of the river. This is what happens to design systems if we let them become stale.
A solid structure like a bridge can’t adapt to changes because it’s expensive and it takes years to build. Rather than approaching design systems like architecture, we should approach it like gardening.
An architect designs a structure considering every single detail, but once they’re done, they move on to the next one.
A gardener plants seeds and tends to them. They know what they planted, but they don’t know exactly what the garden is going to look like. They find out as it grows and intervene when they find weeds, or they want to make changes.
A design system needs gardeners, because they will tend to it and evolve it continuously. With that being said, ironically evolution seems to be a bit of a chicken and egg problem.
Teams working on product features often need specific solutions, but they are afraid to “break the system”. On the other hand, the system can’t evolve without knowing about these needs. It’s a stalemate.
The best way out of this, I believe, is by breaking down our silos. We need proper collaboration and communication, but we must also accept two things:
1. It’s ok to break the system, as long as you’re doing it with intent. If your user needs a solution that is very specific and unique, you can’t let the system hold you back.
2. Ultimately, everybody owns the system. You don’t need to ask for permission; you should feel empowered to push for change and progress.
People who are the closest to the problems need to be the trailblazers, and the system is there to help augment that, when it makes sense.
It’s all about never-ending feedback loops, which leads me to conclude that a design system is not a problem to solve, it’s a process to manage.
We’re not playing with Lego
A lot of people like to compare design systems to Lego, but personally I always think of pegs, the kind you use to hang clothes. Because, when I was a kid, my family didn’t have a lot of money to spare on toys, so I found in pegs my alternative to building-block toys.
With individual pegs, I made up characters, and I clipped them together to build objects and worlds around my characters. My system was pretty limited, but that didn’t stop me from having fun with it.
I think pegs are a better metaphor than Lego, because they better reflect the state of design systems.
Lego have been evolving and expanding for decades, and I think it’s fair to say that you can literally build anything with them, however, the same can’t be said about our design systems.
My pegs “play system” was pretty limited. For instance, if I wanted to do something like play with characters from a show I watched on TV, with Lego that was possible, with pegs I couldn’t.
But, as any child, I didn’t let that stop me. I decided to extend my system and started drawing characters from my favourite TV shows. And then I would cut them out with scissors and make paper action figures out of them.
We need to be more like children, stop looking for excuses and crutches, and instead try to solve problems.
What can we do?
1. Be consistent and intentional
Being consistent doesn’t mean everything needs to be the same.
We need hierarchy and contrast to be able to give emphasis to things that are more important, and sometimes we also need to design a bespoke solution to help users understand a complex idea, or just to create a moment of delight. Fabricio Teixeira has a great talk about this. Go watch it.
We can’t let our systems dictate too much of our experiences. That prevents design systems from evolving, but, even worse, creates poor experiences for people.
Rather than letting the system define our solutions, we should solve problems independently and then find ways to apply the system to it. And when it makes sense, make sure to contribute back to the system, and don’t just document the solution (the what), but also what led to it (the how and the why).
In short, be a designer, not an assembler.
2. Measure more than speed
We can’t base our performance solely in the volume of things we ship, or how fast we ship them. There are more dimensions to what we build beyond functionality, like quality, user value, usability, delight, and so much more.
Design is a multiplier of user value: it doesn’t matter that a product has a lot of functionality if most users can’t use it intuitively.
If we truly care about our users’ experience, we should recognize the trade off between speed and quality. We should advocate for spending a bit more time to ship a product with better design, making a case for the value it brings to the table.
Also, let’s face it, more often than not, once you ship something that is subpar, that will rarely be temporary, so have that in mind when you start to compromise.
That V2 with better design will have a hard time making it to the top of the list of priorities.
3. Don’t settle
The way a designer can have the most impact, in my opinion, is by consistently thinking ahead. Continuous small improvements and iterations are essential, but in order to know what those should be, you need to raise your head to see where you should be going.
Designers need to be proactive, not reactive.
Taking feedback is key to the work we do, but we need to be opinionated and able to interpret it rather than just moving blindly down a particular track.
Understanding the root cause of feedback can be much more fruitful than just reacting to it.
Last, but not least, we should be the primary advocates for design quality, whether that means pushing for design initiatives to be prioritised in the roadmap, or following through the building of the product to make sure things are up to our standards.
The worst disservice a designer can do is to stop caring.
If there’s only one idea you take away from this article, let it be this:
Thanks for reading! Since you made it this far, I’ll introduce myself:
My name is José Torre, I’m a designer and I write stuff here sometimes.
If you feel like talking, connecting, or just want to see what I’m up to, I’m Halfool on YouTube and Instagram, and you can also follow me on Twitter and LinkedIn.
