Design systems and decision making

Design systems are becoming the clear path forward for building projects at startups, maintaining enterprise-level products, and everything in between. These systems, made up of a set of style standards and reusable components, are the perfect way to align a brand through product and keep design consistent. Design systems are self-imposed which naturally leads to a large amount of decisions to be made.

At Manifold, we’re smack in the middle of that decision making phase. We have a fairly well defined brand style that our small design team is able to manage by personal communication and ad-hoc discussions about direction; this works well up to a point. As we add members of our team — I’m looking at you, front-end engineers — we require a more inclusive method of communicating brand style and principles.

Our product (and product marketing) is growing beyond the bounds of our current style guides and prototypes and sketch files and icon sets. Now we’re at the point where we need something that requires a cohesive approach. Enter our growing design system, and the decisions we need to make to foster its evolution.

Why is a design system the answer?

For Manifold and many other companies designing products, design systems provide a clear solution on how to communicate design across both design and engineering orgs.

The easiest decision to make here is to choose a design system as our method of communicating design decisions going forward.

There is a ton of material written on design systems, here are few key references:

• Invision has an excellent introduction with their Design Handbook project.
• Adele compiles a truly gigantic list of systems.
• Atlassian’s article on building a design system of your own.
• Brad Frost has a landmark introduction to system design.

What should you include?

First, we need to make some preliminary decisions about what pieces we need to achieve our goal of having a central repository for design.

The best thing about designing your own system is that you (the design team) are the architect. While it might seem static when you’re implementing new designs, all parts of the system are living, changing pieces that can shift to accommodate as needed. In our case, and most likely the majority of designers looking to create a system, we are not starting from zero. We have existing designs, color palettes, typography, and maybe even some reusable components.

In Manifold’s case here’s what we have:

• Colors
• Typography styles
• Iconography
• An opinionated grid
• Shared sketch library
• Some React components
• A basic style guide tying some of this together

That’s our basic style inventory. It’s a start!

Unifying the parts

We can start by grouping these things into categories, combined with our ambitions, based on the atomic design thinking philosophy.

Basics

• Colors
• Typography
• Iconography
• Grid

Pattern library

• Components
• Templates
• Prototypes

These are basic tangible blocks for our design system — things we create and share to keep consistent. A glaring omission here is the philosophy and design thinking behind the elements. It’s important to have a guide for creating new atomic level pieces and the components based on them, so we’ll add Guidelines:

Guidelines

• UX philosophy
• Implementation guidelines

This list will definitely continue to grow as we learn what’s right for our org as we work with and use the system.

Deciding on a design system tool

In order to collect these pieces into one place and share, we have so many options. Should we roll our own? Do we use an existing tool like Invision’s DSM to sync? At Manifold, we have yet to find the right solution — the parts of our system, organized separately, are floating in different places. Each section of the above style inventory live independently.

We have yet to find the right tool, probably because the parts we’d like to include are fundamentally different. Text and colors need a different display tool than a React component. If we make the decision to have a collection of collections, creating our own web app with links to the different parts might work best. We’ve also found that a tool like DSM does well for overarching style and simple components but falls down when you need to display example code or write about UX decisions.

Our system in the future

If we want to take the design system philosophy a step further and start introducing bulletproof consistency, we can start introducing the Airbnb philosophy of tying our interface directly to code. This will allow us to integrate our design more deeply with our front end team and maintain the brand inside our different products more cleanly.

—

As our system grows and cements itself, we will continue to confront problems with decision making laid out inside our design system. Using the design system to shape our decisions has proven useful to unify our thinking and ownership between teams.

Have you had success creating a design system for a growing organization? What tools took you there? Is there a tool not mentioned here that we’d benefit from trying? We’d love to hear from you, find us on twitter or leave a comment.