Back

How to develop an online psychotherapy service in the UK and not go crazy

Against the backdrop of pandemic, Purrweb developed a service to find psychotherapists in the UK. Clients approached us for design services but got a fully developed web platform and mobile app. We, in turn, got an hours-long master class on working with a very attentive and demanding client. We’ll tell you the way things were.

Reading time: 7 minutes

Table of contents

    More than design

    Kate Robinson and Mirsad Mustovich contacted us in the autumn of 2020. Kate has a PhD in clinical psychology and she’s been a licensed counselor for 10 years. She specializes in trauma therapy, anxiety, and depression. Apart from counseling, she reads lectures. And Mirsad specializes in management consulting — he was our client. 

    Kate and Mirsad wanted to combine their experiences and create a therapy service with custom features like calendar, notes, chat, and video calls. They asked us to do the design for their future app My Therapy Assistant. We did it but Mirsad stayed with us to develop a mobile app and a web service.

    We built a team of developers and designers, a QA specialist, and a project manager. Little did we know that we would have two managers — Mirsad was so involved in the process that sometimes we thought he was a Purrweb employee. But we’ll get back to it later.

    Unnatural selection

    To start working with My Therapy Assistant, a month-long online course in psychology is not enough. The platform is very selective — here’s what you need to get an account: 

    • MA or PhD in psychology,
    • at least 3 years of practice,
    • at least £1,000,000 of indemnity,
    • a DBS certificate,
    • an ID.

    When a therapist creates an account, they fill the form, give the data from this list, and undergo an interview. After registration they have to meet these requirements: 

    • set time slots for at least 5 sessions a week;
    • keep their calendar updated;
    • answer patients when they want to cancel or set up a meeting within 6 hours. 

    If therapists reject more than 5 requests in a row, service moderators contact them. Moderators have the right to block the account.

    It’s much easier for patients: create an account, customize your profile, decide on the goals — and you’re done. You can also take a survey, and the platform will set you up with a therapist. If it’s not enough, the platform has a chatbot. It will ask you more specific questions from preferable gender to payment options and it will set you up with a suitable specialist as well.

    Surprise me!

    There are too many similar apps on the UK market, so My Therapy Assistant is not a unique product. But it’s different from its competitors in three ways:

    • Custom features: calendar, notes, chat, and video calls. We could have used ready-made solutions for almost all these functions but the client wanted to make them from scratch.

    • Adaptive screen: it’s more than adaptive design — we calculated not only the screen’s width but also its height. It’s not an easy task. But, for example, a desktop app will display the whole function block without distorting the proportions or having to scroll down — even if you open it on an 11-inch laptop screen.
    • Window management: you can minimize a video call window and use other app features simultaneously — like making notes during your session.

    Tech stack-wise we used all the reliable frameworks and instruments: 

    • Next.js for web frontend — we needed this for search engine indexing,
    • Nest.js + GraphQL for backend,
    • PostgreSQL for data storage,
    • React Native for the mobile app.

    Role playing

    We divided the development process into 14 sprints:

    1. Frontend and backend architecture.
    2. Authorization. We used Auth0 and SendGrid for sending a confirmation letter after registration. We usually go with Auth0 for authorization through social networks — in our project we added this feature for patients. This solution is also good for quick authorization building. And we went with SendGrid because of convenient letter templates and API. 
    3. Onboarding.
    4. User flow for finding a therapist.
    5. Creating a schedule for therapists.
    6. Patient’s dashboard.
    7. Chat.
    8. Video calls.
    9. Payments. During this sprint we started working on a mobile app, so we also did mobile architecture, onboarding, and registration.
    10. Feedback on therapy sessions and income management. Mobile app: finding a therapist.
    11. Admin dashboard and email notifications. Mobile app: finding a therapist. 
    12. Insurance integration. Mobile app: income management and patient’s dashboard. 
    13. Preparation for the release and debugging. Mobile app: chat and video calls. 
    14. Setting user behavior analytics. Mobile app: preparation for the release, debugging, release.

    Service is very detailed for every user role. For example, patients can monitor all the previous and upcoming sessions, make notes, keep all the materials for therapy in one place, and track therapy goals. They can also chat with therapists and look through doctors’ profiles. 

    Therapists can see their schedule, calendar, income, and patients. Admins look through registration requests, existing profiles, and patients’ data, which is the requirement of HIPPA and GDPR.

    Many opportunities means many screens. And here’s where things went wrong.

    Screens for everyone

    Three roles require approximately 100 screens. It was even before we agreed to develop two apps — web and mobile.

    During development we stuck upon emitted edge cases. For example, the doctor’s availability in the distant future. Rarely patients wanted to schedule a session not for the next week, but in several months. But we didn’t have any screens for this scenario. We discovered it when our team was already building the app. 

    Since we worked on the final release instead of an MVP, this was an urgent problem. Our client wanted to go to the highly competitive market with the final product, so we refined this case. 

    Insurance issues

    Western medicine works closely with insurance companies. Many clients have insurance that covers psychotherapy. To allow clients to use their insurance cards, we had to integrate My Therapy Assistant with an insurance aggregator. Mirsad suggested HealthCode, which is the largest and the most popular British healthtech service. 

    When we received HealthCode’s API description, we were discouraged. This document was a useless incoherent mess with outdated descriptions. Our team lead had to hold a long conversation with HealthCode tech support to get the necessary data.

    Even worse, HealthCode’s API uses an obsolete data exchange format — SOAP. Our app uses JSON, like the rest of the world. That’s why we had to write a module to convert queries to our format, which was time-consuming.

    We could test HealthCode’s API only when a real client tried to pay with their insurance since it doesn’t have a sandbox. We braced ourselves for the first payment — and when it was successful, we were in high spirits. But the UK has a lot of insurance companies, so later we had payment failure cases. We worked on all of them with HealthCode’s tech support to fix all the integration bugs.

    Another manager

    We like the clients who are eager to get involved in the project and take part in it. Mirsad was one of them. He was tracking the development and actively taking part in our group chat. But sometimes his micromanagement was too much — as if we had another PM in our team. 

    It led to conflicts. At first we discussed solutions, implemented them, and got back for the client’s review. But during the presentation Mirsad was asking for a different implementation — even though we reached an agreement earlier. All this rework is time and money — and it’s not always obvious for non-developers. It’s only him who thinks that it’s “easy” and “requires just one more line of code”. 

    The truth is, service issues and new features are almost never fixed or added with just one line of code. It’s hard to explain but it’s crucial. If you don’t find common ground with your client, you’ll end up with mutual dissatisfaction. And all the pent-up grudges will lead you to a failed project.

    That’s why we never stay silent in such situations. I invited the client to a “confessional”. We spent 1,5 hours on negotiating because we wanted to make the communication pleasant, crystal clear, and comfortable both for him and our team. 

    This resulted in the following action plan. We promised to:

    • write down all the agreements after every Zoom call,
    • invite Mirsad to daily standups,
    • schedule a quick 10-minute call with our QA specialist and our developer in case of unexpected issues.

    And Mirsad promised to:

    • give up micromanagement and track our progress during daily standups,
    • perform a priority check instead of adding urgent tasks to the ongoing sprint,
    • respect our task evaluation. 

    After we reached this agreement, the development process became much more productive. We had some disagreements later but, since we implemented writing down all the important points after each Zoom call, we solved those problems quickly.

    Coding and diplomacy school

    The project took us 8000 hours. The service became available to users in the middle of April. Kate switched several offline clients to My Therapy Assistant and runs sessions in the app. Recently My Therapy Assistant got a new doctor — it doesn’t happen fast due to rigorous selection. At the moment of finishing our case study Kate conducted 69 sessions and a new therapist did 2.

    Mirsad is currently working on marketing and promotion. And we keep supporting the project — right now we’re refining two intended features: 

    • a chatbot that helps users choose a therapist by asking questions and suggesting doctors’ profiles, 
    • push notifications with reminders of upcoming sessions or new chat messages.

    And to me working on My Therapy Assistant became a negotiation workshop and a source of insights on project management. We always work with clients because each app is their idea and they’re experts in their own fields. And we are experts in development, design, and usability. Sometimes those expertises overlap — and that requires negotiations, management, and looking for a compromise.

    You can find common ground with your client and come up with a solution if you follow these principles: 

    1. Write down agreements after every call.
    2. Don’t be scared of omitting something. It’s impossible to include everything — but with a good team you can quickly implement what’s lacking. 
    3. The main management pain point is third-party integrations. Discuss risks with your client — you can even invite them to the call with a third-party service representative. 
    4. If you feel uncomfortable, discuss this issue with your client and explain that micromanagement doesn’t work. Try and make your job as clear as possible — provide your client with daily and sprint reports.
    Management
    • Dmitriy Larin
    • Svetlana Kolpakova
    Design
    • Anastasia Martyan
    • Ilya Utkin
    • Valeriy Boiko
    • Julia Vakulenko
    • Polina Tolmacheva
    Development
    • Vladislav Severin
    • Vladislav Dyubov
    • Ivan Zhukov
    • Linar Ayupov
    • Nikita Maksimenko
    QA testing
    • Tatyana Perina
    Content
    • Anton Kiryukhin

    How useful was this post?

    Rate this article!

    5 ratings, аverage 5 out of 5.

    No votes so far! Be the first to rate this post.

    As you found this post useful...

    Follow us on social media!

    Share