Build a Design System without thinking about building a "Design System"

So, you came up with an idea of building a design system and you propose that to your team. But the moment you do that there are some common questions that pop up

• Building a design system sounds like building a palace. Maybe we are not at the right stage to do it.
• It might be too early for us to build a design system.
• Design System will take too long to build, we can’t invest in it.

These are interesting questions and I guess most us have been through these questions in one form or the other. It’s also for a fact because we are part of the industry(or startup culture) where things move at fast pace and everyone is just hustling. People usually want everything at a rocket speed. It’s fine there’s nothing against it. But there are certain principles that remains constant regardless of the speed for building products. One such thing is Design System.

Regardless of all the questions, you know that it’s worth it and you have decided that you really want to build a design system but how do you deal with the baggage of building something “BIG”? You don’t. It’s just a perception. Let’s see how we can change it.

Let’s go one step backward and imagine we are a very early stage startup figuring out our product. Here’s the sequence of events that may happen:

1. We start with the idea of building an amazing and beautiful product.
2. We start putting down our thoughts about our product by defining the flows a.k.a defining the User experience of our product.
3. Until now things are just black and white so to add some charm to our product what we do next is we start by defining some colors for our product which also help us think about brand colors so people can relate to our product instantly. Few examples to relate to what I mean:

• As soon as we look at Orange color we think about Swiggy.
• As soon as we look at Red we think about Zomato.
• As soon as we look at shade of Pink we think about Myntra.
• As soon as we look at Black and Copper color we think about Cred.
• As soon as we look at Green we think about Dunzo.

These colors have left a mark in our heads so we always relate with them whenever we look at the shades of these colors. So, the point here is we end up defining the color pallette to make things consistent across our product. Isn’t it?

4. Next, we decide what fonts and their different sizes we want to use across our product to define textual hierarchy, which means we are thinking about typography in technical terms.
5. After this we have enough things so we get started and begin with putting some elements on the screen and we realise okay I need a consistent spacing between them so we end up using similar units of spaces across our product.
6. Then, we need certain elements to have specific width and heights so we end up using similar units of sizes across our product.

Up until now we are not even talking about “Design System”. Now, think about if you were to stop doing these repetitive things in design/code what you would have done?

• In Design Tools: Define these repetitive things as Styles(in Figma)? Or maybe document them in one of your pages in Figma as guidelines?
• In Code: Define them as collection of variables at a central place as constants?

Hmmm, so now if you look at the above points we do these steps regardless of what stage of the product we are in and to put them in simple terms here’s what we already have defined until now:

1. Colors
2. Typography
3. Sizes
4. Spaces

Did you realise what have we done unknowingly? We have defined Design Tokens.

Note: We might not have a full fledged token system but at least we have started somewhere to bring consistency into our product.

What’s next?

You start with designing the basic elements that you will be using to build your product let’s say it’s in early stage and you’re building an MVP. Hence, you know there are few basic elements(without many variations and complexities) that you’ll need at the moment. So the next step is to define these basic elements for example Buttons, Text Inputs, Headings, Links. You’ll use your Design Tokens created above to build these elements. These elements are also known as atoms(smallest unit of your design).

Let’s take a pause here and revisit what all things we already have done:

1. Define Tokens
2. Build atoms using the tokens

We didn’t do something extra ordinary, it’s basically the lifecycle of any product. We just took an initial extra step to store and reuse things. And, this initial extra step will save us hours of fixing design inconsistencies in our product like “the border radius of a button is 2px on home page and 4px on about page”. Also, this has laid our foundation or building blocks of a design system on top of which we can build and evolve.

Whoop! Did we just build a Design System without explicitly defining that we are building a Design System? Yes we just did(though a tiny one)! 🚀

Wrap 🗞

Design System is basically set of principles and guidelines that we use to build our products. It’s never ending and it keeps on evolving. Since we start with defining our guidelines in form of tokens it becomes much easier to evolve our Design System as our product grows and matures as there will be more use cases that will pop up in our product’s journey.

You might have a question that with growing teams/bigger companies how do you scale and prove worth of Design System? Stay tuned for the next post 😉

Are you building or have already built a design system at your company and like to share your stories? I would love to hear them. You can write it to me or you can DM me on Twitter.

If you like this then don’t forget to
🐤 Share
🔔 Subscribe
➡️ Follow me on Twitter