5 signs your project needs a design system

A design system is a set of practices and patterns underlying any piece of design shared between designers and frontend engineers on a project.

Designers use it to design new components and screens in such a way that they don’t conflict with previously existing materials. This avoids creating too much design debt and the need to refactor all old components.

Frontend engineers use it to understand the logic behind the composition of new screens and they use it as a basis for building their library of elements.

As a result, we end up with a synchronized, nearly identical component library in the designer’s Figma and the frontender’s Storybook.

A design system is the “language” that designers and frontend engineers use to communicate with one another. A graphical implementation of a design system is called a UI kit (it’s a library of buttons, inputs, etc.) We might think of a UI kit built using a design system like a story that has been written using that language.

To give a more tangible example from my own experience, each designer at Evil Martians practices the same set of principles across the board. For instance, these shared conventions include:

• Micro modules
• Naming rules
• Component composition
• A color system

But enough about how we do things, the question here is whether or not your project would benefit from a design system. To that end, here are 6 signs that it certainly would.

You need an MVP fast

When starting a new project, a designer needs to create basic elements (buttons, icons, inputs, dropdown menus, etc). But actually doing this well requires pretty deep consideration: creating an icon size grid that works for all buttons, inputs, and other elements; organizing elements that are flexibly and readily combined with each other. Further still we must think about composing font styles flexible enough without adding too much entropy, organizing color styles in a way that helps you easily update the color during branding development; the list goes on.

All this initial planning is very important because poorly designed elements will quickly lead to a huge tech debt. That being said, undertaking these preparations demands a lot of time. That’s why it’s important to have a well designed design system before starting a project. (But if you don’t already have one, that doesn’t mean it’s not worth starting now.)

You need to scale up the dev team

Onboarding a new developer onto an existing project is expensive, and the older the project the more expensive it becomes. Likewise, the greater the number of developers there are working on the project, the more expensive the cost of onboarding a new one.

In projects without a design system, there’s a high risk you’ll end up in a situation where each developer understands the design differently and creates components in their own way.

Additionally, new team members need a way to learn and comprehend the style of all the colleagues. There are certain pains that come with acclimating a new designer: a completely new logic for spacing (or lack thereof), a wobbling color system, different font sizes, different alignment habits, and so on.

Design systems reduce the number of things a new developer needs to learn. Instead of studying all of the developed elements, they just need to learn a limited number of rules behind the design. After that, each component the new developer works with will be familiar to them.

Having a design system reduces costs on onboarding new devs as they need to learn only one fairly limited set of rules instead of learning all project components.

We’ve had a lot of projects which we started designing with a design system. Each time, development started and scaled smoothly without the need to spend a long time learning the mockups.

You need to support and evolve the project for a long period of time

So many designers compose screens as isolated pieces of art, simply putting together elements that look good. Working this way creates a lot of fluctuation in color styles, margin and paddings, component sizes, and so on. A developer sees this mess and (if they’re good) will constantly ask the designer, “Did you really mean for those two shades of gray to be different, or is it coincidence and they can be merged together?” In this scenario, if a developer doesn’t communicate effectively, they will develop mockups as they understand them, producing a lot of arbitrary styles, and thus, making the code hard to read.

After discussing the style fluctuations with the designer, developers must then synchronize with each other, otherwise each developer will generate slightly different components, which is certain to result in clashes before too long. That’s how design debt converts into tech debt.

Moreover, no designer can remember all the paddings and element sizes they used half a year ago in some project module. When trying to add something to an old mockup, a designer must recall the context and remember why they used a particular margin between elements and why it might vary from another one in a similar component. This will eventually lead to more and more fluctuations which the developer will need to spend extra time handling.

A design system helps to keep the design and tech debt under control.

The designer doesn’t spend time reverse-engineering their old mockups. Developers receive mockups with consistent spaces, colors, and sizes. And, a well-considered design system reduces cost of improvements and refactoring.

A robust design system upfront alongside an underlying UI Kit helps the project continue to evolve for a longer period without the need to refactor core UI components.

You want to make sure designers aren’t a bottleneck

Designers working without a clear system not only generate randomness and debt, it’s kinda like a form of vendor-locking, in a sense. To illustrate, if the designer decides to quit, no one can simply decompile their design and extract applicable logic from it. Indeed, a new designer might find it much easier to redesign everything from scratch than trying to reverse-engineer old mockups, and feature development will stop during that time. If you’ve experienced, or are wary about having this particular brand of bottleneck, that’s a clear sign that a solid design system is sorely needed.

Additionally, a solid design system means it’s even possible to rotate or take designers off a project if needed. A new designer only needs to learn a few key rules that the previous designer has set. The new designer might want to refresh the style, use another font, or swap a color, but the system will hold everything together, making it possible to keep developing new features without a complete redesign.

Design systems allow devs to keep developing new features without involving a designer.

And finally, at a certain point, developers can even develop new features themselves during periods when the designer is unavailable. With a UI kit built on top of a robust design system, a front-end engineer can continue to develop a project during mid-range periods of development when a designer could be unavailable.

You strive for “perfect” results

A well-designed and well-developed interface just looks solid. It leaves no questions about alignment and margins; everything is just in its place. Additionally, a design system has shared practices and agreements between designers and front-end engineers. This keeps things organized and sustainable. Once a design system has been formulated and implemented, a component within it will remain the same wherever it’s used, and again, this means time saved.

As described previously, a design build without a system leads to accumulating errors: arbitrary spaces erroneously used by the designer are interpreted by frontend developers ultimately produce an unpredictable result requiring manual compensation. The more a developer makes padding and margin customization inside components, the higher chance the component will look off in some cases, the higher cost of running visual tests to make sure everything looks great, and the lower probability the team will have time for that.

To achieve a neat result, the interface must be built using neatly developed components. A design system sets rules: the space to use, fonts, icon size for each font size, the padding to wrap around a label and icon inside a button, and so on.

This provides two main benefits:

• First, developers will understand the logic behind the component composition and will develop them using exact same metrics. Thus, the designer and developer have identical components in Figma and in Storybook.
• Second, the designer is primed to pick an existing space or a component instead of inventing something new without a good reason; the same applies for developers.

This simple ability to reuse previously developed components gives us a predictable result. For instance, once you’ve designed and developed a great-looking search bar, a newly-developed filter bar will also look great. That’s because it’s visually the same component inheriting its well-designed look.

And so, we’ve come to this

If I’ve not already hit this point home enough, a design system is a logical, efficient choice for our team. This rings true not only in terms of the efficiency it brings with regards to design and technical implementation, but also with how our projects are able to effectively add, rotate, and remove design personnel while keeping the train on the tracks.

Invest into the system once, and it’ll be much easier to deploy a new project. At Evil Martians, our designers are able to take our well-defined design rules and begin developing a UI kit without the need to reinvent the wheel. Effectively, this means time saved, and thus… money saved. Give us a shout!