Closer Look · About 6 min · 4 chapters
Making Patient Stories Visible
I built the stories from conversations with former patients, anonymised session transcripts and clinician interviews. Patient Story posters and a Patient Spotlight talk gave the team a concrete reference for who we were designing for.
Patient Story posters turned research into a reference the team could keep returning to
Mapping the Whole Patient Journey
I referred myself through the service on a test account and combined that first-hand walkthrough with interviews across Clinical, Patient Services and other teams. Mapping what patients did, thought and felt showed where uncertainty accumulated across the whole journey — not only inside the therapy platform.
I then used UX comics to make a better experience tangible enough for the wider team to discuss.
Mapping the full patient journey showed where uncertainty and friction built up before therapy began, between appointments and inside the platform
Breaking a Long Application into Manageable Steps
Patients found the therapy application long and stressful, and many abandoned it. The questions were fixed by NHS requirements, so making the form shorter was not an option. The real task was to make it feel manageable.
I broke the same questions into smaller groups, added visible progress and saved each step automatically. People could pause and return without losing their place.
The same required questions, broken into resumable steps with visible progress
Showing People What Happened Next
After the questionnaires, Patient Services reviewed whether someone was clinically suitable and assigned a therapist. None of that was visible to patients. During the pandemic, when waits reached around thirty days, the silence felt like being forgotten.
We could not shorten the wait, but we could show where someone had got to, what was happening behind the scenes and roughly how long it usually took. Internal reporting after release noted lower application drop-off and more patients reaching their second session.
Application status and expected wait times made an unavoidable delay easier to understand
Explaining What the Questionnaires Were For
Names such as PHQ-9 and GAD-7 intimidated patients, and people did not know why they kept being asked the same questions. With a clinical colleague, I audited every questionnaire, gave each one a patient-friendly name and explained what it measured and why it mattered.
In usability testing, participants understood the purpose more clearly and were more willing to continue. Showing one question at a time, adding progress and allowing people to resume made the task feel less daunting.
Patient-friendly names and descriptions explained what each questionnaire was for
Putting the Results into Plain Language
Results were originally presented as graphs and long lists. Without an explanation, they were meaningless at best and alarming at worst — especially because it is not unusual to feel worse before feeling better in CBT.
With a clinician, I rebuilt the page around the questions patients actually had. A plain-language explanation came first, followed by more detail for anyone who wanted it, including why symptoms can rise before they fall.
Progress was explained in plain language before the detailed scores and answers
Setting Expectations After Session One
Some patients left their first session feeling discouraged. They expected to feel better immediately, or had not yet built a connection with their therapist.
The session ending normalised slow progress and offered a route to resolve fixable concerns
Turning Feedback into Something the Team Could Use
Patient feedback existed in a database but was rarely read. I added NPS and free-text questions to the post-treatment survey, then worked with Data on dashboards showing satisfaction over time and comments by score and diagnosis. The new NPS measure recorded a score of roughly 40, giving the team a baseline for future releases; the survey also created a pool of former patients willing to take part in future research.
We also defined product events that connected ieso’s second-session measure to the earlier stages of the journey. Alongside this, the redesign was built and documented against WCAG AA requirements, with accessibility checks included in development and QA rather than left until the end.
Feedback and product data gave the team a clearer view of where to investigate next
