Design systems: we often build castles over ancient ruins
Creating design systems in companies is often like building new houses on top of existing ones: we need to rely on old foundations and communications.
Why is this happening?
A design system is a utilitarian product that a company uses to optimize the development of its core product (or several). And so the strategy for creating (or integrating an existing) design system for a company is based primarily on what is most convenient from the perspective of the core product. And not from what is best from a design system point of view.
In practice, this prioritization means that the business is interested in the design systems team to maximize the use of what already exists: architecture, API, and others. Meaning, build a new system on an existing foundation.
What is the main advantage of this approach?
Often a design system starts as a project: the team creates new components and APIs and gradually replaces the corresponding parts in the main product with them. For example, by implementing tokens, the team can start cleaning up the product code from hard-coded values.
In this case, the company will not have to stop the development of the main product. It will only need to allocate a little extra time in some sprints to implement new elements and adopt them. It can be compared to short-term pit stops at races, where the service team changes tires, refills fuel, etc.
In racing, you can’t change the engine (to add power) or the body (to improve aerodynamics) on a pit stop. Besides being against the rules in sports, it would simply take too much time.
In a product company, a major architecture or process change could require a significant investment. Sometimes even freezing all product initiatives.
What are the downsides?
Legacy. A major bane of development: often only things that no longer work are getting attention. In large products, this eventually leads to the fact that the code becomes like a patchwork quilt. Which may fall apart at a critical moment.
Another obvious disadvantage is that you can’t always choose the “best” solution. Maximum come to a compromise. In the worst case — you will have to use outdated solutions.
When design systems are implemented in large companies, it is not uncommon to face mistrust and skepticism from the teams. This can make it very difficult and slow down the implementation of design systems. After all, the implementation of such things often requires teamwork and it is difficult to expect a good result if individual players are not willing to play harmoniously.
“Do we have to? What if we don’t?” (→ Reluctant)
“What if we didn’t use your system to do it?” (→ Individualist)
Nathan Curtis
To avoid such situations, it is necessary to get the support of the management: not only to obtain official status for the initiative, but also to provide it with the necessary resources.
What are the alternatives?
Start from scratch
The first thing that comes to mind when talking about an alternative approach is to start from scratch: build a new architecture (if required) without being tied to old solutions. Taking into account only the required functionality and capabilities. This can be done without stopping work on the existing product by building a new one in parallel. It’s like building a new building next to the old one with all the new: foundation, communications, etc. And when it is ready — relocate all the residents from the old one into it.
There are many examples of using this approach. For example, the Apple Macintosh was developed in parallel to the Lisa II as an alternative.
The main disadvantage of this way is that it is expensive. It will be necessary to create a startup within the company and allocate the necessary resources to create a new product. Since it is not very reasonable from a business point of view to make such investments just to change the architecture, serious platform changes are often combined with a complete rethinking of the main product.
“Blowing up the old and starting fresh, bigger may be triggered by an external force — an executive mandate, brand refresh, or tech replatform.”
Nathan Curtis
Strategic approach
Relatively recently, Hamburg decided to try to reduce the noise of the autobahn running through the city by moving it underground. But because you can’t just simply stop the autobahn from running they decided to cover it with a “roof” and plant a park zone on top.
They managed to successfully test the concept on a small stretch of road and even to increase the number of lanes in addition to the noise isolation. Now the project will close all other pieces of the autobahn that pass through residential areas.
In my opinion, this is a perfect illustration of a strategic approach: defining the future vision of a product and building a strategy to achieve it step by step, changing the product without interrupting its operation. Planning such an initiative requires not only a great understanding of the product and all its parts but also a good alignment at all levels from company management to individual small teams. And the more people, the more resources and processes are required to support alignment.
In a small company with a small number of developers and designers, it will not be too expensive to start systematizing components and achieve consistency. In companies with a large number of teams, you might need more detailed documentation and processes in addition.
With proper planning and a successful pilot, the strategy for implementing a design system can be “sold” to management. And here, in my opinion, there is one interesting thing: the larger the company, the more you need to think on a bigger scale. Define what kind of design system you want to build and what it can bring to the business beyond consistency.
