Oxygen

Since our creation in 2013, we have had one purpose: strive for a healthier world.

To achieve this, we’ve developed a human-centric approach to innovation, focused on two main missions:

1. Improve the daily lives of care teams, powering them with a new generation of technologies. We believe that care teams are the center of our healthcare systems and supporting them is the best way to look after patient health.
2. Improve health for all, helping them to have a fast and frictionless access to care, manage their health more easily and receive preventive and continuous care.

Design System Name

• Oxygen

Design System team size

• 5-10

Design System team make-up

• 2 Designers
• 4 Engineers
• 1 ProductManager
  1 Data Analyst

Governance model

Hybrid

Governance approach

The Design System team is part of Tech and Product Domain which includes more than 600 people working daily on Doctolib’s new features. 

Having a dedicated team for the Design system has imposed itself quite naturally. Truth is our design system was created long after the company and it was very artisanal until the birth of the DS feature team. So, we already had this mindset of leveraging people to help us craft or maintain components and guidelines. Moreover, the Design System Guild that  was part of the road since the beginning is a real help for us and a door to enter inside feature teams’ life. Second point is really pragmatic: with so many users asking for help, requests or improvements, the federated and centralised models would have been really complicated to deploy. Moreover, regarding the centralised model, as we perceive ourselves as a support team providing tools to other teams, we need to closely work with them and we don’t want to be the one deciding for others and giving top down decisions. As we are seeking for adoption this model is not an option for us.

Governance’s challenges

​​The current main challenge for us is fighting legacy codebase. On Figma we are on track with the design system, but not on the code side.

Our approach to solve this challenge is all about evangelization, knowledge sharing, and collaboration. In addition, we’re backing us up with metrics we previously worked on. Basically the plan is: 

1. Provide each feature team a precise overview of their own legacy through metrics: DS compliance of all the files they own, number of deprecated components or properties used, number of components that need to be migrated, accessibility criteria or ESlints rules… So, they can already fix issues on their own, or at least avoid generating new debt. 
2. Oxygen roadshow: we approach all teams through a dedicated program. We are taking time to (re)introduce the DS to each team one by one, and deep diving on their debt together. Then we are providing one dev day to do some pair programming and fix some issues. It’s also a good time to meet and collect feedbacks about our Design System.
3. We are supporting teams in their effort of debt fixing, through open hours everyday, and pair programming sessions. In parallel, we evangelize a lot of the debt fixing topic to top management to allow some time to teams to fix their debt.

Something we successfully accomplished was around ownership of DS and supporting teams. In the past, when our team did not exist and DS had no ownership, every developer was editing the design system, and designers were doing the same on their own. Which led to a period where we had a bipolar DS with lots of discrepancies between Figma and Storybook (called drifts). And this situation was creating lots of misunderstanding, bad craft and then tensions between teams. Then we worked two realign Figma and Storybook, and decided to create a process called Oxygen Update Proposal (OUP) not to generate drifts anymore. This process is a document anyone can create to suggest an improvement, a creation or an addition to a component or a guideline. Then, we are able: – to track all the requests in one only channel visible by anyone, – understand the why – understand the impacts on Figma and on production – and with different validation steps. The major benefit is to have all in one place, and this document is a base to open discussion with teams. Once design has validated and tech scoping is validated too, the team can start working on it on their own or during Open Hour. And we discovered that it fosters discussions between designers and developers that were not used to work together, and honestly it’s a good way to create connections between those two worlds. Moreover it’s helping developers gaining some front-end skills working with DS developers. Since we released this process at the beginning of the year more than 40 have been written, 12 implemented, 5 rejected, and 12 to approved and to be implemented.

Next challenges for us are multiple: 

1. Still on this legacy fight topic: implementation of tokens. This is a huge topic, and aside the tech aspect, we will need to train teams and understand all the logic behind tokens. For that purpose, we already wrote guidelines, and plan to do tutorials that we will share across design and tech teams. In addition, we’ll do several training sessions with designers, as they are more likely to do live workshops. 
2. Improving components’ accessibility: due to the European Accessibility Act that will be deployed in 2025, we are starting to work on our accessibility. The more the DS is accessible, the more our products will be. We already made an audit (230 Jira tickets), including those tickets in our quarterly delivery, and we are setting standards based on ESlints rules. Next steps would be to create better guidelines on the tech side. 
3. Last but not least, our DS is on our monolith on the tech side, which is a real pain. The extraction from the monolith is a big tech challenge.

Our governance helped with collaboration and collaboration by starting from the ground. In the past there were no DS team, and few interactions between Product Designers and Developers. Thanks to this hybrid model, we are well identified as owners of the DS, but as we claim it “everyone is the owner, we’re the gatekeepers”. We have as rule number 1 to be at the service of our internal teams and thus to be reactive. This, adding the OUP process where we meet devs and product designers, and sometimes devs from different teams, adding the Open Hours we hold every day, adding all the interventions we’re doing during rituals, adding the Oxygen Roadshows, we really created a bridge between teams and inside teams. Developers are more inclined to ask questions to Product Designers, and Product Designers are more inclined to see with the developers before the sprint if this layout can be executed or not. 

About efficiency, now that the design system on Figma is clean and refined, our 25 Product Designers can ship faster. All our components have been reworked and optimized together. The properties are matching the ones on the code side, so it’s even simpler for developers too. On our last NPS, we received several feedbacks from developers about their efficiency rising with the design system. Consistency is also significant, even more now that we are tracking DS compliancy on our codebase per feature team. It pushes feature teams to craft compliant code.

From our point of view, the biggest impact is a human one around collaboration. Our governance and the fact we are a team where designers and developers are working hand in hand, really fostered this collaboration mindset that has spread to feature teams. Usually designers are feeling a bit lonely, now that the Design System is seen as a topic including both sides, and we are here in support and for reinsurance, it’s clearly changing the relations. One impact that is not yet visible but will be in the long run is all about setting standards and flexibility. With the codebase at least 80% compliant, once legacy will be an old nightmare, we’ll be able to change or update designs easily, and at low developer costs. Moreover, code quality and accessibility will be also easily manageable.

On the screenshots above (extracted from our latest NPS), we received 35 answers (half dev, half designers) highlighting satisfaction, adoption and efficiency. On the design side as on the code side, our overall DS compliance since beg. 2023 has really increased. On the screenshots below (extracted from our dashboard), you can see compliance of:

• all Figma files
• a feature team
• all features teams