A leading European online pharmacy needed its Online Doctor Service to be easier to find, understand, and trust — right as Germany's e-prescription rollout was gaining momentum. I joined as an external UX Designer, embedded within a growing in-house team, to help move faster and contribute to research and design that would close the gap between a service that existed and users who simply didn't know it did.

CLIENT

Online pharmacy (under NDA)

DURATION

3 months (2022)

ROLE

External UX Designer 

TEAM

4-person UX research team

To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of the client.

A note on my role

This case study is different from my others. I wasn't the lead designer. I was brought in through an agency as additional capacity — a fourth designer on a team that needed to move faster without losing rigour. My involvement in decisions that required deep internal knowledge was deliberately limited, and that was appropriate given the context.

I'm including this project because of what it taught me: how research-led design works inside a large, regulated organisation, how stakeholder alignment gets built before a single screen is drawn, and what it means to contribute effectively when you don't own the outcome.

Setting the stage

In 2022, Germany's e-prescription rollout was underway, but awareness and usage of Online Doctor Services remained low. For one of Europe's leading online pharmacies, the ODS represented a direct path for customers to obtain e-prescriptions digitally — but it wasn't being discovered or used.

The team's mandate was clear: understand why, and fix it. My job was to support that process — contributing to research, synthesis, and design — and to help the team move at a pace four designers could sustain where three couldn't.

Learning before building

Before wireframing anything, the team needed to understand why customers weren't engaging with the ODS at all.

To start, we needed internal alignment. We conducted empathy mapping workshop involving 20+ stakeholders across departments, each holding different assumptions about the ODS's role. I facilitated a group of six, and the session surfaced misalignments that would have pulled the design in conflicting directions if left unaddressed. Getting those into the open before design began was the point.

With a shared foundation in place, we conducted moderated remote user testing with eight participants across Germany. Each was given two tasks:

  1. Find a way to get a prescription for their symptoms and,

  2. Find a doctor in their area.

Four barriers emerged consistently across all eight sessions — invisibility, insurance confusion, an unclear entry point, and a trust deficit around third-party redirects. But one observation stood out above the rest.

Every single participant stalled at the same moment — a question asking whether their symptoms were "acute or chronic."

It revealed something more fundamental than a language problem: the entire flow had been built around clinical logic, not how users actually think about their own health situation. That single observation, surfaced collectively across eight sessions, reframed how the team approached the redesign. Not as a language fix but a structural one.

This is the kind of insight that only emerges when research is done rigorously and without assumptions — and it's what made the subsequent design decisions defensible rather than intuitive.

Turning insights into design

The existing landing page tried to do too much and explained too little. Drop-off was happening before users even started the flow — a signal that the problem wasn't the journey, it was the starting point.

The team introduced a dedicated landing page built around two clear entry paths:

  1. "I need a doctor"

  2. "I need a prescription"

This directly addressed what testing had shown: users didn't know which category they fell into, and the existing page didn't help them figure it out. Each path then guided users through a simplified flow — insurance type → symptoms → next steps — using plain language that mapped to how users actually thought about their situation.

Supporting content addressed the trust and transparency barriers directly: how the ODS works, what insurance is accepted, and why users are redirected to a third-party platform and what happens to their data.

Throughout this phase I contributed to prototyping, supported synthesis of research findings, and helped translate insights into design rationale during team reviews. The decisions were collective — and that's an accurate reflection of how good research-led design works inside large organisations.

What I took from this project

Working as an embedded external designer in a regulated, research-driven environment taught me things that leading a project can't.

I learned what it looks like when stakeholder alignment is treated as a design input rather than an afterthought — the empathy mapping workshop wasn't a warm-up exercise, it was how the team ensured the design solved the right problem. I learned how to contribute meaningfully without ownership — knowing when to push an observation forward and when to let the team's collective judgment lead. And I learned how research rigour changes the quality of design decisions: the "acute or chronic" reframe wasn't a creative insight, it was the direct output of structured, careful observation.

These aren't skills that show up obviously in a portfolio. But they shape how I work on every project since.

Outcomes & impact

For users: A clearer, more trustworthy starting point for beginning an online doctor visit. Users could finally distinguish between finding a doctor and requesting a prescription — and understand what would happen at each step.

For the business: Stakeholder alignment was established early and held through to launch. The design was approved, deployed, and — notably — remains live in 2026, suggesting it was validated and retained well beyond the initial rollout.

For the product: The work was part of a broader initiative to reduce friction across the e-prescription journey. In the year following the project, the company reported strong year-on-year growth in prescription sales — a result of multiple converging efforts, of which this was one part.

A note on the numbers: Due to NDA obligations, I'm unable to share client-specific data. Rx sales figures referenced are drawn from publicly available company reporting.

Let’s work together

Working on something complex? I'm currently open to product design roles in Berlin and remotely.

LinkedIn