Design Systems (The missing ingredient)

In the 1950s, when instant cake mix was first introduced to the market, it sold poorly. This frustrated manufactures who were fully convinced they were on to a good thing. To find out why instant cake mix was performing so badly, they engaged with researchers who in turn interviewed housewives, and the interviews revealed the problem: Housewives felt that using instant cake mix was convenient, but it was also cheating. In other words, instant cake mix made it all too easy.

Searching for a solution, the manufacturers began with the question ‘If housewives find instant cake too easy to make, why not make it harder’? They launched another batch of cake mix, only this time they removed a key ingredient — dried egg. Now using instant cake mix meant housewives needed to add their own eggs to the mix. The plan worked. Introducing this small piece of labour gave housewives ownership of the process. Instead of feeling like cheating, instant cake mix felt good.

Preparing ingredients
Companies are investing in Design Systems right now for one good reason: teams need them. Yesterday’s teams looked like traditional manufacturing: everyone co-located in the same room, working on the same product and aiming for the same annual release date. Today’s teams look more like start ups: small, dispersed units working in different locations, on different parts of the product, responsible for their own release cycles. Structuring teams like this is great for speeding up production but it invites a communication overhead which, if left unmanaged, can lead to inconsistencies in the product. To ensure harmony, teams need to sing from the same hymn sheet. The hymn sheet in this case is a Design System.

Paradoxically, getting teams to reference a Design System is the biggest challenge a Design System has. The quickest way to get around it is to make it relevant. This is because relevant Design Systems reflect the needs of the people using it. So for example: the way to make a Design System relevant for Developers is to include snippets of code with each component, the way to make a Design System relevant for QAs is to ensure it represents what’s already been released in the wild. This is important to understand because the way to measure the success of a Design System is not by the sum of its parts but by the level of engagement it attracts.

Making it flat pack
What the manufactures of instant cake mix had stumbled upon is the ‘IKEA effect’. The ‘IKEA effect’ says that we place more value on the products we’ve had hand in making. So flat pack furniture — which has involved our labour for completion — is more valuable in our minds than furniture we bought off the shelf. What the IKEA effect teaches us is that if we want users to engage with a product, we need to give them ownership, and we can do this by involving them in the process of making — a lesson that can be applied to Design Systems.

If we want users to engage with a product, we need to give them ownership

Crack a few eggs
Ceding ownership may feel risky. After all, if several product teams are working on different parts of the product and contributing to the Design System, won’t this lead to inconsistency? The short answer: yes, managing consistency will always be a battle but this is not the problem that needs your attention. The real problem you need to think about is how teams contribute to the Design System. To find solutions, you’re going to need to crack a few eggs.

Ce n’est pas une design system
Stop thinking about your Design System as a Design System, start thinking about it as a product. From concept to build, testing and shipping, Design Systems have their own production cycles to manage — and it doesn’t stop at release. Over time, your Design System will accumulate a backlog, as new additions are requested and old ones need updating. Backlogs are messy and need to be managed and prioritised. A tool like Trello can help you here. Using a basic Kanban approach, you can see what components are in the backlog, what’s currently being worked on and what’s out there in the wild.

Governance team
Managing any production cycle is hard, that’s why you will need a Governance team. The job of the governance team is to ensure that the Design System stays relevant. They do this in two ways: help product teams make new contributions, and ensure that what’s already in the Design System is in lock step with the products it supports. The Governance team are there to impose order on the Design System, not control. Reactance, another word used in psychology, implies the opposite of the IKEA effect. Imposing too much control will result in a lack of ownership.

Acceptance criteria
Before anything gets added to a Design System it needs to be properly evaluated. When contributions are made arbitrarily, it erodes the quality of the Design System, which in turn affects the quality of the product. An acceptance criteria provides your Governance team with clear direction on what to look for from new contributions. For example: Have all patterns been sufficiently stress tested? Is there enough relevant information or documentation for the Developers / QAs / Designers that will use it?

Version control
Design Systems can involve many different iterations over the course of time. To ensure consistency, each of these iterations needs to be tracked. If left unchecked, your Design System will fall out of sequence with your product or at best, prevent you from rolling back on previous decisions. A robust system of version control will prevent this from happening. Repository like Github or Bitbucket can be used to good effect here and will enable you to manage changes and control versioning.

—

It’s tempting to think of a Design System as a re-usable kit of parts — which is fine in many respects. The problem with this way of thinking however is that it focuses way too much on the artefact and not enough on the activities supporting it. Instead, Design Systems need to be thought of as products who’s success is determined by the right inputs, good management and that missing ingredient — ownership.

Each & Other partner with companies to bake ownership into their Design Systems. Supplying ingredients is easy; getting people to use them is harder.

Check out the Each & Other podcast on Design Systems