How do we design for specialists at Doctolib?
“You know nothing as a designer” is still one of the principles I tell everyone when explaining the role of a Product Designer.
It is so important and yet often forgotten. Due to the lack of time or simply out of habit, designers often rush or skip the discovery phase. “We already did some research on that” — referring to a single question during a 30-minute interview, the boss’ intuition and our own biases.
Being a designer is about solving problems, but what happens when your user is so different from you (in a galaxy far, far away…)? You can’t imagine how they feel about a piece of information, what action they will take, and under what circumstances.
This article is about how to design for a certain type of user, but first, for a bit of context, I’ll briefly introduce Doctolib, our products, and users.
What we do at Doctolib
1. The users
Doctolib’s users are also split in two:
- The patients
- The practitioners or specialists
We will focus on the latter in this article.
At Doctolib, we work for all types of practitioners, such as general practitioners, physiologists, nurses, gynaecologists, and paediatricians. Jobs that you are familiar with only as a patient or, in some cases, because some of your family or friends work in this specific field. These users may be in the same sector, but their professional life differs from one another, and thus their use of our products.
What also varies is the context: They may work alone or in a larger health facility, with secretaries or assistants who will also use the software. Here comes the conundrum!
For these different cases, context is everything. A general practitioner will take some daily actions that a gynaecologist will not.
2. The product
At Doctolib, the product is split into several parts with various focuses on different users
For the patient’s side, there is the Patient Health Platform. It allows patients to book appointments with specialists (general practitioners, dentists, physiotherapists, etc…).
Linked to it is the Booking Management System which helps specialists set up their calendars, booking slots, opening hours and profile pages on Doctolib’s website.
Finally, there is the EHR (Electronic Health Records) or digitalized patient records, helping practitioners do their medical consultations, and create and share documents with patients.
Then there is Video consultation, Doctolib Team (an instant messaging solution between practitioners), Doctolib Physiotherapist (you get it…), and a Social Security Card/Healthcare Practitioner Card reader which complements the EHR.
3. The markets
Doctolib is available in France, Germany, and Italy, which adds complexity not only in differing user needs but also legal requirements.
In France, for example, there are a lot of individual practitioners, contrary to Germany. There are also medical assistants (or Medizinische Fachangestellte) in Germany, who can also provide simple medical acts on top of patient management.
Different organizations are linked to the health sector, the Haute Autorité de santé in France and Bundesministerium für Gesundheit in Germany for example. This impacts how people use our products.
What does it mean to design for a specialist?
1. What is a specialist?
For starters, I would like to give a small definition of what a specialist is in this article (and what it means in our daily life as designers).
A specialist is someone with a high level of specific knowledge and skills that are outside of your own knowledge.
It is also someone who uses the product every day to improve productivity.
Anyone can imagine being an Uber passenger, but can you imagine what an Uber driver does on a daily basis?
Oh, you can? Ok.
Everyone knows what ordering a pair of jeans online entails, but only a few can fathom its entire journey: from the warehouse, through customs, to your door. And even less so, what everyone involved in this process is doing to complete their tasks (checkmate)!
I also want to take a moment to differentiate between a specialist and a power user (A user with in-depth product knowledge, the most active, expressive and influential members of your product’s community). They are two different types of people and a specialist isn’t necessarily a power user. We also need to take into account that the use of a computer may vary from one person to another.
I interviewed several product designers, UX writers, and UX researchers in order to better understand what it means for them to design for a specialist.
2. The difficult first steps as a designer at Doctolib
Taking a look at health-oriented software, in general, is like taking a stroll in a maze. When I was introduced to the product I saw how complex, how packed with information, and I would even say how overwhelming, it was.
Your first instinct as a Product Designer is to find ways to simplify it, and that’s when you realize that you are biased and ignorant.
How could you simplify something that you don’t even know about? First reality check.
“I saw how complex the work of the user is and thought this is something else. Medical software, I don’t know anything about it, it feels overwhelming.” — David Brandau, Product Design Manager
You need to take a step back and assess the situation and the users’ flow outside of the software. You need User Research for that!
3. The importance of research
I cannot stress enough how important it is to immerse yourself in the daily life of a specialist.
Interviews, field trips, shadowing, and any bit of information is needed at the beginning of every project. Not only is it important to know more about how the product is used by the users to do their work, but also — to know the(ir) lingo.
Second reality check.
Talking to a practitioner about what biological data they are analyzing when examining a patient is the same as being a grandparent with a grandchild talking about TikTok, Web3, or NFTs. You don’t understand it until you take the time to do some research (I still don’t get it though…).
It will take time but talking the same language is the first step towards understanding the nature of their work.
“It was hard, at first, I am not a Doctor. I started to understand only while observing our users.” — Camille Le Maître, UX Researcher
David, a Product Design Manager, explained how he got through his first months at Doctolib:
- Set up a glossary of terms
- Watch a lot of videos about how the health industry works
- Talk with specialists (Duh!)
- Talk with stakeholders (Designers, Product Managers, Researchers, Customer Care, etc…) or anyone who has any information on the subject
“Context is everything” — Aurélien Réaut, Product Designer
It is important to understand their context on top of knowing how they use the product. When is the practitioner using this feature? At what time of the day? Is it during a consultation or outside? Which time of the day is the most stressful? All these details will make you understand more what the user feels when working.
The more we were talking to specialists, the more we realise how truly passionate they are about their work. They insist on explaining to the tiniest detail what their job is and what information they are looking for when making a diagnosis.
It took me 3 long months to have a better picture of the product, of what practitioners go through, and I am still learning.
4. Co-building and feedback
When Doctolib started to create Doctolib Practice, our EHR solution, co-building with our users was at the core of its development. It has been out for 2 years now.
Today we are still co-building the solution with the help from our users through different channels:
- By posting on Doctolib Community, a forum with practitioners
- By interviewing them
- By organizing pioneers day (We invited several practitioners for a full day of activities, to discuss about their job and how we can help them with our solution)
Each feature starts from user research, but what sets it in motion varies. It can be a comment on a review, feedback from satisfaction, or a data evolution.
We kick-start the project depending on its complexity either by:
- Sharing a form to get some more insights (Quantitative)
- Interviewing practitioners (Qualitative)
- Doing a workshop (Qualitative)
Then after the design is somewhat done, we share it with our users:
- Prototype testing
- Sharing pictures of the design
- Follow-up interviews
If we “don’t have time to run unmoderated prototype testing”, we try to call our users and show our solution while explaining the context. If we still don’t have the time, we share a picture in the Doctolib Community Forum and ask for feedback on what they understood and their questions.
If you don’t have time, do whatever you can to have something, the tiniest feedback is still better than no feedback at all.
Finally, co-building is also possible when the product is launched:
- Beta-testing, constant feedback and follow-up
- A/B testing
- Data monitoring
Co-building is imperative in our craft, a specialist has all the keys we are looking for to come up with the best solution to a problem.
The designer’s role with specialists
After settling on an idea that co-building is imperative and that the specialist has all the answers, you now might be asking yourself: Am I even needed in the conversation? Yes, you are! That’s where the way you conduct yourself and your designer skills come to play.
1. Humility as a keyword
Designing with humility is designing with honesty, you are trying to make a product that works, not the next Dribbble shot of the month. Humility comes from realizing how we will never fill the gap between the years of experiences in the fields that a specialist has and our own comprehension of the health sector.
Each time I design a solution, it is a test of my process. Did I do proper research? Were my questions biased? Did I understand the problem well?
I’m not trying to solve everything at once. The level of knowledge, the complexity of the product is overwhelming. Take your time and ask around for help, a user, a stakeholder, or a colleague that has been here for a longer time.
“It’s impossible to know everything, we need to admit it. We must understand that we are doing 50% of the work, for the rest, we need to ask for help.” — Chiara Angori, UX Writer
I can’t remember how many times I have sat down in front of my design wondering if I’m right, only to look back at a recorded interview with the specialist answering my problem.
2. Empathy and adapting yourself
It is a big challenge for our users to get out of a bad design. Trying to help them change a solution that they have been using for years might be frustrating at times when you clearly see a UX issue. However, the specialist only sees it as a tool to improve the patient’s health, and adding a new way to do something that they have been using for years takes time.
When co-building, we try to explain the work that we do and why we do it. If the user understands why we are adding a new way to do the same thing, it is likely that they will actually love the change.
“We had people being open and other people scared of changes. Communicating clearly has the power to soften old habits.” — Paulina Brygier, Product Designer
3. The art of saying no
This can be intriguing. When you are a designer, you want to provide the best product to your user, the one they want and ask for. However, while designers can be biased, so can specialists.
I realized that, after spending some time designing with and for specialists, they really love their previous solution and will always come back to it in their mind. We always need to be aware that what the user says they want, is not always what they really need.
On the other hand, once you answer one of the users’ problems, they tend to get greedy and wish for more things.
You will be tight on the schedule and while you will want to implement these things, you need to take a step back and ask yourself, do I really need to add this right now? Will it solve the main problem?
4. The struggles of designing outside of the user’s needs
Working with professionals in the Healthcare industry is balancing between designing for the users and complying to certificates’ terms. Some software can be used by some professionals only if they answer a certain set of rules decided by institutions.
Since the Health sector is heavily regulated, we are often asked to answer several needs that are not immediately those of the users. This top-down logic can become a struggle when your job is to apply a bottom-up way of thinking.
Since we are obliged to comply with these rules, we need to find the perfect balance between truly answering a user’s problem and validating the certification requirements.
It’s at this moment that the product designer’s broader perspective comes into play. We need to have the company’s business and strategy in mind when designing. While you may not exactly answer the user needs during these periods of time, it is necessary for your company to do it to be relevant. Your role here is to make the user experience as painless as possible.
And how do we know if our design works? It’s back to user testing, full-circle moment.
To conclude
Designing for specialists isn’t different from designing for any user, it is simply less forgiving.
Since you are not your user, what is acceptable for you isn’t acceptable for the specialist.
In the end, it is when we actually have our users in front of us and they explain how our product changed their life that we can really grasp how important our job is.
One of the doctors in a workshop I was organizing told me about the importance of my work at Doctolib while we where discussing about the display of Biology data.
“You can save lives”
This kind of feedback helps us remind ourselves that even if we might not save lives on a daily basis, we can at least improve the lives of our users.
Thank you very much for going through this looooooooong article. I hope it helped you answer some of the questions that you may have in your own company.
I would like to thank Paulina Brygier, Caroline Vien, Chiara Angori, David Brandau, Aurélien Réaut and Camille Le Maître for their help in the writing of this article. Thank you Manon Moisy for the illustration.
