10 lessons I learned owning on a Design System for 30+ Product Designers and 200+ Developers

I was hired at doctolib in May 2020. After one year as a Product Designer, I had the chance to jump to a new role of Design Ops, and in the last 1.5 year the team went from 30 designers to 60 🤯. In my scope of Design Ops, the Design System (Oxygen) is a topic that is getting bigger and bigger. Since then, I never stopped working with designers and developers to improve our processes, rituals, and craft.

Here’s my learnings this last year regarding the Design System.

#1 Be clear on ownership, missions, contribution processes

Period.

The worst thing that can happen when a team member (Designer or Developer) has a request is not knowing how to proceed, whom to contact, where to find documentation. Lack of clarity is always a synonym of misunderstanding and leads to demotivation.

This has lots of side effects also on the adoption of the Design System, and on trust of the owning team.

#2 Follow the 3 rules of the Design System team: Align, align and… align.

A big part of the job is to keep planets aligned:

• Aligning team members about updates (designers / developers)
• Aligning components on every tool and chasing drifts between them (in our case: Figma / Storybook / Zeroheight).

This is a daily task to follow all topics and keep everyone at the same level of information.

#3 Your nemesis has a name: legacy.

If I had to personnalise Legacy, it would be Lord Voldemort. It’s always sneaking around you, like a shadow over your head, and when you think you got rid of it, it’s still here.

Wikipedia has a more conventional definition and considers legacy as anything that “refers to outdated systems that are still in use.”

Honestly, crafting new components on Figma is fun, but the legacy must not be neglected, notably on the tech side, because you always have to try to reduce the gap between Figma component and their equivalent in code. Moreover updating a legacy component is not that easy, as it may require a complex migration if this component is largely used across your product and by different teams.

In your KPIs definition, don’t forget to evaluate the ratio of Component delivery vs. Debt reduction.

#4 You are not alone!

You are not a lone rider, and should not be!

Creating and maintaining a Design System is time-consuming, due to a daily attention to all details. Delegating the creation and reflexion around components by involving Designers and Developers is a way to leverage their skills and then going faster and better. Moreover creating emulation around the Design System will always foster adoption and spread knowledge.

> Our solution: At Doctolib, we have a culture of pair designing and pair developing. Thus, each time a Designer has a particular need, we work with this Designer plus additional Designers who have a specific interest in the topic or are just motivated to help. We also regularly set up task forces for transversal and impactful topics (such as reworking all our Buttons, revamping our guidelines).

#5 100% Design System compliant is a myth

100% Design System compliant designs is a North Star KPI we should try to get closer to, but definitely not a reachable goal. There will always be use cases in which the Design System can’t be fully applied, and needs to be tweaked. Moreover there will always be legacy reasons fighting against compliancy, and/or developers bandwidth issues.

Another point is that a Design System is a living creature, the time to update all your legacy components, you may already have some deprecated new ones, due to new users needs, technological evolution… I think targeting a 80% compliancy is a more realistic view.

#6 Identify Core components vs. Snowflakes

Really linked to lesson #1 about contribution, we had a hard time understanding what should be developed or what should be included in our Design System. The rule is simple now, and relies on usage of a component in our products:

• 2+ usages across our products: it’s a Core component, needs to be added to our Figma Core library and Storybook.
• Only 1 usage across our products: it’s a Snowflake. The Designer can add it to their Domain library, but it won’t be added on the Design System. The feature team will hard code the component and host it on their own codebase.

#7 Masterpiece component vs. efficient component.

I love this one, because I’m a Product Designer, and like you I’m in love with nicely crafted, well refined and polished concepts. I love creating pieces of art. But have you ever tried sitting on Katrina Kamprani’s chairs?

We always want to push the borders to create what I call Masterpiece components, the one that is really powerful, is flexible enough to address all needs, and easily maintainable. But guess what? This component is a chimera. Exactly what happened with the List Item component I created (and I was really proud of).

You need to remember that the users are the Designers, and you have to find the right balance between the quality of the craft and the usability of the component. I regularly have this discussion with my team, and I always prefer multiplying components instead of a single overcomplicated one that won’t be used, and thus won’t serve your design system, and is finally impossible to maintain.

#8 Document E-VE-RY-THING, from the start, always.

Documentation is key, but usually underestimated and always the last thing to be done, and (let’s be honest) it’s painful… But on the contrary, it has to be done from the start to have a record of any progress, discussion or decision. It’s even more important when you’re talking from a component that is on standby for months and you go back to this topic. It will also helps to make your team members more autonomous when they’re looking for some infos.

And as I usually say: “when it’s written somewhere, it’s written somewhere.” 😉 Meaning you always have a base to refer to, and this documentation needs to be accessible to everyone. We are currently 600 Doctolibers in our Tech, Product and Design org, and it’s not scalable to answer each question one by one.

#9 Tools and plugins never stop changing… and breaking stuff.

Figma doesn’t have the feature you want, but is key for you. Fine, you find a workaround, or use a plugin. It clearly does the job. But how long will it do? Your workaround won’t last forever and you’ll get forced to change everything, your process, your component. For instance, when Figma release an update or when your plugin is not maintained anymore. Michael Blancon Tardi, my partner in crime, illustrates this in his last article with the release of the new auto-layout of Figma (during Config22), that made the Swap component we created months ago stop working and generate design debt. That’s why sometimes we need to be reasonable in our choices because a miracle solution can be a thorn in the side some times later.

#10 OVER-communicate

Each time we faced an issue or got pushback from Designers, Developers or Product, it was mainly due to a lack of communication.

Don’t hesitate to communicate progresses, status, ongoing work, and always offer a repo where everyone can find what they is looking for.

Thanks to Gaëlle Malenfant for her illustration and to Mike Winnington for having reviewed this article.