How we envision Design QA at Doctolib
As a Product Designer, it’s essential to deliver high quality interfaces while respecting the graphic consistency of the entire product. Still, the work of the Product Designer is not finished when interfaces are finished in Figma.
There’s still a long way to go!
For some designers it’s definitely not the most interesting part of the job, but Product Designers are responsible for the user experience and the graphic design of the project.
They must take the time to ensure that the design complies with the requirements as soon as it is developed.
This task is called Design QA (Design Quality Assurance).
At Doctolib, one of our priorities in the product team is to improve the quality and consistency of our products by taking into account user needs.
To meet this priority, and to avoid creating more design debt, it was important as a personal initiative to review this Design QA process.
In this article, I will give you as a Product Designer some things to set up as soon as possible with your feature team, then I will explain to you how we’re doing Design QA at Doctolib without adding too much complexity to our organization.
Advice for working in a feature team
Advice #1: Developers are your new best friends
It may seem logical, but designers often don’t communicate enough with developers. If you behave like an outsourcer, you run the risk of being seen like this.
As a designer, you’re an integral part of the team and by getting involved, you will create better cohesion and facilitate exchanges with your team.
For this, you must be present during your team’s rituals (stand-up, retrospective, and so on…).
You can also schedule a special retrospective on the design/dev collaboration in your team to get their feedback. Just below, you can find an example of this type of with one of my feature team, where I’m trying to continually improve our collaboration.
Advice #2: Be transparent about your way of working
For instance, I had organized a meeting with my team to present how the double diamond process is concretely applied, how I work with the design system team, and how I craft my screens in Figma.
This can help to evangelize them further about design and create transparency. Also tell them at what stage of the process they can get involved.
Show them that you are available for them. If you want them to take initiative, they need to feel confident. This will be very helpful for the following.
Design QA @ Doctolib
The Design QA process is taking place at different key moments of the project:
All along the sprint, during the dev time, once the feature is in the test environment and even when the feature is live. The aim of this process is to avoid generating design debt.
Ticket cycle at Doctolib
To do: Ticket is ready to be dev
In progress: Development on going
In review: To be reviewed by the tech team
In validation: Available on the test environment
Done: Validation by the Product manager
After the technical validation, the ticket will be in the “In validation” column.
From there, everything can go very quickly. The feature is available on the test environment after 30 minutes.
There are 2 possibilities after that:
1) feature is isolated > it does not impact production
2) feature is not isolated > it impacts production
There are 3 pushes to production every day and potentially, a feature in “test” can impact the production in the day. So it’s really important to be able to have a vision of what will happen.
That is why I created 3 types of Design QA by taking into account the ticket cycle.
During dev time
Now that there are no barriers between you and the developers, you can organize a peer design/dev session.
It can either be set up by the designer or by the developer.
This meeting takes place during the development phase and is intended to ensure that the dev is in line with the design, by comparing the designer’s mock-ups with the screens in development.
You can also use this meeting to address a technical issue that has an impact on the design. This can help to identify certain graphic issues and fix them in advance.
It’s an opportunity for them to exchange ideas directly and this discussion can lead to other “live” improvement topics.
🤜 Results: Avoid going back and forth and improve the designer/dev collaboration
“What I like is that I can get feedback during the development phase and make changes if necessary on the fly. It really helps me not to waste time and thus to be more efficient.”
Jade, Software Engineer at Doctolib
Pushed on test environment
We saw above that before the new feature goes into production, it is available in a test environment. So at this point, the developer can send a message to the designer and say that the ticket will be moved to the “In validation” column and so the designer will be able to test it.
No need to create here a Design QA ticket, in an asynchronous way, by message or by comment on the existing JIRA ticket.
🤜 Results: the designer is warned to check the dev, and can act before it’s live.
The aim of this process is to avoid creating new tickets for developers as much as possible. It’s up to the designer to be reactive at this stage. The developer can add the mention “Impact on prod” for example on the ticket, it will serve the designer to be responsive.
“For the moment I plan to merge my PR on the “cancel dialog” (PHR-679) at 2 pm.”
Mélanie, Software Engineer at Doctolib
Live on Prod
If the ticket was pushed to production and if there is a graphic issue, the designer can create a Design QA ticket on JIRA to solve the issue and the ticket will be treated during or at the end of the sprint of development.
A JIRA ticket can contain several feedbacks in order to limit the creation of tickets. Generally, I like to illustrate what I am saying in the ticket with “current result” and “expected result” paragraphs plus a Figma link.
Then, I communicate this ticket to my team during the stand-up meeting and the Product Manager or the Engineering Manager will take the ticket into account in the development sprint.
We identified a lot of benefits :
We started to apply this process for one team for 4 months and then extended it to all teams across the product. Thanks to this process, we can:
✨ Ensure the quality of the product
- Avoid new bugs by testing
- Expected design output is deployed during production
- Increase consistency across the product
✨ Improve collaboration and communication
- More exchanges inside the team
- Create transparency
- Educate the team to have a graphic eye
✨ Save time
- Reduce the extensive number of iterations
- Avoid the rework of the code after a deployed feature
- Avoid generating design debt
What to remember ?
💡 Once the layout is shipped, your work is not over.
💡 Make yourself available and keep tracking the progress of tickets.
💡 Work closely with your developer at each phase of the development (pair design/dev session).
💡 Create a JIRA ticket only if the feature was pushed on production.
This process is adapted depending on the team inside Doctolib and is continuously improved. And don’t forget:
The better the design hand off, the easier the Design QA!
I hope this article was helpful for you and don’t hesitate to share your way to do Design QA in the comments below!
