Get best of the week

The dark side of the design system and what to do with it

Hello!

My name is Lesha Svirido, I am a leading product designer at Alfa-Bank (this is what we do online banking for business).

In this post I will tell you about design systems. Yes, they are written about them as often as professional burnout or remote work. The thing, frankly, has long had time to become hype, fill its edge, bring joy and disappointment, but it still remains a necessary thing. Under the cut - about why the design system is cool and how it helps us in our work. About why it's not always cool, what design systems have dark sides and how to resist them.

And also a link to the Alfa-Bank design system.



Let's start with the obvious. People often think that a design system is designed for designers to make their life easier, that it’s such a convenient set of components that is always at hand in Sketch or Figma. But this is called a UI kit.

The design system is an integral thing for the product team, which helps developers as well.

Why design systems are cool


1. The issue of design scalability is excellently solved.

We have a lot of products in our business bank, and when we launch something new, we will actively reuse these or those elements. It would be possible for each launch to sit down and draw new elements. But this, firstly, time, and secondly, violates the consistency, which I will write more below. Therefore, we reuse and are not shy. For example, when we recently launched a new digital loan product, we reused about 60% of the previously launched products, and thanks to this we launched the product very quickly.

2. Helps with debt management

And not only a design duty, but also a development one. Recently, we had to go and change the green color that we use in the products to another green color. Previously, one would have to go and negotiate with the owner of each product, they say, look, it was so green, and now it will be like this. And here is why. Yes it is. True, it is necessary.

Instead, we just changed the generally accepted green at the level of the design system in a few clicks, and all teams now have new (correct) introductory notes about using green.



3. Helps maintain consistency

We have more than 30 products in the bank for legal entities, and it is with the help of the design system that we can normally maintain the consistency of all of them. Why is this important? Suppose a client took out a loan six months ago. Today he decided to arrange acquiring. In six months, he will open a deposit. Throughout all this time, at every step of the way, he must perceive the bank and all its products as a single whole. And if in one product something looks different than the same element in another product, this is not very correct.

4. Rapid prototyping

Perhaps the only plus of the design system, which is actually sharpened more for designers, rather than the team as a whole. To test certain hypotheses, you need to make a prototype, but with its help it is not always possible to fully reproduce one or another flow that is necessary. Then the designer, together with the developer, create a prototype that they are going to test.

5. Improving usability

We have a lot of components, each of which has already been tested by battle on users. That is, we know for sure that users perceive this or that element quite unambiguously, without discrepancies and calls to friends for clarification. These are working components in which we have previously sewn up various variations and states, all this is already in the library.



And everything seems to be cool, right? The design system is wonderful, you need to use them always and everywhere. But there are dark sides.

The dark side of design systems


1. Limitations for new solutions A

designer can come up with excellent solutions for a product and bring it to the developer. What he shrugs, he says, they say, sorry, bros, we don’t have one in the library, we can’t do this. And here everything rests not only on the desire of the designer to “make beautifully” - additional factors must be evaluated. For example, the time to develop new components and the appropriateness of this process, because the very value that the client will receive after the update is not very clear. Plus a budget. Yes, in an ideal world, everything related to the budget is never a designer’s problem at all and should not affect his creative impulses.

But we live in this world, so a number of desires of the designer may well be considered inappropriate from the point of view of the budget.

2. Slow product evolution

Of course, the design system is developing, but not always with the speed with which you want. Take the product here - it must develop continuously, because technological solutions may appear new, and the user’s Wishlist can be supplemented with something else, in general, forward and forth. You can’t just make a product, give it to the user and forget / score. It is very important that both designers and the rest of the team continue to work on the product, improving it and taking it to a new level, bring something else, necessary and useful to it

It's about the same story as with a phone or watch. One used to simply provide voice communications, others showed time. Today, these are gadgets with a bunch of additional features and functions, without which the end user cannot imagine them. Who needs a smartphone now, in which there will be no cameras or multimedia data transmission at all? And smart watches that show time, but are devoid of notifications and an alarm clock?

This applies to digital products no less, and sometimes more.

Therefore, it is critically important to communicate the importance of product development to products. Talk about new features and new user segments that will help increase meaningful metrics. And it is always useful and good.

3. Spoiled developers

When developers work with a design system for a long time, they sometimes begin to respond to incoming requests with the mantra "This is not in the design system, sorry, we can’t do this." And here the thing is actually not that they are lazy, or they can’t, or simply don’t want to, but that they simply have such a pattern of behavior, like if they come to you with a request, you need to go to design -system, pull out the desired item from there and insert it. Such is the design system copy-paste.

Accordingly, if there is nothing in the design system, then there is nothing to get. And you need to draw it from scratch. Instead with a designer. Here, as practice shows, often everything rests precisely on the problem of communication, not everyone likes to go and agree on something in principle.

What to do? It is necessary for the designer to clearly understand why he is drawing this or that layout. And so that the developer also understands this, and just as clearly - why are we sitting here and figuring something new instead of rummaging through the design system and reusing everything happily. And then you need to scale this approach to the team as a whole. A team is a combat business unit, it is necessary that everyone understands what exactly he is responsible for.

4. MVP remains MVP The

main purpose of the existence of any self-respecting MVP is to test some hypothesis, after which it will evolve vigorously into a product that benefits customers and money for business.

But sometimes it turns out that the MVP, which worked, simply remains as a product. This is the case when the approach “Works - do not touch” is applied incorrectly. Yes it works. The hypothesis works, for which we did the MVP test. And the fact that MVP works only means that the time has come to bring it to mind (read - to the product).

No matter how trite it may sound, it is important to convey to designers and products that now they are sitting and sawing it MVP. That it is something temporary, the first step, a test of hypothesis. And the task of the team after verification should always be to create a product.

How to deal with it


1. Plan and establish processes.

You and your team should understand what you are doing today, tomorrow, in a week, at the next sprint. And also - why are you doing this. Otherwise, the meaning of the work, in principle, disappears.

If this is not done, chaos and a situation are inevitable, in which everyone just sits and unites together their own pieces of backlog.

2. Team enthusiasm

Yes, it sounds like these creepy “dream team, cookies and people with burning eyes”, but the interest of each team member in the process is more important than it seems. Of course, you can make a product with the hands of people who do not really care what they do and for what, and such a product will also work. But if there is an opportunity to do this with like-minded people - it is in every way better.

3. Success metrics

They must be identified, recorded and monitored for their compliance and implementation. You drew some page - and now you can see that thanks to it the number of customers has increased. And it’s good for a person, he sees that what was created with these hands really works, and it is useful for business as a whole.

4. The design system is not the police of design.

Here it is still important: designers, including new arrivals, may begin to perceive your existing design system as a guide to action and the last resort. And a story can turn out in which the designer has a great idea for using the component, he goes to the design system, does not find it there and decides that the component is not needed, that someone has already suggested it, but they have rejected it. As a result, it turns out that a good idea fell off at the start.

If there is nothing in the design of the system, this means that it can find a place for itself there. As I already wrote, the design system should develop, acquire new useful components and scenarios for their use.

5. Iteration

I will not be original, when working with a design system (and indeed when working), break down tasks into steps that you are able to complete and calculate, instead of just going and setting a task like “make it cool”.

What to read


Design Systems Handbook
By Marco Suarez, Jina Anne, Katie Sylor-Miller, Diana Mounter, and Roy Stanfield

Awesome Design Systems

Yuri Vetrov on Interfaces

Alfa-Bank Design System

And one more thing. Design systems have proven themselves for use in large companies, where there are many products, designers, components and more.

Because of this hype around design systems, they are trying to implement them everywhere, even in small web studios for 2-4 people, where each little bit of a designer writes in PHP and administers servers. Like, since it works everywhere and it's cool for everyone, it will be like that for us too.

Will not be. If you are a small startup, you do not need a design system for the sake of the design system itself. Start simply with a good UI kit and move on.

More articles:


All Articles