Three key strategies that enabled us to reduce our design debt at Doctolib
“Design Debt” is the sum of all imperfections of the user experience and design processes that appear over time.
Most often, design debt is ignored in the product because in small amounts it has a poor impact on the product and on the development phase, whereas technical debt can considerably slow down the development time.
Nevertheless too much design debt can reduce the adoption of digital solutions and slow business growth.
Another important point is that by allowing the accumulation of design debt, each sprint will require developers to invest more time on the rework of existing features.
As a result, the design debt increases the time to scale future initiatives.
By tackling design debt in our product, we are able to reduce inconsistencies in our product, be design system compliant in order to be more flexible on the next product evolutions and gain credibility and trust through a seamless user experience.
In this article, I’ll give you three key strategies that we have applied at Doctolib to reduce the design debt.
1/ Identify and gather all design debt problems
You can easily say that you have some design debt in your product without really taking the time to collect them.
With 3 Designers we started an audit of the Doctolib website/app and tried to gather all design debt problems on a Figma file. Thanks also to the design system team who created a tool to quickly identify any component which is not in line with the design system of the product.
By doing this task, we identified a lot of legacy components and we shared them internally to put forward the fact that the design debt exists in our product and that we can’t ignore it.
Here is an overview of our work, one Figma page for each part of the product:
2/ Find a process that fits with your organization
Every organisation has different processes, you have to identify them and find the best way to fit into them.
For that I have conducted several interviews with Engineering Managers and Product Managers to better understand how a development team works on a daily basis.
I had 3 learnings :
I have to integrate the design debt issues into JIRA, the daily tool of the developers.
I have to be aware that it will be difficult to prioritize them (due to the development bandwidth and roadmap).
This process can serve all teams, so I have to keep in mind that the whole product team can benefit from it.
So I decided to create a new JIRA board to have only one space, one source of truth to collect all the design debt issues of the whole product.
This board is linked to the boards of each team. If a team has a design debt ticket assigned to them, they can find it in their backlog.
Then, having a dedicated board for these problems also allows us to monitor the evolution of the design debt in the product.
The time had come to create the tickets !
I created a pretty simple template, with 3 sections :
Context: to give a little bit more details about the problem, is it on mobile?, desktop? Do we frequently find this bug in the product? How to reproduce the problem?
Current result: I use this section to put screenshots or videos of the problem with an explanation
Expected result: an explanation of the expected change with all useful links.
After that, to evaluate the complexity of each design debt ticket and to attribute a priority, I used the impact/effort matrix (Impact = on the product, effort = dev time). This step is crucial because developers can not invest too much time on these tickets, so we have to prioritize them.
3/ Collect feedback and evangelize internally
Now that we have a JIRA board with a well-filled backlog, it’s time to communicate internally!
I have divided my approach into 3 phases:
Get feedback from other designers during a meeting, it can also give you new ambassadors who will use and share it.
A presentation in each feature team to explain why it is important to tackle the design debt and to review and validate the workflow with them.
A documentation of the process so that anyone can discover it and start it themselves.
To sum up
This board was used by more than 7 teams during two quarters and we have identified some interesting first results!
Many developers and product managers have taken the issue of debt in design seriously. They have become accustomed to referring to this board and have taken some initiatives.
When teams had bandwidth or identified a related project, they were able to process design debt tickets.
Despite these tickets not being integrated in any team objective, over 26 tickets were processed (on 75 tickets in total) which means 35% of the backlog have been treated.
For instance we were able to rework our splash screen, our skeleton loaders in the app, some UX problems on the app and UI adjustments. Our application is now increasingly design system compliant.
One last advice, if you don’t want design debt to build up in your product, don’t forget to do your design QA properly in every phase of development.
I’ve written an article about this if you’re interested.
Thank you for reading the article. I hope it was helpful for you. If you have any questions, don’t hesitate to reach me on Twitter or Linkedin !
