The Importance of a Design System When Building Products

The Importance of a Design System When Building Products

A few weeks ago while interviewing a developer for Codelitt, I asked if he had any questions for me. He only had one,

“Would I be the one creating the design?”

He may have thought that my video froze because it took me a while to realize that he was being serious. I was sitting there wondering to myself, Why would a developer ask that?”

After I came out of the shock, my answer was a simple one, Of course not, we are not savages here. He laughed, I laughed, but even after it was over I couldn’t stop thinking about it. While processing it, I found myself having flashbacks to similar situations I’d seen in the past.

Not so long ago, I had a friend that was starting a marketing agency. She needed a developer and so, being the closest reference she had to that market, she reached out to me for guidance on how to go about hiring. Aware that she didn’t have any experience with web development, I asked about her plans for the team. “It’s not as simple as just hiring a developer of course. Naturally, there will need to be a designer on your team,” I said. I couldn’t have been more wrong. When I voiced this assumption to my friend her response was:

“If the engineer is good he will bring the designer with him or design himself.”

After trying to explain that it didn’t work like that, we agreed to disagree. Needless to say, her agency never kicked off.

Nowadays I always have design by my side – and am quite happy about it! The interview with that candidate lead to some processing which stirred up some questions though. The one I’d like to dive into today is:

Is having a designer on my team enough to guarantee a nice looking output and a maintainable stylesheet?

After some careful consideration and comparing situations across projects I came to the conclusion that no, having a designer in my team isn’t enough. The reason is simple: adding a specialist to a team doesn’t solve any problem if there is no process behind that.

Let me give you an example! In reviewing one of our oldest projects I came across this jewel. Below you have the colors.sass file

As you may notice we have quite a few varieties of blue! But where did the blue3, blue4, and blue5 go? I don’t know.

This situation is a good example of what happens when we leave a set of engineers to name colors. The image above is an excerpt from a file that contains 44 different types. In this scenario, we always had a designer working together with the engineering team. A possible explanation for how we ended up in this situation was that we rotated the engineers quite often. On top of this constant change in staff, we also didn’t have a design system for new ones to follow.

When it comes to building pages, there is a lot that engineering can copy from the design system. Color naming is the most obvious, but the same principle applies to componentization. By having the design system we can develop our components with a clear goal: reusability. For example, the first two buttons below are on our website while the third is on our blog.

The Importance of a Design System When Building Products

And we can even build the variations together at the beginning of the project! (see below)

The Importance of a Design System When Building Products

Our engineering team has faced the issue of not having a design system in place when working on a past project. In that particular situation, we didn’t have an idea of how many options we would need for buttons. We also didn’t have a clear understanding on how we would reuse them. In the end it fell to the engineers to make decisions about not only the type of buttons, but also how they would behave in specific ways rather than a generically.

If we’d had design system in place at the beginning of the project, we could’ve defined a good reusability base for the key components saving us time, money, and lots of energy.

The Importance of a Design System When Building Products

With a design system we can guide our engineers better and efficiently direct our efforts in the long run. After we build the basic components, more often than not we will end up reusing them rather than creating a new one for each specific case. This way we can focus on building features that the users will love all across the board – no need to recreate the wheel.


  • To find out how to build features that your users will love, check out our post on User Testing!
  • To learn more about Kaio and his journey to become a leader in tech, check out this interview!

Source: Codelitt