The Minimum Viable Design System
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?
There are no wrong questions and I was happy to answer every single time. However, whenever I hear this question I feel that it points at a deeper problem: design systems are still misunderstood and confused with an old approach to building a style guide.
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.
Why? Simply because the dynamic world of product development, where changes happen constantly, does not respond well to static assets that take weeks to build. While a design/development martyr was struggling to document every convention, conventions kept changing. Building a style guide was a Sisyphean task.
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 delegating one person to create documentation, in the world of design system, we plan a new workflow that keeps adding, subtracting, and modifying all the information for crafting user experiences.
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.
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.
The growth of the entropy is a constant and can be only controlled through constant action. That’s why the end game for a Design Operations team is not a static artifact, it’s a workflow in which a united organization of designers, developers, PMs and other team members build a design system for crafting user experiences.
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.
A design system stays in a constant state of being a minimum viable product. The point in time when a design system suddenly gains value does not exist. Once the design system process is established and agreed upon, the minimum value is achieved. With every subsequent release, the design system becomes more powerful, but never achieves the ultimate value. The entropy continues to grow, the interface continues to change and design system must evolve, as a process, without an end.
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.
Why? Because this color is immediately decreasing the entropy, unlike a static style guide which remains always outdated and never implemented.
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.
Do you want to see how we’re building our Design System? Follow our Design Operations sprints:
- Design Systems Sprint 0: The Silver Bullet of Product Development.
- Design Systems Sprint 1: The Interface Inventory
- Design System Sprint 2: One Color Palette to Rule them All
- Design System Sprint 3: Managing the Basics
- Design System Sprint 4: Design Principles
- Design System Sprint 5: Managing Typography
- Design System Sprint 6: The Fastest Icons on Earth
And here’s a broader perspective on design systems:
Design Systems are a language. And this is changing software development forever.
