From scan report to next step

In short: patients were getting diagnostic reports written for doctors, and many didn’t know what to do next. I led product and delivery for a platform that turns a static report into an interactive, guided one. It went from an idea to the first live report in six months, has since delivered more than 2 million reports and lifted daily active users by 30%. Along the way, approval moved from a manual clinician queue to near-instant, with zero compliance violations.

An idea, and a first problem to solve

When I took this on, the client had a vision rather than a product: help people manage their health as a whole. A vision that broad can’t be built in one go, so we needed a first problem narrow enough to ship and painful enough to matter. We picked reporting.

Someone gets a scan. A few days later a report arrives, written in medical language, for doctors. They read it and are left with three questions: What does this mean? What should I do next? Should I be worried? The answer usually waits for the next appointment. Until then they’re anxious, and some never take the next step at all.

Our bet: if the report explained itself, and answered questions the moment they came up, more people would understand their results and act on them.

The first bet: a report you scroll, not a PDF you read

Our UX designer led the research; I co-ran the interviews and the synthesis. Over several rounds we spoke to 15–25 users and tested different formats.

The one that clicked was a format people already know from their phones: a scrollable, multi-page report, like Instagram stories. Each page carries one idea: the finding, what the test is for, what the result means, what to do next. An AI assistant is always one tap away for anything the page doesn’t answer.

We had a working prototype in 90 days. The client ran a beta with it, the feedback was good, and the first report went live at month six. From then on we shipped a new report type roughly every two months, alongside new features for patients, admins and the platform itself.

Decision: trust before speed

From day one, a clinician reviewed every AI-generated report before a patient saw it. That was the client’s requirement, and I agreed with it. This was the first time patients would receive an AI-assisted explanation of their medical results, and one false positive or false negative would damage trust in the whole product.

The gate had a cost, though. Every report waited in a human queue, and clinician time is expensive.

Rather than argue for removing the gate, I measured it. Working alongside the clinicians, I tracked the approval rate: the share of AI-generated reports they approved as they were. It started at 85–90%. As we tuned the AI over the next couple of months, it climbed to about 99%. By then the gate was mostly confirming what the AI had already got right.

That was the evidence I needed. I proposed loosening the gate in stages: first bulk approval, where clinicians review and release reports in batches, then auto-approval, taking each step only once the data supported it. The client didn’t need persuading; the gains were obvious. Reports that had waited around 24 hours for a clinician now reached patients almost instantly, or within about six hours if queued.

Decision: buy the chat, then build it

Care navigators, the people who help patients with next steps, are central to the product, so patients need to be able to message them. But I didn’t want launch to wait on a chat system. We took it in three steps, moving on only when the current one stopped being good enough.

1. Use a vendor’s platform. We started with a third-party care-messaging platform, connected through single sign-on. It got us live on time. But patients had to leave our product to send a message, the UX didn’t match ours, and our data and user flows were split across two systems.
2. Bring it in-app with the vendor’s SDK. Using the vendor’s own chat SDK, we moved chat inside our product. Patients no longer had to leave, and new patients were set up in chat automatically when their report was approved. That fixed the experience, but we still depended on the vendor, and at the volume we were projecting, the pricing no longer made sense.
3. Build our own. Once scale justified it, we built chat natively into the platform. We now own the experience end to end, and at our volume it cut costs significantly.

What broke: we were flying blind

Here’s the honest part: we added proper analytics late, after most of the core product was built.

When the data arrived, it showed a clear pattern. Users over 45 were dropping off on specific screens, the ones where we expected them to take a next step. We found two causes:

1. The opening screen framed the report as something to read. Nothing told users they could act on it.
2. The next-step buttons sat below the fold. Many users didn’t realise they could scroll down to find them.

The fixes were small. We rewrote the opening screen to present the report as interactive, with actions to take, moved the key buttons up to where people could see them without scrolling, and relaunched. Daily active users rose 30% against the pre-redesign baseline, with the biggest gains among older users.

The lesson stayed with me: the users who most need a report explained are the least likely to go looking for a hidden button.

The deadline that didn’t move

Late in one cycle, the client’s requirements arrived weeks behind schedule, but the delivery date stayed where it was. We had to deliver several new reports at once. It was the most chaotic week of the project, and it changed how we build.

Until then, designers produced screens in Figma and engineers rebuilt them in code by hand. Under pressure, I pushed us to connect Figma directly to AI coding agents (through MCP), guided by clear instruction files (SKILL.md) that described our components and conventions. Turning a design into working code went from about four business days to one. Because the context was so clearly defined, the same approach sped up backend work too.

That got us through the deadline. Afterwards, I started a spike to design a complete AI-assisted workflow for building a new report, from design to backend. It became the standard process for every report after that.

Saying no, and offering something better

Some requests I pushed back on, usually ones that looked simple but put patient data at risk.

One example: the client wanted reports delivered through a link with no login, to keep things frictionless. But these are medical results, and access to an email inbox doesn’t prove you’re the patient. Inboxes get shared; emails get forwarded.

My tech lead and I explained the risk and proposed an alternative: verify the email, then ask for the patient’s date of birth before the report opens. It’s almost as frictionless, and the chance of the wrong person seeing someone’s results drops sharply.

My rule: protect the outcome the client is paying for, even when that means saying no to the feature they asked for.

Running 13 people across time zones

A distributed team works when the structure is deliberate. What worked for us:

• Three protected overlap hours each day, with every important meeting inside them.
• Written handoffs. Before logging off, each team wrote a note for the next one, and nobody started work without reading the last one.
• Detailed specs before build, so fewer questions had to wait a time zone.
• End-of-week demos, where everyone showed what they’d built, so nobody was working in the dark.

Where it landed

• 2 million+ reports delivered since launch
• +30% daily active users after the redesign
• Report infrastructure load-tested for 5× volume
• A 12-month roadmap delivered on schedule, with zero compliance violations
• A new report type roughly every two months after launch

What I’d do differently

Analytics from day zero. Our biggest engagement win came from data we could have had months earlier. Next time, instrumentation is part of the first sprint, not the last.

AI workflows sooner, and on purpose. We found them under deadline pressure and only standardised them afterwards. Now I’d set aside a small group whose job is to trial new tools as they appear, so a good idea doesn’t wait for a crisis to be discovered.