3 learnings about design systems.
On a meta level, but not so much either… Or, heck! Another “trying to be in depth article” to make some sense about it.
These are my personal opinions and observations, any reaction or feedback is welcome!
I guess I no longer need to introduce the notion of design system by now, but just in case, I’ll take the risk of defining it with my own perspective:
A design system is a tool that the product team (depending on the org you work for) creates to industrialize the conception and production of the product by creating reusable components with behaviors, decisions etc…made of variables and constants. It allows a product team to define and create a frame in order to set standards for the production, insuring cohesion, visibility and scalability at a micro and macro scale. A product for the product if you want.
Now, this can be digital product making but also not just about that, design systems are everywhere. And I will write about this too at some point…
Yay! God…that to-do list is endless 😒
Since defining it this way doesn’t really allow our brains to make connections with things we already know… I use a metaphor to talk about what is a design system for me. Because it is NOT just a UI kit, but you pretty much all know this by now, right? …Right??
In a far far far away land, a magical book appears …
Where you can read documented decisions about construction blocks you need to build your castle. You and your team start to build those blocks and use them in the good setting and with the good purpose. The castle starts to look like one and you can invite more people in it! building a bigger one or improve on that very weird drawbridge you built 3 month ago.
What, why and how.
Even if the outcomes seem to be pretty positive about having a design system…well it can be quite the opposite. Like any trend effect, questioning it before thinking that this is the answer to everything, is a good call. If not, I wonder what is the difference between a machine and a designer, (But that is written here).
It is very tempting to introduce best practices very early, but that mistake can cost you and a company a lot. If a design system is a tool, like a hammer for example, using that hammer to cut a piece of paper is not the right one. You invested money on that hammer and the effort to use it for nothing or a very unproductive way to cut that piece of paper. Like, it’s probably a mess by now. Everything is about goals and the context. A full on custom design system for an MVP that you will probably be questioning in a month or so? You think you’ll be able to question it as much as it should be if you invested so much on the production? Think again?
The first learning was that a design system can be dangerous.
It is no miracle recipe to product making. Sometimes the answer is not “design system everything” , it is more effective than to try and frame yourself in too much rational systems when things are moving and questioned fast.
To make it short: there’s a time and space for everything, your job is to know when it is and when it’s not.
A few questions that helped me with this:
• What’s the priority and why?
• Is it a component that is for the product team or the design team?
• What are the key components of the product at this stage that you know will be reusable and developed?
• Have you selected the tools and softwares to match your goals and study the impact if you change or remove them?
• Is the process defined and commonly distributed & known among the people who will work on this?
Growth and change.
When we make decisions we have to make up our minds and get clarity about whether it’s good or not, we visualize a balance between costs and benefits. We perceive things as a cost oftentimes because to decide is also to renounce. That process is framed in time and space, what is good now might not be tomorrow. Tomorrow you might change your directions, address a new market that hates that blue you chose, those rounded corners or that dropdown isn’t really accessible anyway. Suddenly it doesn’t speak to your audience, the needs changed, you expand to new geographical markets, and you need your product to be in Japanese…etc.
At some point you need a blueprint and the design system will support all that. So the thing is, that we need to build stability in something very unstable. There are no shortcuts to it, but to simply embrace that a product is like an ever shifting platform on which a company will speak for itself.
It’s both beautiful and a mess. The design system is trying to make sense of that mess.
The second learning is that change is a part of the process (but also life itself when you think about it, it’s hard but this is the way…) so if you look at it with a perfection bias… well you might sit on some gold mines that very few seem to agree on for now, but also not. Your system needs to embrace that change, to facilitate that change, rather than to set in stones some decisions that will, for the greater good, be challenged and refined over time.
To make it short: Scalability is not so much about being able to build fast it’s also being able to change fast, choose your battles.
A few questions that helped me with this:
• Are the interests separated, or does it have strong interdependence?
• What are the UI constrains of the product?
• Is it quick fix or long term fix?
• How much time the simplest change will cost the team at each level, like a text style for example?
• Do you know where your front debt is?
Opinions and decisions.
One of the major issues about design is that it’s visible…
For the best and the worst of designer's wellbeing, our work brings out opinions. People are entitled to their opinions, especially if they have something at stake in it. Now, to have opinions is great, to make decisions based on that is another thing. I don’t blame, I get that sometimes people project their own image into the things they do… This is especially noticeable on looks and feels topics because it is basically like seeing and feeling personality. Yes, your brand is “someone” but it’s not you nor the product itself.
Since the design system of a product contains the identity of a company and the product, it is very tempting to say no to something you don’t personally like.
This is where it’s important to communicate your thoughts process and how you ended up on this solution as a product team. Tell the story, so everybody can tell it for you too, and don’t fall for bullshit (but that is said here).
The third learning is a major issue in making anything efficient. Decisions making should go back to the team that works on the specific subject. If you don’t have your hands in the discovery, problems, solutions, research you shouldn’t make the final decisions. You simply don’t have the expertise so why do you need to validate it? Trust your team and let go of control, you don’t gain anything anyway doing it.
To make it short: you can’t decide if a book is good without reading it just because you heard about it.
A few questions that helped me with this:
• Are each role and missions defined and orchestrated together?
• Where does friction happen and why?
• Is the design/tech process is shared to other teams in a way they understand it, so they can comprehend what’s at stake?
• Are your decisions backed up, documented, and how do you share it?
• Where does it hurt you if you hear no? (this one optional but soon enough you’ll see that your ego is your enemy sometimes, most of the time…alright, all the time)
Thank you if you reached the bottom of it.
I hope my mistakes can help in any way, shape or form, and that’s what this article is about. I’ll get more into the subject and share methods on specific topics such as tokens, handoff, documentation and so on … (that both worked and didn’t).
Stay tuned if you’d like. Bisous from la 🇫🇷.
See you soon,
A.
Credits : The illustrations used in that article are the property of a project I worked on and that you can see here: https://www.getnobullshit.com/
If you use them, please credit the same link, or I’ll bite. (thanks ❤)
