Design system : enthusiastic updates or systematic efficiency?

Michael Blancon Tardi
Doctolib
Published in
6 min readJun 30, 2022
“To update, or not to update: that is the question: Whether ’tis nobler in the mind to suffer” — Shakespearegma

As a Product Designer dedicated to Oxygen, the

Design System, I’m always searching for well-crafted components with smart structured layers.

When starting to design, our main concern is to ensure good user experience, an attractive UI and overall consistency (for design and tech teams)… We agreed that these are the basics.

We go the extra mile by imagining ourselves as new joiners at

, or, for instance, someone who is a total stranger to using Figma. It helps keep the components library easy to handle and understandable for everyone.

👯‍♀️️ Assemble! 👯‍♂

At

, designers are split into autonomous Feature Teams with dedicated topics and roadmaps. Each team is made up of Product Manager, Product Designer, dedicated UX Researcher and UX Writer, Data Analyst, Tech Stakeholder and of course Software Engineers.

As the Oxygen team is young, we just recently adopted these same principles.

When I joined this dream team as a full time Product Designer last January, we were two designers and one Software Engineer who worked part-time with our team.

Now, almost 6 months later, we are 5!

…And the power is ours!

This pump-up team allows us to get better and better at rationalizing projects, challenging existing production processes, delivering higher quality design standards, tooling the Design System to be more efficient, and putting KPI milestones on our roadmap.

…Ok ok, I get it… “Je tourne autour du pot” (as we say in french for beating around the bush).

But it was important to tell you about the background of our daily tasks and jobs so that you understand the rest of this post.
And that being said, there are so many tasks to be done in our Design System, and the main goal is to reduce our tech and design debts or custom legacy interfaces parts.

🆕 Components 💠

SO… At the last Config 22 from

, some exciting updated features were announced (great work by the way, congrats to the team! 👏🎉):

  • Auto layout
  • Absolute positioning
  • Negative spacings
  • Components properties…

These changes will let us improve our ways of crafting user interfaces.

As I mentioned earlier, we have what we call “debt reduction” as a KPI. Regarding my scope as a Product Designer, it means that I have to check if our existing components are:

  • Well-crafted at structure and layers levels,
  • Easy to use for the design team,
  • Aligned overall (usage of tokens, name conventions, reused components as nested…)

Honest statement:
Some of our actual components are still using Figma’s deprecated auto-layout versions!

When I find an opportunity to improve something, to build it in a cleaner way or just make small enhancements for the better, I deep dive into it.

But tackling these “small” tasks, in addition to supporting designers in their Design System challenges, is almost a full-time job — and as a team of 25 Product Designers, we can’t always afford it.

So with my Oxygen team mates, we were wondering:

“Should we always strive for an up-to-date Design System?”

⚖️ Yeah or nah?

Getting an answer was quiet simple — we started by listing the Pros and Cons:

PROs

  • Well-built components
  • Improving end-design quality (each Figma update brings superior craft level)
  • Less complex layer structures
  • Less master component variations
  • Quicker use for designers (Properties efficiency)

CONs

  • It takes a looooot of time!
  • Management of deprecated components (which can be tricky and we don’t want to break component instances in all our design files… — with great library comes great responsibility)
  • Guidelines need to be updated and even rewritten
  • Workshop to share design updates (with all Designers and some Product Managers, Engineers…)
  • Updating old design pages (Product Design concerns)
Previous Pill VS new Pill master component sets (yeah, we also shine from our reworks)

🔀 Workarounds

As a Design System team, our job is to facilitate the daily work of the Product Designers in each Feature Team. So each time we create new components (especially complex ones) we aim for the right balanced workflow in Figma.

That means not using too many overkilled properties, managing enough flexibility and ensuring layers construction efficiency with few nested levels.

We try to avoid more than 3 layers of levels — like dreams in Inception

Before Config 22, we had to find workarounds for:

  • Swappable components in order to bring modularity
(For instances: The pink area displayed on modal, drawer and card content, etc…)
  • Overlapping items with frames such as notification badges
(For instances: avatar status, badges, floating label inputs...)

These smart ideas and extra efforts that we accomplished, are now useless…

And we actually lack Figma Design Tokens management… We are aware that some plugins are clearly doing the job but we don’t want to create dependencies to plugins on this strategic core topic!
We know it will soon or later be addressed by

… isn’t it? 🫠

As with the new boolean feature in components, we need to have property dependency in order to have clearer componant usage and fewer variations (for example, property B can be toggled if property A is true).

In the meantime, we have yet another workaround to process and again, a rework to plan in the near futur

Hey

team, it’s a call for help! 🆘

⭐ Stage notation ⭐️

Thanks to

‘s tech mindset, we end up by adding notation to our components. That helps us identify where we have to focus and what we need to prioritize on roadmaps, and obviously tackle old deprecated components first.
This also gives Product Designers a trust indicator about a specific component.

The mastermind behind this is quite simple:
We listed 10 rules that we consider vital to a component life cycle, which are grouped into 5 families:

  • Design quality (to know if it’s built in the best way)
  • Storybook (to check consistency)
  • Compliance (to apply generic rules such as web accessibility)
  • Design debt (to keep an eye on our main concerns regarding updates from Configs, the icon library or deprecated craft builds)
  • ZeroHeight documentation (to keep publishing up-to-date guidelines)

And there are 3 levels:

  1. Stage 1: That’s some sloppy work, or deprecated ways of crafting
  2. Stage 2: OK, we can live with it, but we can do it better
  3. Stage 3: Only Batman can improve it with Bat-Gadgets 😏
“One component stage to rule them all” Sauron on a Jira board

This work is also done in Storybook but with tech-driven criteria.

This solution was chosen by the Oxygen Design System team and we take it as the key goal to satisfy our main users, our team members!

So we choose to save our breath for the long run, making changes step by step. The best advice we can give you is:

  • Track your weaknesses
  • Plan for acting quickly and effortlessly
  • Blend your ideas with your teammates (meet with designers, software engineers, stackholders, managers..)
  • Keep in mind that consistency is a master key (as is being patient)

If you want to push forward this topic forward, feel free to contact me or leave a comment.

And don’t forget that we are searching for more team members to get the long-term run jobs done! Sounds tempting, huh ?

👉 Check out our open positions here 👈

Special thanks to:

--

--