PRODUCT DESIGN
Widespread mistakes made in the creation and scaling of design systems
5 things you need to think about in defining strategy and organizing the design team
We’re all already pretty familiar with design systems. Recently, this topic has gained considerable popularity. It seems like hype is over, but many product companies are actively involved in their systems creating and getting their first bumps now.
In this selection, I would like to review some frequently observed mistakes when my colleagues are sharing the workflow of the design system in their projects, complaining about how complicated their development is. Meanwhile, they often express that it would probably be easier to live without it. Maybe it is so.
I don’t claim to be an adherent of adding bureaucracy to projects. However, I firmly believe that if you build it right, all your components could play a symphony, similar to a smoothly coordinated orchestra. I think it’s what your product needs.
1. Creating a design system from scratch where it is not necessary.
It sounds crazy. But regrettably, this is the most common mistake made by teams starting on a product. They build their design system rather than buying an existing one. Considering that in some cases, they could have done with the UI kit at all.
Let’s try to draw a parallel. Now, let’s imagine that you are a beginning entrepreneur. You have start-up capital, and you need to decide how to house your employees. There is a 99% chance you will rent an office and do a quick renovation rather than buying your premises. This is the right thing to do, as spending a great part of your capital without prior validation of your business model is very risky.
Also, there is no reason to make this investment at an early stage with design systems. Moreover, if you buy real estate, you can immediately know the price, and when you create and maintain a design system, the cost is generally higher than you expected.
Consequences of the mistake:
- Loss of a huge budget when you start the product work.
- The unplanned deceleration in the process of your product creation.
- The transition to a hybrid model of advanced UI whale during product development. Reorienting of staff also engaged in the creation of design system.
What can we do to prevent it?
There are ready-made systems in the market that can fill all your product needs at the start of its creation. They typically include a set of components, patterns library, ready documentation. They also provided with support and regular updates. Some famous products as Twitter, Spotify have gone this way.
2. The process of creating and reviewing new components is overloaded.
This problem is often seen while extending library components.
We are often inspired by the experience of large companies when learning about their current processes. However, we forget that they have come to this model over time.
What do I mean? So let’s take a look at the path of creating a single component in a large and evolved design system.
For each of these stages, it takes about 1–2 meetings of the different levels of staff. However, if there are difficulties at any stage, additional calls and discussions are possible. Thus, one component may take several weeks to complete.
It looks logical for companies like Atlassian or IBM. But, sadly, this model is also sought by younger products. Thus, they slow down the speed of creating components where they are extremely needed. Accordingly, it affects the design speed of the product itself.
The additional braking factor is the overloaded accounting of component development status.
I have seen a version where the staff of 3 professionals working on the system had to mark status in several tools simultaneously. They created a base in Excel, a table in Notion, and a separate space in Confluence. Also, these things are adopted from larger companies.
Consequences of the mistake:
- The extreme slowdown in the creation of new components.
- Time loss in case of irrelevant created component.
What can we do to prevent it?
Occasionally, it is necessary to optimize the validation and review components. It is necessary to eliminate unnecessary steps that have no value. The important thing is to keep your eye on the ball to understand which part the component creation process takes in your product life. And whether it corresponds to the pre-defined product development plan.
3. The focus shifts away from the design of the product itself.
You probably have heard the saying that design systems are killing creativity. There are many articles about it on the Internet. The lack of freedom is mentioned almost everywhere to generate fascinating, creative solutions. The reason for this is the restrictions that the library of patterns and components imposes on the designer.
Of course, it’s possible that someone really wants to have all the freedom and pursue extraordinary solutions. In this case, the design system is unnecessary at all. But mostly, I heard this opinion when experts began to work on the system too early, and the work balance over product was lost.
At the time of active design system implementation, the max percentage of resources that must be allocated comes to 50%.
After the main part of the component and pattern library is built, and basic documentation is written, the support is usually provided by no more than 10–15% of resources.
The important thing is to realize that the system implementation should be started after the main concept of the product is ready. This means that a full UX research is done, all the main high-fidelity pages of the future product are formed and tested.
Consequences of the mistake:
- Unexplored potential in product visualization.
- Resource loss for recycling components.
What can we do to prevent it?
The allocation of resources to activity team streams is always a floating issue. Keeping a perfect balance between building the system and improving the performance of the product itself is challenging. In this case, we need to remain flexible. Meanwhile, we shouldn’t save time on planning, setting goals, and coordinating with all the product’s stakeholders.
4. Incorrect team composition and scaling.
Imagine that you are building a house and hire builders when necessary. In the beginning, you need to dig a pit, and you ask for excavator services. But then the bricklaying begins and the bricklayers do their job. If you haven’t had time to recruit professionals to plaster the walls on time, you’re more likely to ask the bricklayers whether some of them can perform this service. In this way, some specialists also part-time perform other work on your future home.
Something similar occurs in the construction of the design system when you don’t have a correctly composed team. The only difference is that overlapping responsibility is unavoidable at the start. For instance, the interaction designer will be the researcher, the architect of the component, and the executor of its final design.
This is a normal situation for starting work on a system. But as you progress, you must scale the team appropriately. To understand which specialists and how many of them to hire, I suggest returning to the scheme of creating a component, we discussed earlier. As you remember, this is the way of creating components in a large developed design system. I will provide the minimum composition of the team, which should be enough to work at this stage of maturity, below:
And this team composition may be enough to start a design system:
Consequences of the mistake:
- Low speed of design system construction.
- Low-quality implementation through the work of non-core specialists at certain stages.
What can we do to prevent it?
We are back to defining strategy and planning. It is advisable to make footnotes for each step in the roadmap and specify the composition at each stage of the system’s development. Accordingly, it is better to launch a search and recruitment campaign about 2–3 months before the next stage in the roadmap.
5. The lack of evolution in system design to favor scalability.
With the extension of our system, we feel like we’ve done something huge. The formidable construction will cover all our UI design needs and optimize our work in general. This process has taken a long time, possibly several years. Technology has certainly changed during this time. Everybody remembers the days when product design was mainly designed with Adobe Photoshop.
At the time of writing, there is a flowering and absorption of the market by Figma. This tool has revolutionized the design and cooperative collaboration process, and it is rapidly evolving. The auto-layout and variants are appearing, more systematic updates are announced. It is similar to front-end frameworks, where React has long surpassed Angular in popularity. All of this may not be relevant in 2–3 years. It is important to be aware of trends and tool updates.
As we discussed before, your design system is a living organism, and it is equally important to allocate the resource and time for its renewal. In the case of the purchase of an existing one, this responsibility rests with the creators. The only thing you have to do is to make sure that your final interface has no unexpected bugs caused by component updates.
If you develop a design system by yourself, all responsibility regarding its relevance rests with you. Thus, you always have to strike a balance between scaling up and upgrading existing components. Unfortunately, the majority prioritize the first, which leads to a loss of relevance, and strongly affects the performance of your constructor in the future.
Consequences of the mistake:
- Resource overrun to keep the system design up-to-date.
- The difficulty in recruiting staff and motivating them to work with outdated technology.
What can we do to prevent it?
It is necessary to keep abreast of trends and react to the appearance of new tools and frameworks in time. It is necessary to study them and assess the various scenarios for further development, including an immediate transition to new technologies or a slow transition with a gradual allocation of the resource.
If the decision needs to be made while building a design system, a fairly common option is to refine along an already agreed with stakeholder’s path, using a minimum allocation of resources for a parallel update to the existing library.
Building quality and the well-coordinated constructor is a process, which complexity is usually underestimated. Unfortunately, everyone makes similar mistakes that they don’t like to recall publicly. I have experienced it myself and have seen my colleagues burned out along the end of the arduous journey of forming libraries and putting the product on a new track. But I still believe that design systems are the future and that interface design will become automated.
