How to start a design system — the basics

Design systems may sound scary for an early stage company, but trust me they can have a huge impact on both your MVP and final product. They bring quality, consistency and improve execution speed tremendously. ??

It all requires you to simply choose a different approach at an early stage and the process can be quite unobtrusive. We’ve worked with both established brands and early stage startups and we’ve found out there is a way to build a Design System MVP even for the smallest of startups. ??

On August 7th I was speaking at Blockchain Alliance Warsaw Startup meeting and here’s a short summary of what has been said.

Let’s first consider why a startup may need a Design System in the first place. ??

To do that we have to first explore what are the common patterns in startup building and how they can be better with a design system.

Most startups don’t have the marketing budgets to build trust, so they have to rely on quality and “worth” or “profit”. We talked about this in more detail in another blog post: https://hype4.com/blog/how-execution-quality-affects-user-trust

???? If a DS can’t make the product better it has no reason for existing.

How a small team works on projects

Imagine a small team of a designer and a developer building a product. In an ideal world their cooperation should look like the blue lines. But in reality a lot of the communication happens verbally, on slack, messages, emails etc and a lot of the meaning gets lost.

Now imagine what happens if either someone quits and someone new comes, or when your team starts to grow.

Without processes you end up with chaos ??

The communication is now nonlinear and the same subject can be mentioned simultanously by many people. CHAOS!

And that in turn can lead to both teams visions not being aligned. Guess how that affects your roadmap.

Do you want that to happen? No?

Enter: Design System. ??

Of course a design system can’t solve all your problems and also make coffee. We all wish it could. ??????

But done right it can save you a lot of silly problem solving along the way. You can focus on your product core strenghts instead of UI nuances. ?

So what is a design system? ??

You probably heard the expression “source of truth”, and that makes some sense of course, but it’s best to look at this from another angle.

In short a design system is a buffer between all of your teams (designers, developers, marketers, CEO) that serves as building blocks of your product. Those building blocks can be colors, fonts, but also margins, spacing and layout choices. You don’t need to define all of them, but the more you do the more benefit you will get.

It can be done in various ways, but the general blueprint consists of Component definitions, Documentation and Code Snippets.

Let’s start from the first one.

Components ?? are all elements that the UI consists of. All buttons, fonts, colors, margin and safe space definitions and more. From high level stuff like colors, to the tick icon in a checkbox. Be precise.

Below you can see a small fragment of our own design system library (made in Sketch, which we fully recommend!). With Sketch you can create interlinked libraries quite easily and there’s plenty of tutorials on how to start.

It starts with the colors and then those colors are used on all other defined elements. So if we decide to change our color palette, it AUTOMAGICALLY changes everwhere. Just one click!

That helps building consistency and makes it easier to choose the right elements for the right application. A library like that should be built at the design stage, but with close cooperation with developers and other team members. It has to make sense — can’t be random or frankensteined from bootstraps and material designs of this world.

Documentation is a wiki ?? with all the design choices outlined in it. It should be divided into coherent sections and be both precise AND easy to understand. This is the hardest part of any design system and the one that makes the most difference.

You need to define design tokens (that’s a much longer story), but also define how each element can be used. For example if you have a CTA button, you need to specify that it can ONLY be used once per page. All other actions should have other respective buttons of their own.

Remember! Be precise! ??

Code snippets live within the wiki (and GIT repositories of course) and are the code-based representation of all of the components and general layout rules. They can be made by just CSS attributes, or full JS, React or Vue components that are right there for the developers to download and re-use. That way both the design and the resulting code have one source and are completely consistent across the board. ??

A MVP of a design system for an MVP product can only take a few days

So there’s no reason not to build one. Even if you make the most basic definitions and stick to them your product will benefit from them. The more precise and thought out your Design System, the easier it is to grow it in the future alongside the product. But you have to treat the design system as a product too. It has to live and breathe. Evolve. Starting early will set you in a mindset of doing things consistently and efficiently.

Design systems save you time and money. ??????

You can focus on innovating instead of figuring out how to build another signup form and what buttons to use. ??

Originally published at https://hype4.com

Don't forget to check out our medium blog at https://medium.com/@michalmalewicz