Minimum Viable Design System Guide

When to have one — when to not have one — how to make one

Every software product design department introduces a design system at a certain maturity stage.

Design systems have become a commodity across SaaS, B2B software and consumer software departments.

Repeating tasks shapes framework thinking

Design systems occurred in the early industrial era when the principles of frameworks developed.

🔨 Figma is the 2023 gold standard for design systems with its libraries, components, instances, patterns, etc.

Atoms in the Material UI design system

Design systems typically follow the atomic design principle and are closely connected to how front-end experiences in web applications are being built, thus reducing the amount of information loss between design, development handoff and actual live implementation even further.

Having a coded design system twin in the web via storybook

Depending on the process used, tools like storybookJS bridge the gap between Figma and front-end even more and see rising popularity even outside cutting edge tech teams.

the BlueprintJS design system in Sketch

However a new danger arises if everyone takes the creation of design systems as a default requirement for their department.

For product and design leaders it’s obligatory to know why and when design systems are necessary and with which level of detail.

💀 💀 💀 Business Risk 📉 📉 📉

The biggest damage done by having a design system too early is

• loss in short and mid-term productivity
• losing time-to-market against competition
• high R&D costs that can kill the company before it succeeds

The biggest damage done by having a design system too late is

• inconsistency across the product line
• crippled long-term productivity by having to put out fires rather than building new stuff
• the necessity for redoing an entire product library which does not increase the capabilities of a product
• unhappy team: low retention for top talent
• unhappy customers: reduced CLTV and increased churn

🙋Why have a design system?

You become a member of the copy pasta gang.

Advantages of a design system

• productivity boost through reusability
• increased consistency across the entire product line
• inexperienced and lower paid designers can produce high quality outcomes with little management oversight
• if created and maintained by top UI designers, the quality leverage can be enormous

Disadvantages of a design system

• time and resource cost of creation
• cost of maintenance
• discipline and energy cost to keep all new design efforts up-to-date with the design system
• incompetent designers will build bad design systems which leads to a continuously enforced badly designed product

Sweet spot

You need a design system

• if you are absolutely certain your company cannot continue with an existing framework like Material UI or Blueprint.JS
• if you have 2 of the following: 12+ months runway, product-market-fit or a growing customer base that’s heavily using the product

You don’t need a design system

• if you do not have factual indication your project is going to make it.
• if you think you have a product, but it’s actually just a project (e.g. a small marketing website)
• if your product has very little reusable components
• if you’re creating something for the short-term

This narrows it down to a relatively small time spectrum.
The biggest enemy for making the right decision in terms of timing are people who want to deliver exceptional quality at all times without lacking the sensitivity for the business risk of the company stage they’re in.
Or the exact opposite: A product lead with too much love for rapid prototyping who has never pushed a product or platform into growth stage maturity.

🚫 Design systems fail when

• designers lack discipline using the design system
• the over-engineered design system is unusable by designers
• processes don’t support usage of the design system
• nobody is responsible to maintain the design system and there is no time and resources allocated to maintain the design system
• product managers/owners are not disciplined enough to stick to the design system when front-end development has failed to implement strictly according to design system
• front-end development and design processes are not streamlined to work in a tandem, turning any design handoff based on the design system into garbage implementation. Pretty much day-to-day operations if you outsource to cheap dev teams ;)

Different slaps for different situations

Lack of discipline is the biggest threat for design systems.
It’s natural: it takes many years of experience to understand that designing or writing code to solve a problem in the quickest way comes with trade-off in technical debt. An inexperienced designer loves the challenge of doing something from scratch. Becoming sensitive for technical debt only comes with those years of experience. There’s always a conflict between personal comfort and desire and actual business interests and leaders need to be aware.

Thankfully humans are creatures of habits and reinforcing the habit of using the same system/framework/methodology on a daily basis will lead to consistent workflows.

✔️Design System Checklist

A great design system

• is very easy to use and provides high productivity for the designers
• has the most important components that are being used pre-built
• is as small as it can be without lacking content
• uses atomic design principles
• is functional and beautiful of high quality
• encapsulates color schemes and typography settings that make sense and are highly applicable even by non-designers
• well organized in Figma and accessible to engineers and product people
• self-explanatory – no senior supervision needed
• is a cross-discipline effort of the entire product team with buy-in on all sides
• allows developers to receive handoffs in wireframes and develop front-end experiences fully consistent according to the design guidelines

A bad design system

• makes the extraction of components complicated and time consuming
• is so big that you can solve each problem/challenge in multiple ways, creating inconsistency in the feature design process despite having a consistently looking design system
• is so badly fleshed out for the most used components that despite using it, creates repetitiveness in the feature design process, which reduces productivity and fosters inconsistency
• is an isolated project of the design team
• is so ugly that instead of leveraging the quality of a top designer, it consistently forces designers to stick to terrible design choices defined by the design system creator
• is so technically over-engineered that changing a small thing in once instance destroys many other components
• is so technically under-engineered that changing the design system takes tons of time and inevitably leads to inconsistencies caused by manual repetition