Is it really a design system?

19/01/2021 by Benoit Rajalu

A character sitting at their desk being flumoxed

For the past 15 months I have been working with my team on our company's Design System (DS). We're a small-ish squad with 3 designers and 9 front-end developers and absolutely none of us are working on it full-time. It's still a really important subject and one we've discussed "passionately" about all year long.

Many of these debates have featured variations of the same line: "this is not a design system". We often have to reassess whether what is being suggested or what has been built is "worthy" of a DS.

Why? Are we all working under different definitions of what a Design System is? We should not. Even if we had not thoroughly detailed our needs from the start (which I swear we did), there are plenty of converging definitions out there. The notion of a DS isn't that new or complicated, is it?

So let's work backwards. What is it we're building when we're not building a DS? Also, is it ok not to be building one?

Three people holding jigsaw puzzle pieces that clearly match with one another — One thing is for sure, a Design System is a collaborative effort

Speaking the same language: what are we talking about?

One of the most complete definitions of a Design System comes courtesy of Nathan Curtis from EightShapes, a company built to nurture such systems.

Curtis' definition breaks down a DS in large checkbox thingies.

First he says a DS almost always "offers a library of visual style and components documented and released as reusable code for developers and/or tool(s) for designers."

This definition opens the door to a system being made exclusively either for designers or developers. A thoroughly documented collection of Figma (or your tool of choice) components is as much of a DS as a thoroughly documented combination of Figma and React (or your tool of choice) matching components.

These two delivery and production scopes are wildly different. Why? Which do we pick?

Enters checkbox number two: the system's customers. Who will be using the DS and what are their needs? It's possible that the DS' consumers may only be designers or developers but not both. The delivery scope would then change accordingly.

Now we can define what we need and who we need it for, it leaves one last checkbox: how? Curtis' definition is not about the minute details of how the sausage is made, it's more about who makes the sausage: "a design system is made by an individual, team, and/or community. While some arise less formally, organizations now dedicate small to large squad(s) to develop and release system versions and processes over time."

This puts the DS in front of the real question: can the company afford the cost of having a team organise, own and drive this internal product forward? The answer to that directly informs the scope of the possible output.

So these are the checkboxes we'll work with. Curtis elegantly sums them up in an elevator-pitch definition:

Almost always, a design system offers a library of visual style and components documented and released as reusable code for developers and/or tool(s) for designers. A system may also offer guidance on accessibility, page layout, and editorial and less often branding, data viz, UX patterns, and other tools.
A design system is adopted by and supported for other teams making experiences. These teams use it to develop and ship features more efficiently to form a more cohesive customer journey.
A design system is made by an individual, team, and/or community. While some arise less formally, organizations now dedicate small to large squad(s) to develop and release system versions and processes over time.

When are we not building a design system?

Leaving out part of the customers

Let's go back to the branching path. It says a Design System can be either a collection of code and design components or exclusively one of them. My team had a previous experience where our designers had their own design components, the developers their UI library and neither were aligned. That situation had left us with a laundry list of issues and inconsistencies, so that branching path made us very uncomfortable. It describes precisely what we want to avoid.

As we've seen however, that first part of the definition works in tandem with the notion of customers.

In a company where designers and developers work towards the same eventual payload, they are both customers of the Design System. Their needs are fundamentally the same: both professions want a homogenized, accessible, efficiently built product. We are not two teams working for each other, but one team collectively building the UI of our apps.

That's why the branching path felt wrong. We can't do the "or" part of "reusable code for developers and/or tool(s) for designers", we need both or else we would severely compromise on this unicity of purpose. We need to speak the same language because we are eventually building the same thing.

A designer and developer collaborating on what looks like a mobile app — Designers and developers make the same product, they should thus make it together

With that comes our first clue at assessing when we're no longer building a DS.

It has to be a nexus for all the production teams present in the company's workflow. If designers and developers are not following the same rules or not on the same line as to what the objectives are, then it's probably not a Design System down the line. It may be a UI Kit and a UI Library (or two separate systems), both vaguely resembling one another but not in sync. One part will eventually "lie" to the other. The designers will have an idea of the product, but the developers will build it their own way.

If this division is OK with you, you're not building a Design System. Chances are you're building an isolated UI library.

Leaving things open to interpretation

Everything you read about Design Systems revolves around documentation. Curtis' definition features it ("library of visual styles and components documented and released") but you can look at any of the popular DS out there, you'll see that they do not skip on the guidelines and thorough docs.

This has a crucial purpose. Imagine you have designed a button component. You have done your job well, each interactive state is detailed, you have provided different length and types of content to showcase the behavior of the component. It gets picked up by the developers and made into a web component.

At first all is well. In the playground (such as a Storybook) where the new component is displayed, it looks and seems to behave just like it does in the designing software.

But then it must be used inside the app. How should it behave when it's put right next to copy for instance? Does the copy wrap or does the content inside the button wrap when the space becomes limited? Also, what happens when I need more than one button in the same spot? You may offer variants then, a "Secondary" or even "Tertiary" button but then you get asked even more questions: when should one use Secondary or Tertiary? Can I use Tertiary on its own because I like the way it looks a bit better here? Also, can I just do Primary then go straight to Tertiary?

A developer visibly lost watching his laptop screen — Undocumented design leads to perilous development

With each component comes a long list of possibilities and with them a long list of choices. The thinner the documentation is the larger becomes the place for interpretation, either from other designers or from developers. This comes in direct opposition to the mission statement of "developing and shiping features more efficiently to form a more cohesive customer journey". Any interpretation is a risk to the cohesiveness of the overall product.

It's also much less efficient: for each new component the design team will have an endless stream of back and forth questions from the developers who will try to ensure the answers are built as code. But later on another designer who has no idea these limits are in place may use the same component and break those implicit rules. The coded component is unable to fit the requested design, and the back and forth starts again.

Documentation and guidelines are there to prevent this. Theoretically, one could "learn" your Design System and build any feature simply by applying it and without damaging the product's homogeneity. If you remove the doc, what is there to learn? It's all just components and individual choices to make.

If that's OK with you, you are not building a Design System. Chances are you're building a divisive UI kit.

Initiatives that undermine the system

The definition we're working with revolves a lot around people using the DS. Let's discuss the last part first, the one about having a squad working on the system. That's important for ownership, enabling teams to move quickly according to a clear path. It's easier to set a trail as an identified crew rather than needing to question everything as a large committee at every turn. It's also important because having owners for the DS means they "embody" this in-house project.

In software engineering we're used to having teams handling artifacts for other teams. We already do that with the "infrastructure teams" behind the platform other teams run their services on, or with "QA teams" focused on testing pipelines and tools needed by the other squads etc...

Why would that apply here? Well now we're looping back to the second part of the definition: adoption, support and usage by the consumers building products. These consumers (our colleagues) are also contributors: they are closest to the products and are acutely aware of technical requirements among other needs. Communication and contribution from them is essential to most companies. Having a core team identified as leading the System enables all the other teams to defer and centralize most of the tedium of collectively building a company-wide product.

That's the plan anyways. But what happens when either developers or designers don't subscribe to the System?

Say as a developer, you don't want to pitch in to the collective effort required to build a component that will fit not only your needs, but also the needs of another feature team? You'll code a single-use component outside the scope of the DS. It seems easy, but the other team might do exactly the same. Now the designers review both features and see two components that seem to behave the same, they have every right to think that component can safely be used at scale. It's generic for them after all, why wouldn't it be for developers?

A green and a red Toasts to differentiate variants — Sidestepping the Design System leads to duplicates of its components

By choosing to go rogue on the DS, the developer has created a rift in the basic contract of a DS. It works exactly the same way when designers try to get away from the DS.

You're tasked with designing a new feature but the Design System does not seem to provide exactly what you need. You feel like a bit more margin would work better, or maybe you'd prefer using a Secondary button without having a Primary. The temptation to break pre-existing rules from the DS (or to never set them) grows, but the contract would be lost and the dev team will be unable to deliver without friction.

If the DS does not provide what the designer needs, maybe the DS is not properly outfitted and additional work is required, which is fine. Ask the DS team for it. It is an iterative, living process. The point is that it's not something one does in half-steps. Either you build the product with the DS or you don't. If you consistently don't especially when you could, why is there a Design System? The whole structure cumbles. There's no customers anymore, and there's no use for a producing team either.

If you are OK with undermining your Design System, you are not building a Design System. You may be actively destroying it.

When is building a design system not worth it?

As we've seen, the definition of what a Design System is takes into consideration more than the delivery. Who its customers are and what they are after clearly defines it more than the type of component it documents.

With that in mind, there may well be situations in which investing in a DS may be too steep a cost. As an in-house product, the value of DS is only worth what its customers say it is worth. If your teams are not interested in collaborative creation, in the curation of the single source of truth, in systematic methodologies...then the cost of adoption may be too high for them to pay.

Your organisation may also balk at the idea of shifting its production pipeline from a "from scratch" model to a "system first" (and eventually "system only") approach. The former has an air of complete creativity and unlimited potential. It is also the reason why many products have visible "layers" where you can see the sudden shifts in design directions. You may even find two buttons that look the same, but do not have the same styles when focused. Airbnb itself had that going on for a while.

The latter implies tremendously more documentation work. It's often wrongly seen as a simple box of Lego bricks, ready to be used. It is decidedly more than that: it's the Lego bricks and the very carefully-made and detailed leaflet that comes with the kit you've bought. It's the bricks and the way to use them. It's the bricks and not the magic pencil that will make any brick look like whatever anyone wants at any time. It's the brick and the legal binding that one must not do whatever they damn want with the bricks or the Lego company will sue. It's the brick, the team that builds the brick and the other team(s) that uses the brick and the communication between everybody.

Buying into that mindset takes time. It is an investment, both in the talents it will require and the methods it dictates. Whether they are worth your team's time (and company's money) is up to what you (as a company, as a team of designers and / or developers) are trying to achieve. If cohesiveness and rapid industrialisation of best practices is not that high in your list of objectives maybe you are not in the market.

But maybe you should.

You can build a Design System

If there's only one thing to remember about all of this, it's that a Design System is a methodology before it's a deliverable. Its objectives are always the same: deliver high-quality, homogenized UI elements at scale to consumers using them to build products.

To achieve that, you may try to keep doing what we have all been doing forever: split your design and development teams and work as if one was building for the other. Chances are, doing the things we've always done, you'll run into the same problems we've always had.

The idea is to switch from this "us" and "them" isolated exchange to a "needs" and "means" one. The needs are the same for both professions. The means should therefore align.

A diagram showing on one side an opposition between code and design, and on the other a cycle between features and a Design System — Changing your UI pipeline: moving on from "opposition" to "collaboration"

It has a price, as most changes do. The need for a core driving team is nothing to scoff at. Maybe that team does not need to be dedicated to the DS full-time at first? Remember that nothing has to be a big bang. Take your time. Identify your priorities, make sure everybody is either on board or ready to get on board. Document the ways a DS would have helped solve recurring issues.

A Design System isn't necessarily the solution to all your woes, but when it solves most of them, staying true to its principles is the best way to avoid falling back into the same pit. It's key that we do not make ourselves believe we're building one when ultimately, we're just slapping the label on a different ruleset.

Illustrations are curtesy of Greg Dlubacz over at Whoooa.