Sometimes you have to say politely “No”
Argumentative rejections are part of the job of creating and maintaining design systems.
There are a large number of articles that teach how designers can say no. This is mostly about freelancers and how to interact with difficult clients. There are also articles with tips for dealing with Product Managers. However, what about when you’re supporting a Design System? What to do with conflicting requests from other designers or developers.
I don’t know what I’m doing yet…
If you’re not an expert and you’re just starting to create a design system for your company from scratch, you may not know what direction to take. You can, of course, read several articles with recipes on “how to start,” but sometimes there is nothing better than personal experience. Trying something, making mistakes sometimes, and learning from mistakes. Being open to new things. Be a “Yes, let’s try” person.
You have to be as flexible as possible in such a situation. However, document your decisions if you don’t want successful decisions to remain “black magic” and unsuccessful ones to stay as an unknown coincidence.
I don’t just mean write down the decision itself, but how you (or others) get there. Arguments, etc. Yes, this can be, sometimes, difficult. Especially when the decision was intuitive (gut feeling). However, if you learn to question yourself and others, you can eventually begin to understand the source of the idea.
Such documentation will allow you to further understand cause-and-effect relationships and learn what works and what doesn’t. And next time if you see that a new proposal fits a known pattern (or goes in the same direction) — you will be able to point this out to others. That is, you will learn to give reasoned reasons against risky solutions.
I’ve seen this somewhere before…
You can always ask the community for examples when it comes to bad decisions. Designers (and many other professions) like to make lists of what not to do.
There is a large cross-section of articles in the category “10 Worst Design Decisions” and the like. However, concerning design systems, the most important will be descriptions of “Good/Bad” practices, “Patterns”, “Do’s & Don’ts”, etc. And it is best to look for them in the documentation of open design systems.
Often such documents provide concise but concise arguments for or against a particular solution, and they can greatly help in analyzing situations arising in your system. And even in your daily design work.
“Do & Don’ts” are a key element of any system design documentation and the earlier you start documenting “Good/Bad” practices for your system, the more questions, and misunderstandings you will be able to avoid.
“If it’s not documented, it doesn’t exist”
The documentation is a commitment. But also guidance on “what could/should I do”. After all, designers often make questionable decisions because they are not aware of what should and should not be done within the design system. In its absence, the statement “anything is possible” is a reasonable thought.
But here it is important to emphasize: documentation is not about bans. Documentation is designed to explain how the system works and reasonably indicate what is worth doing and what is not. Accordingly, if the designer (or developer) is only driven by “I like it this way” and it contradicts the documentation — you have a reasonable and justifiable reason to refuse, referring to the documentation.
Documentation helps to set a good example for others to argue their ideas. And turn ideas into solutions that will help take your design system to the next level.
Design library ≠ Design system
Often problems arise when users (or contributors) don’t understand what a design system is and think of it as a design library. Many designers are used to dealing with off-the-shelf design libraries and having to modify them to suit their needs.
“I like this UI-Kit, but it was created without any consideration for my use cases and so I need to customize it”. Sounds pretty reasonable, doesn’t it? Yes, if we are talking about third-party solutions of which you (or someone else) will only use a small part. But in the case of an in-house design system, this might lead to chaos.
Something similar to this, but a little different….
In my opinion, the hardest thing is when users request small changes. Quite small changes:
- Add the ability to use icons in headers.
- Change the order of blocks in the list.
- Show 3 buttons instead of 2 (defined by a component).
The difficulty here is that there is often no reason not to. If it is not directly contrary to the component logic. But here we are faced with 2 important points:
- Consistency of approach with other components.
- The complexity of implementation in code and design components (Figma, Sketch, etc.).
Consistency
First, you need to figure out if the pattern intersects with some other component. To do this, you either need to know all the components and their behavior by heart or go through each of them and see if the proposal conflicts with any of the other components. If there are the slightest conflicts, it is necessary to discuss the proposal not in isolation, but in the context of the behavior of several components. This may often require inviting more people into the discussion.
The complexity of implementation
Very often, what looks like a simple solution in design can require a huge effort in development. Perhaps because the current architecture is not flexible enough. Perhaps it just goes against the basic standards/approaches used in development. Theoretically, almost anything is possible, but some things will require more effort. In such a situation, you might need to understand how important these changes are: “Nice to have” or “critical needs”.
We are servants, not dictators
The design system is a product. But it is a very specific one. While the success of the majority of products can be measured by how much money they make, for a design system the main indicator is how many users use it and how much it makes their life easier. In other words, a design system is “The most honest product” 😅. And that entails a lot of responsibility. We don’t just need to make the best of what the customers want, but also help them understand the consequences of each questionable decision:
- a lack of flexibility in the prospect
- delays in solution development (due to the complexity of the solution and its maintenance)
- the need for cascading changes to other components or agreements
Don’t be attached to your ideas
Ultimately, the design system is about the users (designers and developers). So you have to be very attentive to them. After all, without them we are nobody. And if the edits are reasonable and do not break anything — why not make them?
All the reasons to say “no” are just about ensuring that we create the product the users need, not the one they want.
When asked about customer input in the development of the Ford Model T, Henry Ford famously said, “If I had asked people what they wanted, they would have said faster horses.”
