LVNDR Health · App and Dashboard
Designing the UK's first LGBTQIA+ sexual health clinic
Summary
I joined an early-stage startup with years of research and no product. In three months we launched a full clinical service, with a patient app and a clinician dashboard built in-house. This case study is about the system behind it, and how we got there.
The pilot scored 93 on NPS and 83 on the System Usability Scale.
Startup chaos
Assessing LVNDR's status and roadmap
Picture this. A startup with a big idea and an even bigger heart, but a bit all over the place. When I joined, we had tons of research and barely three months to put together a full service supported by two systems: a patient app and a clinician dashboard. It had to provide healthcare securely, to an audience that needed extra care. And we still didn't have a fixed pilot goal, because the commercial proposition kept changing, sometimes every two or three days (with time I understood this is normal when setting up a company).
Did I think it was insane? Yes. Did I tell my new team? I did. Did I think about taking a camper van to a remote town in Indonesia and opening a beachfront chiringuito? Also yes. But as we say in Italy, since we're in it, we keep dancing. And I danced.
Some of the patient app screens
Scope
From user stories to deliverables
When I joined, the project had a much broader scope and no clear list of deliverables, only a collection of user stories. Through a series of work sessions, I helped prioritise and translate them into actionable deliverables, focusing on what would bring the most value.
This led to a scoped-down list of key features for both platforms.
Key deliverables for the app and the dashboard, after scoping down.
The first three months
From strategy to screens
I started in a much more managerial and strategic role. I analysed launch priorities and ways of working, and helped define product metrics.
I only started wireframing in July, because before then the roadmap and deliverables were still unclear. The app and the dashboard were designed in tandem, since every feature on one side had an effect on the other.
A simplified view of the first three months, up to launch.
How we worked
Weekly design sprints
To get things done within a tight deadline, I gave clear responsibilities and domains to my design team, a junior designer and a design intern, and set up weekly sprints. The development team was waiting on designs to start both backend and frontend, so we had to move fast without skipping the design process.
I knew this pace wasn't sustainable, so the plan was explicit from the start. High intensity until launch, then back to a more thoughtful process to avoid burning the team out.
Mon
All-hands
With the whole team, understanding the weekly focus and needs.
Sprint kick-off
Feature kick-off with product, design and dev to align on the week's focus.
Design
Research and first draft of the user flow.
Tue
Clinic check-in #1
With the clinical staff, to make sure designs meet practical requirements.
Design
Wireframing.
Design and dev session
Showing the initial work and gathering technical constraints.
Wed
Design focus day
Refining flow and wireframes, starting the UI.
Design critique
Checking there are no blockers, gathering feedback and auditing components.
Thu
Clinic check-in #2
Showing wireframes or a low-fi prototype, to gather feedback and make sure there's no misunderstanding.
Design
Refining the UI.
Fri
Demo day
Showing the high-fidelity prototype to the whole team, to see if it's ready or anything is missing.
Design and dev handover
Handing the work over to the tech team.
Outcomes
What the pilot told us
Redefining everyone's responsibilities made the work smoother. People could focus, results came faster, and seeing the first UI every Friday made the team more motivated, even in a very stressful pre-launch phase. Despite some delays outside our control, the designs were ready for launch.
In January 2023 we started collecting the first metrics from a controlled group of 100 users.
93
Net Promoter Score, against an industry range of 40 to 61
4.8/5
Customer satisfaction, against 3.1 for standard care
83
System Usability Scale, against an average of 68
4.8/5
Likelihood of switching to LVNDR when publicly available
LVNDR vs existing services
LVNDR
Existing services
Pilot user metrics, collected by LVNDR after launch with a controlled group of 100 users.
After launch
Where the real value was
Once the service was live, we realised that the biggest value for the whole service sat with the clinicians. They were used to pen and paper and to very outdated systems, and a lot of their time went into taking notes. Improving their experience meant better consultations, more value in every session with patients, and less note-taking weighing on them.
Before launch I was mostly focused on the patient app. Once it had reached a good level, I moved on to spend around 90% of my time on the dashboard, on the logic behind the two systems and how they interacted, and on how the backend and the third-party services we relied on actually worked. The dashboard became the main focus of the company.
It meant jumping from one system to the other, and getting to know the whole service, its complexity and all the different people who were part of it.
The dashboard
An operational backbone, built in-house
The app and the dashboard couldn't exist without each other. Patients shared tests, answers and consultations through the app, and clinicians had to review, act on and follow up every one of them in the dashboard. LVNDR was also CQC-registered, so every clinical step needed safe record keeping and clear accountability.
Given how sensitive the data was, LVNDR wanted all of it handled internally, without third-party services. So the first version of the dashboard launched together with the app, built in a rush while I spent most of my time on the app. We agreed it would be a base for what the dashboard could become. The patient history, for example, had to hold all the data and the unique challenges of each person. In v1 it was a toggle that opened a sort of Word page, where clinicians wrote notes as they already did outside the system. The one thing it added was that notes were linked to the patient, so already categorised. Far from what we wanted, but it meant the service could go live with every piece of patient data under our control.
To make it possible, the Product Owner became my assistant for research and wireframing. While I worked on the app, they ran sessions with the clinicians to understand their needs, and turned them into rough wireframes. We met every day. They showed me what they had, and I directed what to get out of the next session with the doctors. So when I had more time for the dashboard, I wasn't starting from zero.
The Labs page, where clinicians review results, order new tests and follow every alert and status change.
Mapping the system
Every patient, every status
To design the dashboard I first had to map the service as a system. I built a service blueprint of the PrEP journey, following each patient from sign up to prescription and linking every step in the app to what happened in the backend and in the dashboard.
Service blueprint of the PrEP journey, from sign up to prescription.
View in full (PDF)Alongside it, I mapped how the app and the dashboard talked to each other, so that every action on one side triggered the right thing on the other.
How the patient app and the clinician dashboard interact.
View in full (PDF)That's where the hard questions came up. When is a patient simply waiting, and when are they blocked? When do they count as lost to follow-up, and what should trigger it? Each status needed a clear rule, because each one meant a different action for a clinician.
Care plan, stage, status and alerts, and the action each combination makes available to a clinician.
Take consultations. A patient who hasn't joined the call after 15 minutes becomes a no-show, and a no-show or a cancellation can mean someone at LVNDR has to follow up by email or phone. Even a status as simple as “late” came with a question to answer first. How would the system even know?
Exploration of consultation statuses, what triggers each one, and the questions still open.
The people on the other side of the dashboard were just as varied. We started from two very different users, an admin who managed everyone's shifts and a full-time clinician, and even among clinicians, seniority changed what someone should be able to do. Every rule in the system had to answer two questions. Who can see this, and who can act on it?
Dashboard personas, used to decide who could see and do what.
Iterating after launch
From v1 to v2
After launch we released v2, and then further versions, while the service was running. In v2 the patient history moved from free notes to tables, so information was easier to read. Every answer a patient gave in the app's modules had to be validated by a clinician during the consultation. So instead of asking every question again, clinicians only had to confirm the data, which made consultations much faster. If an answer changed during the call, the clinician could update it in edit mode, which highlighted what had changed from the original. Every piece of information could be traced.
v1
At launch
The patient history as it launched with the service.
v2
After launch
The same patient history after the v2 redesign.
v2
Edit mode
Patient history in v2, in edit mode.
Impact
What changed for clinicians
With patient information collected before the consultation and everything a clinician needed in one place, appointments got shorter and each clinician could see more patients. These are service-level numbers, the result of the questionnaire and the dashboard working together.
What I learnt
Collaboration in healthcare is a safety issue
Miscommunication can escalate into patient safety and business risks. Working with LGBTQIA+ specialised clinicians was crucial, for their medical expertise and to navigate the biases still built into how LGBTQIA+ health is understood.
“We're a startup” is not an excuse
I had to make compromises, test less than I wanted and work within a flawed design system. But I refused the “we're just a startup” mindset and kept a structured process, even if it moved four times faster. One of the first things I introduced was regular design critiques, a safe and open space to check in with the junior designer and the intern and grow together. After two months both roles were cut, and for the next two I worked practically alone, until a part-time freelancer joined. At one point the workload was such that I trained a project manager to take on some early design work.
Designing the service, not only the screens
Jumping from the app to the dashboard, and from there to the backend and the third-party services, taught me to see LVNDR as one system. Every change on one side had consequences on the other, and on the people using them. Maybe that's what service design really is.
Next up
