Design System Mastery: Scaling With Wisdom
Design systems are a trend nowadays aren’t they? Every organization wants to have its own one and that is a great step forward in the design world.
Although, just like all other projects the first thing to do is to define its purpose and gate keepers:
- Where the design system will live in my organization?
- Why should we need it?
- What will it solve or fix?
- Who will contribute to it?
Having a design system is a global key asset for organizations (whatever their size).
However be sure that all coworkers are aligned on its purpose and definition. It is not a dedicated tool for designers only, or some shared code repository to copy/paste, or your brand tone of voice.
As design systems can have many shapes, the pre-requisite is to have its definition written down like the table of laws.
Our main goals are to strive for enhanced user experiences, faster ways to deliver features, and improved collaboration between different teams.
Hence, adding wisdom into every decision, plan, roadmap will make the design system grow faster and scale stronger.
By wisdom, I am not saying to turn yourself into some kind of “highest powered priest of the design law” but to ask questions, understand global flows, believe in agnosticism (mainly for design purposes) and plan for clean answers later.
Organic by definition, design systems evolve and adapt with time and contributions. Relying on agnosticism will foster adoption and increase usability.
For instance:
- From a design system perspectives, imported components will be more flexible having properties named as “show Action” rather than “Add to favorite”.
- Specific labels could mislead users. What is true for one use case is not on others, there’s no point having contextualized labels.
- However, if the “Add to favorite” property takes place in a team library, it makes total sense to have it displayed there.
At Doctolib, we call these teams libraries “Modules”.
Read about our file organization to learn more.
Our design system structure is based on Oxygen agnostic components which allow Modules to be compliant and specific to features at the same time. Thus, we give responsibilities and control to the feature UI but still push core updates like color rebranding or Figma craft fixes.
Be careful with breaking changes, consider spending time to share and follow up with designers if some updates have negative impacts on existing component instances.
Read 👉this article👈 to understand how and why Jérôme Benoit and I rebuilt all our design system components in Figma.
Make yourself or your team challenge every past decision. Irrelevant truths have to be cleaned up, reviewed or eventually removed from design systems.
Modularity has to be the second word that defines your design system.
At Oxygen we decide to have simpler files to manage independent updates:
- Our tokens are now hosted in our Foundations library (all the variables, font styles, shadows etc..)
- The Toolbox library which gathers all the helpers components that are not part of the official design system
- We also have an Icons library because icons are formatted to frame their usage
- Oxygen components, our clean components mirroring the codebase
- Design guidelines are split into several libraries to be managed by Oxygen and the UX Writing team (and instances are displayed next to each Oxygen components)
- And finally, multiple Modules libraries to allow all designers to manage their specific uses on the go
When I joined Doctolib on January 2022, the structure of our design system was less mature. We only had 3 libraries for all of these… the Foundations, Icons and one Core Components.
We struggled managing everything, the files were sooo heavy and every designer relied on the Oxygen team to update their specific uses of components…
Too much to follow, too many cascading updates to publish and way too many discussions to have with each designer.
We were lost and completely overwhelmed by an unmanaged workload.
One by one, we created new Module libraries and cut / paste what needed to be excluded from our design system truth.
💡 Pro tip
Cut (⌘+X) and paste (⌘+V) to preserve all instances linked to their master components if you have the Figma organization plan with library features
Thus, step by step, we challenged, re-crafted, improved components and their uses or removed unused ones. And we still have to perform this delete rework on some part of our libraries.
The most important was to define our vision and improve loading times for these large files (because it was too much painful.. several times a day).
Prioritizing this huge amount of work by impact/effort and through tech scopings, synced with JIRA sprints prevented us not losing our minds too much.
Above all of that, keep in mind that design systems’ statements are not there for eternity. These truths adapt over time, what is settled today may not be true tomorrow.
After all, a design system is a living thing built by humans, and humans make mistakes. Embrace trial and failure, this will allow your components, guidelines or processes to get refined and more accurate. And moreover, some of the best product features happen because we try ambitious things, fail, learn from those failures to build a better product.
When working on a design system, 3 pieces of advice to always keep in mind:
- Don’t blindly trust others (can also be applied for big companies).
What works for them may not be true for your organization. Double check these facts and keep what is working for you. If not, adapt it till you can defend it with confidence.
👉 One good website to follow concerning accessibility rules (thanks to Emyly Vo, our accessibility expert). - Always strive for feedbacks. All team members will have good advice or a fresh new perspective that has not been identified.
👉 Share and show your work in progress to anyone relevant, tech people, product people, brand team and obviously other product designers (not only the senior ones, junior profiles can also have really constructive ideas). If you can, ask outside your company, solo designers or freelancers, try to pair with trustfully partner. - Failure is not the end. But one optional step to have it done right. Doubts are also part of the process, exception made if you are a bloody genius.
👉 Doubting is a great way to challenge yourself at any time, any moment of any processes. Embrace it, wipe out these till you are confident with your work.
Thank you for reading this post, feel free to reach out to me if you want to share your thoughts on this or related topics. I’ll be happy to have your feedback 🤓
If you want to be part of the Doctolib adventure:
- 💠 Oxygen (Doctolib’s design system) is looking for an Engineering Manager, DM me on LinkedIn.
- 💼 The design team is also looking for 2 senior product designers here and there.
- 💡 But there are also other open positions, check this link.
A big shout out to the 🙌 Oxygen team 💫
And a special thanks to my reviewers
👉 Mike Winnington💂 from the UX Writing
👉 Vanko Yutian Zhou ✨ from the Brand team
📸 Credits for the cover picture: Duran Ekiz
