Pasikalbėk (Let's Talk Group) is a Lithuanian tele-health service startup that connects mental health practitioners with their clients in a most convenient - remote - way. Together with my team, we’ve built a tool for modern day psychologists to do their work effectively and efficiently by conducting online meetings, and leaving book-keeping and marketing to us.

More information and statistics about the project could be found below in the link, whereas in this post I will describe the process of improving the functionality of sending an inquiry to a therapist to book a consultation.

Since the mvp launch, sending an inquiry to a therapist for booking a consultation hasn't changed much. A simplified worklow would look like this:

1. Registration quiz: personal & contact details, counselling topics.

2. View matching therapists and the rest of available ones.

3. Read therapist's bio & send a booking inquiry.

4. Once the inquiry is sent, the initial message is seen within the client's and therapist's chat.

5. The client and the therapist discuss shortly in the chat for a suitable time for a consultation, and the therapist books a slot in the calendar.

With this user journey, after a while we stumbled upon several problems that affected the actual usage of the platform and the satisfaction of our main clients - therapists.

As we have a dedicated psychologist aka Community manager within our team, she helps me with getting feedback from our therapists throughout weekly conversations without a necessity to conduct too many user interviews.

In addition, after checking the Analytics, we discovered such negative outcomes:

〰️ We saw a tendency of too many of total intro (free) calls on the platform with no further continuation with paid consultations.

〰️ The same client wouldn’t usually go to another specialist, would bounce from the platform completely.

〰️ We started to get feedback from the specialists that they are becoming unhappy with the new incoming clients due to too much of vague information on their side.

This information was enough that I could think of conducting a user study on how to improve the inquiry / booking functionality.

1. Understand the issue more deeply to be able to make actionable changes on the UX / UI side.

2. Do a research, create a new iteration prototype and test it with our users.

3. If the prototype and hypothesis are confirmed, launch a new iteration for the booking functionality.

For the whole process I decided to rely on the Double diamond methodology. This method allowed me to clearly identify the problem at hand and leave assumptions behind. It also helped with addressing the challenge more efficiently by not jumping straight into design solutions - instead, discovering the actual needs beforehand simply by discussing first.

What I already knew:

• Our user persona. Simple - it's our therapists who work on the platform. What gave me bonus points is that I already knew exact people with certain feedback - this allowed my to organise a focus group for user interviews.

• Nevertheless, at first I decided to conduct a quantitative research and see if most of our therapists, who work on the platform, may have the same negative thoughts on the functionality. At the time, we had 30 active specialists.

For this part, I had to create several hypothetical statements to either confirm or deny them. For conducting a quantitative research, I used a Typeform app to gather feedback.

Once this part is done, a qualitative interview could be conducted with a couple of certain specialists.

I pointed out these hypothetical statements:

〰️ Most or all of the specialists require to know as much information about the client as possible even prior the first inquiry sent to them.

〰️ A booking inquiry and a short initial message from the client currently doesn’t give any relevant value. 

〰️ Getting as much information from the client on the initial booking as possible would give more value to the further chat and a call with the psychologist.

〰️ In case the specialist understands he/she’s not suitable for the client, they can transfer the client to another specialist. This way we don’t lose the client, and enable other specialists to work on the platform.

With this case, I gave two options of giving answers to my questions:

(A) choosing from preselected variants,
(B) writing a full response by themselves.

Main pain points from our psychologists were these:

Ｘ Patients come without expectations.
‍
Ｘ Patients’ expectations are sometimes too unreal.
‍
Ｘ Patient’s anonymity, that doesn’t create a mutual credibility.
‍
Ｘ Patients don’t respond after their initial request in the message (first message is too chaotic and unclear).
‍
Ｘ They hope to solve all of their problems within the first free consultation (20 mins).
‍
Ｘ Some of the inquiries are just made impulsively.
‍
Ｘ Clients are not ready to get into discomfort with counselling. They are not personally ready.
‍
Ｘ Clients are not ready / don’t want to pay for consultations.
‍
Ｘ Specialists tend to feel that they get too many low-quality clients.

Having taken out the most significant responses about our psychologists’ pain points, we could map them out using sticky notes on FigJam and create a workshop of How Might We (take next steps to get rid of those pain points/improve the flow).

In the end of our hands-on workshop, we were able to vote the most for these ideas:

✓ More control questions for the users prior sending a request to the psychologist.

✓ Clients should be able to choose suitable days and time themselves - saving time in chat later on.

✓ Client should provide info about goals and expectations prior sending the request.

✓ An option to pay advance payment for the upcoming 2nd consultation during the first free one.

✓ Client should be well aware about the first consultation’s purpose.

After the initial stage of divergence and discovery (1), it was time to proceed with:

1. ideation sketching,

2. lo-fi wireframing,

3. testing,

4. hi-fi designs.

I used a pattern of crazy 8’s to sketch out quick ideations on paper and see how certain features can be blocked, framed, etc.

Wireframes and a prototype were supposed to be done for user testing. After I mapped out all the necessary features from the HMW part for the lo-fi wireframe, I was able to create an active prototype to test out with a pool of 3 psychologists.

I call it a Qualitative research and Testing combined.
For that I used a prototype in Figma and asked for respondents to share their screen and go through it during our video meeting.

The testing part allowed me do understand my users (psychologists) even better. This process enabled me to clarify which information is necessary to have prior sending a booking request to the specialist as well as omit several parts (such as any medications used, or a previous records of therapy, as this is a sensitive information that could have an impact on sending/cancelling the booking request).

Eventually, these were the items we decided to implement on our new iteration:

✓ In the booking screen, we clearly state that a client will send a request to the specialist and he is required to give a few of his personal information in advance. We understood it’s a longer process which might end up by clients bouncing, however, with a clear copy we stated that this is relevant to the patient to get the quickest results.

✓ We ask if the client wanted an individual or a couples therapy.

✓ We ask client to explain his problems as detailed as possible, as well as provide therapy length expectations.

✓ We ask clients to choose the best fitting time range for consultations.

✓ We ask to choose if the client wants free intro session (explained within), or a full length paid consultation.

The testing proved that this iteration may help with NPS score of our therapists on the platform, as well as distinguish motivated clients who would be ready to pay for the consultations. Nevertheless, having limited time of our development team, we have postponed launching an update. Yet, expectations to future results with pushing it live, could be:

• The drop-off after the first (free) consultation may be reduced by 20%.

• Bookings for a free consultation and a paid consultation could split 60% vs. 40%. We believe that the questionnaire we'd provide prior sending the request, could actually have a positive impact. This would also mean a bigger profit for us as a company.

• In a short Typeform that I’ve sent to our psychologists, I received a lot of positive feedback with regards to the additional questions in the Questionnaire prior booking (*Select time range*, *Therapy type=individual or couples*).

In turn, specialists could act quicker and schedule time for consultations without going back and forth in the chat with the client (Time frame selection); or transfer them to another specialist (if the client requested a couples therapy, for example).