A design system is like a kitchen

Having the right ingredients ready lets you be creative

Yuliya Nikolova - Joubert
Demain sera bien. Par Haigo.
8 min readNov 22, 2019

--

Photo by Katie Smith on Unsplash

It was a public holiday weekend in France and I hadn’t planned to do anything special. I live in Paris, in a very small apartment (whoever lived in Paris alone knows the struggle). This small apartment has an even smaller kitchen, so I never keep anything in the pantry. I wanted to cook pommes grenailles (or potatoes in an oven) but it was a public holiday Monday, so I couldn’t find any store open to buy potatoes. When we are hungry, some funny thoughts come to mind. At this moment, standing in front of my empty pantry, I thought about how a kitchen is like a well built design system.

Let me explain…

If I want to make the most of the space in my kitchen, there are some questions I need to ask myself first:

  1. What do I like to eat most of the time?
  2. What dishes I might want to make occasionally ? (in case someone will visits)

I am a big fan of cooked vegetables (ratatouille style) in all their forms, often accompanied by some rice or pasta. So where should I start? First, there are the main ingredients, like salt, paper, olive oil and other spices that I can stock up and keep for a long period of time. Then, I can also purchase some onions, eggplant, zucchini, canned tomatoes, rice, potatoes (normal and sweet), carrots, pasta, salad…Like this I can always have something to cook a quick dish with.

A design system has a similar approach — you use basic design elements (main ingredients) in order to build more complex ones(like a dish).

What is important is not only what I will stock on, but also what I won’t — I might like the occasional curry but I won’t stock up on turmeric, coriander, chicken and cream — I can leave those and decide if I want them later. For now, I need to focus only on what is most functional for my habitual eating habits.

Let’s say I am really motivated to start bringing my home made lunch at work, but I also don’t want to lose all my evenings to cook for the day after. No biggy — I can start to meal prep. Depending on the meals I want, I can prepare the ingredients — cut the salad, cook the vegetables, boil the pasta… all these can stay ready in the fridge for a couple of days before I use them. It is helpful to think about those in categories:

Raw ingredients:

  • Salad
  • Tomatoes
  • Perlesy
  • ….

Bases:

  • Pasta
  • Rice

Cooked:

  • Boiled broccoli
  • Cooked eggplant

Dishes:

  • Ratatouille
  • Chickpeas with tomatoes

Sides:

  • Houmous
  • Tarama
  • ….

When you think about it, this is also how we organise a design system.

Raw ingredients/Bases:

  • Color
  • Typography
  • Grids

Cooked:

  • Inputs
  • Text passages
  • List architecture

Dishes:

  • Forms
  • Hero covers
  • Page templates
  • ….

Sides:

  • Header
  • Footer
  • Navigation
  • ….

Structuring a design system like a well organised fridge is a way to look at the the Atomic approach — we dissect design and code elements into atoms, which build up molecules and then — organisms. Each design system is unique and even though we can follow a general rule for classification, my advice would be to classify the way it works best for your team and your organisation. A good tool to use for guidance is this one, developed by Brad Frost and his team.

But let’s go back to the focus of this reflection — what is really a design system? The term appeared around 2014 and since then, orbiting terms like “component library”, “pattern library” “toolkit” and “style guide” have appeared, mixing up what we would call the the “graphical” side of things, and the “technical” one. You can tell that we still have a lot to learn about design systems because ever so often we can’t get the vocabulary right and use these terms and “design system” interchangeably.

To me, a design system at its fundamental is a collection of elements that are fully deployable (design + code) and allow you to quickly build final products. The time you save from important but tedious tasks around the built allows you to spend more time on what really matters to your users — improving the flow, the service, doing research, testing…

But let’s go back to our metaphor with the potatoes (yes, I do like potatoes very much and if you grew up in Eastern Europe like I did, you ate a lot of those as a kid 😊). It is not enough to have the potatoes cut and prepared, nice and juicy, with olive oil and salt. You also need to heat up the oven and cook them. I don’t know if you have tried a raw potato, but it’s not really edible. Once the potatoes are cooked, you can combine them with the rest of your ingredients in order to have a full dish, adding the rest of the important nutrients (unfortunately, you shouldn’t eat only potatoes).

In a design system, having the designs ready is the first step — editors like Sketch allow you to create a complete design components library. You put it in Zeplin — you have the CSS specifications, which brings you closer to your design system. But the CSS is not enough. You also need to add the HTML and also even some JS of choice (Web Components, React, Angular and etc.). Once you have these, you close the cycle for a design system.

The workflow of building an element in a design system

Back to my kitchen — what do I do if I have unexpected guests over for dinner and I don’t know what they want to eat? The struggle is the same if you are building a design system for more than one typology of product — needs are different and you have to chose your “ingredients” wisely, so that everyone will be happy and not hungry. But how do you do that? You need to make sure that you have raw ingredients that everyone can easily consume. Let’s say you have a person who eats only raw food over for dinner and you didn’t plan for it — well they can snack on the fresh carrots and cucumbers you have pre-cut while you are cooking a meal for the rest of your guests. The situation is similar when you develop a design system for different teams, who have different needs and technology — if you have thought your design system the smart way (having done very well your constants and the structure of your more complicated elements) everyone will have something “to snack on”.

A very good example is the Design System we have been developing for AXA. Long story short — AXA has more than 60 entities all around the world, with production teams who are fully autonomous. Each entity has its own insurance offer and products, and therefore each production team — it’s own needs and technology. On the other side, AXA has a strongly expressed brand visual image, which needs to be respected on digital in order to ensure the consistency in the brand look and feel. So how do you help all these global production teams to create a homogeneous brand look and feel when there’s no common choice of technology?

As a small team, based in AXA Headquarters, our goal is to create a design system, which will serve the needs of all AXA entities. So it’s like having a small kitchen ready to welcome various food preferences at all times. What we decided to do, is develop in Web components. Why? Because they are a standard included in the HTML specs and have a native support. Which therefore makes them compatible with all the big frameworks. It is a good work-around when you need to stay tech-agnostic. It is like stocking up your kitchen with very good quality basic ingredients.

In the AXA Design System the constants are fully usable; the more complex elements offer a solid base to build on for teams who have chosen a different technology. So it’s like “seasoning” in cooking — everyone can spice it up to their own liking (If you want to learn more about the difference between web components, this article is a great start).

We started up with a UI Kit in Sketch, and are building from there. The priority is on the most used web elements and their variations.

Let’s look at an example.

“Button”, in its “primary state”, web-components style:

<axa-button>Primary button</axa-button>

In a design system you want to go beyond that though. You want to also show how the design element looks and how is it used. It’s like using one of those cooking apps with pictures or videos — it’s always better to watch someone show you how to cut perfectly a mango for example.

In a design system context, it will look like something of the sort:

Our V1 vision; design is courtesy of my colleague Rémy ;)

It is a one-stop-shop, where you can consult the code of the design element (or the raw ingredient itself if we refer to our kitchen metaphor), and also its live demo (or how this element will behave).

From here, if you want to use a different “variant” of this element in question, you can add up the needed “seasoning” in order to reach the desired result.

For example, below we have five different variants of our “Button”:

<axa-button class=a-button — secondary>Secondary Blue</axa-button>

<axa-button disabled>Disabled Primary button</axa-button>

<axa-button class=a-button — secondary disabled>Disabled Secondary Blue</axa-button>

<p style=”background:#333333;padding:1em”>

<axa-button class=”a-button — secondary — white”>Secondary White</axa-button>

<axa-button class=”a-button — secondary — white” disabled>Disabled Secondary White</axa-button>

</p>

So what are the benefits of a design system? If we go back to the kitchen metaphor, it’s like comparing making a meal from scratch for multiple guests at the same time (checking the recipe, buying the ingredients, preparing them for cooking and finally cooking the meal) vs. taking up the the prepped ones and spicing up the meal in the pan. It saves you enormous amounts of time, and you also make sure that the result will be the same every time — a delicious meal, fitted to your taste! That is also how it works with a design system — it helps you develop much quicker and you make sure there is visual consistency, fully compliant with your brand’s image.

Design systems are a wonderful tool, that can help production teams work more efficiently and have the time to focus on what really matters — evolving their product and meeting user needs — rather than writing repetitive lines of code or designing the next text box. And just like cooking, with the ingredients already prepared, teams have time to get creative, add a pinch of salt, a bit of the fresh mint they bought today, and why not some nice mushrooms, picked up earlier this week. The result will be a delicious dish — all so familiar, but with this special touch that makes the magic happen.

Adopting this way of cooking (and also developing a product, with the help of a design system) is another challenge I would like to talk about, but that will be for another time.

Now I will go cook some potatoes.

--

--

Yuliya Nikolova - Joubert
Demain sera bien. Par Haigo.

Service designer and Researcher, looking to understand the behavioural mechanisms leading our communities; Passionate culinary photographer;