The Minimum Viable Design System

Growing UXPin Design System stored in UXPin Design System Library

Over the past couple of weeks I had the pleasure to talk about UXPin’s approach to building a design system on multiple meet-ups and webinars (you can watch one of them here). I had lots of fun sharing our experiences learned a lot through all the lovely conversations after my talks.

One question I’ve been asked multiple times, that also came up during my conversations with our team at UXPin, was:

How long does it take to build a design system?

The Zombie Style Guide Legacy

Back in the day, an unlucky member of the design or front end development team would be trusted with the task of documenting all the conventions approved by the team. Color palettes, text styles, code standards, sometimes even UI patterns.

Sounds like a design system? You’re right. It does sound like a design system, but it’s not.

This old approach to building a style guide was aiming at producing an artifact. It’a supposed to be a derivative of a documentation process. And every single time…

Before the style guide was done, it already turned into a zombie.

The impossibility of building and maintaining style guides encouraged our industry to rethink the process of maintaining consistency of experience and code. Enter the design system.

The Design System is a Process

Unlike static style guides, design systems are dynamic. What does it mean? The style guide is an artifact, the design system is a process.

Artifacts are static, processes are dynamic.

Instead of thinking in terms of the delivery date, design system teams (typically called Design Operations teams) plan to help organizations gradually improve the inner consistency of the interface and deliver great projects to the market faster.

Managing entropy with a Style Guide and a Design System

United Against Entropy

Just as with any enclosed system, the entropy of a digital product continues to increase, unless it’s deliberately managed. Every new feature, every new member of the team, every new management layer, or stakeholder/client interaction, adds to the entropy of the experience.

Product experience gradually defaults to chaos.

Never Ending Minimum Viable Product

Asking about the delivery date of a design system seems to have a hidden assumption, that there’s some point in time when the design system is “done”. The processual nature of a design system cancels this assumption.

Design system is a process and therefore is simultaneously always ready and never done.

Start small ship often

A design system comes into existence when an organization acknowledges that increasing UI inconsistency needs to be solved through new workflows.

The entropy stops expanding with the first convention agreed upon and implemented by a design organization. Unlike a style guide, the value of a design system can be experienced immediately. Design system starts to add value almost immediately, even if the first convention is just a set of 5 primary colors with corresponding naming convention. In fact I would argue, that:

Design system with one color defined, properly named, implemented and accepted by an organization is better than a full static style guide.

Instead of worrying about the delivery date of a design system, accept its processual nature, start small and ship often. You’re at war with chaos and every little battle matters.

Good luck.

Design Tools Radical. CEO at UXPin — the most advanced code–based design tool out there: