Building a product without a design system leads to huge design debt
that sometimes will never be repaid
Product designers often work on new projects and know that some stakeholder groups want to launch the product as quickly as possible.
Because of this, many designers ask:
Is it better to create the design system now or wait until we have more time?
My two cents on this topic: If you don't build a clear design system from the moment you start designing the product, you have two options.
- It won't happen.
- After the product is developed, creating the design system will take much more time, effort and money.
If the product team launches the product without a design system, it's a design debt, but not like taking any other design debt. This design debt will often never be repaid due to the "high interest."
My purpose in this article is to spotlight this topic and explain why building a product without a clear design system is a detrimental design mistake.
What is design debt?
You'd like to buy a car that costs 25,000$, but you've got only 10,000$. To buy the car now, you must get a loan from your bank; otherwise, you'll have to wait another year to save all the money. So you choose to get the loan, buy the car now, and pay interest.
In the same way, when we're building a product, we want to get it out fast, so we prefer to move forward before the design process is done. It's the difference between your product's current and ideal state, and this difference is the design debt.
It could happen because of a deadline, a limited budget, or simply because the team isn't experienced enough to do specific designs right.
For example, the team can skip some essential processes like:
- Conducting a usability test
- Solving different edge cases.
- Design QA
- Build design system
All these shortcuts are like a loan to get the product out faster.
One additional thing to mention here is that Design debt is like technical debt (tech debt, code debt), meaning the same applies to code. The idea is to create a quick code solution instead of making a better code quality now.
Design debt on design systems is different from other design debt
Design systems are like the roots of a product, so if you don't have a design system, you build a product without roots.
Take this example: two product teams are working on the same product. One team is working on feature 1, and the other is on feature 2. They want to put a button on the screen. There's no design system with guidelines, so the first team made a button with 8 pixels radius, and the second team made one without a radius.
Now we're going to have two different button designs. You might think that's no big deal; the team has to pick one design and change it. That's true in theory, but it's not true in reality. In reality, the teams won't notice the error or pay attention to fixing it because they have a new feature to work on.
When you multiply it by more cases and add the fact that new people who do not know the product are constantly joining the team, you will have a significant design debt that's difficult to repay and sometimes impossible. It is because the design system affects the whole product, not just a single feature.
I am talking about a design system, not a UI kit
Just a quick note before continuing: I don't mean the UI kit that product designers have in Figma when I talk about design systems; I mean a real design system with guidelines and tokens that aligns the design with the code.
Without a design system, your product will have a big design debt
Let's see what happens when a design team works without a clear system.
A design system is a language for developers, product managers, and designers
A design system is like a language. Communication is better when all the developers, product managers, QA testers, and product designers speak the same language. This language makes it easier for members to communicate with one another; if not, the absence of this language can cause friction between members.
Let's take this case. You designed a form with a submit button (Primary) and a cancel button (Secondary) at the bottom of the form. You sent the design to development, but the developer forgot to add the cancel button. If you have a clear design system, you can tell the developer:
"The secondary button is missing. Can you please add it?"
At that moment, the developer needs to add the code and the text, and that's all.
If you don't have a clear design system, you'll have to explain what is a secondary button and its specs, which means wasting time in Slack messages or a meeting.
Consistency will be difficult to achieve
There are inconsistencies in every product, and we try to avoid them, but making the app 100% consistent is difficult. But, if you don't have a clear design system, inconsistency starts from the first moment and grows, and the real problem is that you can't fix it since there are no guidelines.
A design system makes it much easier to keep your product consistent, so there's less room for error. Consistency will help your users understand the product, so the user experience and the visual design will improve. Also, it helps the product team develop new features since the design team aligns with the product logic.
The hand-off from design to development will take longer
Once the design review is complete, the solution is ready; the product designer prepares all the information and sends it to the developers to start the software development step. This process is called design to development hand-off.
When the product has a clear design system, there's no need to explain the specs of each component since most of them are well documented. You need to explain only the flow and logic of the solution.
When you do not use the design system, you must explain every line and color to the developer. Some design tools have great solutions, but from my experience, it is not enough; you must ensure the developer understands it well; so you will need to invest time in the explanations.
Design QA will take more time
When the developers are finished implementing the design, the designer should review it and make sure the implementation fits the design. This step is called design QA.
Usually, it is normal that there is a difference between design and development, but if there is no design system, the difference will grow.
Because the designer has to explain the problem and the developer has to fix it, each design issue the designer finds can waste a lot of time and effort. As well as reducing the team's performance, this process can create a lot of friction between the designer and the developer and reduce their trust.
It will be necessary to discuss every detail with the design team
When designing a product, we must make many small or big decisions. We don't need to make as many decisions when we have a clear design system because the design system guidelines do it for us. Without these guidelines, each decision has to be discussed and agreed upon.
Think about this case: you design a modal, and the modal has two buttons, submit and close. On the top, there's an X icon to close it. Suddenly, a developer shows up and asks.
"Why did you add the X icon if there's a cancel button?"
A question like that can lead to a long discussion. In reality, this case needed to be solved before because modals are an essential component of every product, and there is no need to invent the wheel here.
Now think about how much time you and the team can waste on these small issues.
Developers will try to avoid refactoring the code because of the risk
If the product is developed without a design system, you may notice that the developers will try to avoid adding the design system afterward. It's because the development team has to change a lot of code, which can cause many bugs.
Suppose your system has inconsistencies with the buttons, so you want to re-arrange them and make sure they look the same. You can design it in Figma, and it'll look awesome, but the developers will have to find all the buttons in the system and change each one individually.
But they can't do it individually because it will take a lot of time, so that they will do it in bulk action.
Since they'll do this in bulk action (finding all the buttons and changing them in one click), the process can be risky and produce many bugs.
That's why developers won't want to make the changes, which can lead to more and more design debt.
There are always new features to add, so PMS will not prioritize the design system
Every product team has a lot of pressure to add new features, and often the maintenance of the product gets overlooked.
It takes a lot of effort to build a design system, so when a product manager considers it, he usually prioritizes another feature (who wants to deal with this big problem).
In many cases, building the design system will be at the bottom of the road map, which means the debt will keep growing until it's unpayable.
The cost of creating a design system after the product launch is much higher
Creating a design system will cost much more if you wait until after the product launch, and this is because you have to analyze and redesign all of the existing components.
Additionally, engineers will have to refactor the code and meet new design standards, and QA testers will need to run lots of tests to ensure product quality.
Calculate how long it will take the team to make these changes. You can see how much money this can cost.
At every unclear point, new members will invent the wheel
It's important to onboard the new designers and developers to ensure they know the company's design system. Then you can be sure everyone knows what the product guidelines are.
If you don't have a design system, the product will continue to accumulate debt because the new members will improvise on every unclear point.
Design system debt creates friction within the design team
Design debt creates conflict within the design team because it can lead to disagreements about many elements in the interface.
Consider this scenario; you need to design a new modal in the system, but there is no design system. Therefore, you play with the product to see what the modal looks like. In this scenario, you find two different modal designs, one with the primary button and the secondary button and one with a primary button and a ghost button. Which one do you choose?
You will need to talk to the other designers because there aren't clear guidelines, each designer will push their way, and you won't know what to do.
As a result, your initial reaction will be frustration since it's a minor issue that wastes a lot of time, and your second reaction will be discomfort, as the discussion can create friction between the members.
Scaling the product will be much more complex
A product wants to grow and get more users, and that's natural. However, if the product doesn't have a design system from the beginning, scaling it will be harder.
Each change in the system will take more time, for example, rebranding the company due to growth.
They choose to change color palettes, but it can be more difficult to change colors if the product does not have a clear token system. Every change will have to be done manually, and the designer and the developer will have to work harder because there is no clear system in the code.
The product team should keep the design system up to date
If the team builds an excellent design system from the beginning but doesn't put effort into maintaining it, it's also a design debt. Once you have the design system, invest time every time you need to improve it.
That way, every change will be easy, and the team can guarantee its quality.
To conclude
In this article, I showed why product teams that do not build a design system initially will find themselves with a large design debt that they may never repay.
Firstly, I explain what a design debt is and how a lack of design system differs from other design debts. Afterward, I explained why you should build it from the beginning of your product and what happens if you don't.
In points, I showed that it helps manage the complexity of design and allows the team to focus on creating a great product. I explained how it could affect the user experience, the trust between the designers and the product team, and why building it after the product release can cost a lot of time and money.
Thank you for reading the article. I hope this article helped you understand why building a design system from the first moment is important. Please feel free to share it with your friends or team members, and if you have any questions, please let me know.
If you enjoyed my article, I suggest you follow me and subscribe so you'll receive an email whenever I post.
