Overview
A note on what I can share: this work is commercially sensitive, so the case below focuses on how the problem was framed and the approach taken — not the specific UI or features that resulted.
The problem
Accurx's Inbox is the daily clinical workflow tool used by the majority of UK GP practices. Our existing AI scribe helped clinicians start a recording and that was largely where its value ended.
Research with users surfaced the gap clearly: the scribe was excellent at one moment in the consultation and absent for everything around it. Clinicians were left to handle review, edit, integration into the patient record, and follow-up actions on their own. The tool felt like a feature, not a workflow.
The 2-week hackathon brief: design a vision for what the scribe could become if we treated it as part of a connected clinical experience, not an isolated tool.
I led the design.
How does an AI scribe stop being a single-purpose feature and start being a thread that runs through the whole consultation workflow?
TL;DR
Set the future vision for the next generation of Accurx's AI scribe in 2 weeks
Partnered with Claude to build a working code prototype — not Figma frames
"Connected experience" became the shared frame the team now uses to scope this product line
Opened a build-vs-buy conversation in the org about owning the underlying scribe APIs
My contribution
Product design
Prototyping in code
AI-assisted development
Vision-setting
The team
1 PM
1 Designer (me)
3 Engineers (2 frontend, 1 backend)
Hackathon format
Year
2026
Process
The research insight that reframed the brief
The most useful finding from user research was almost embarrassing in its simplicity: the scribe was great at starting, and not much else. Clinicians were dropping into the rest of their workflow with no help from the tool that had just listened to their entire consultation.
That reframed the brief. The design problem stopped being "build more AI capability" and became "design the connections between the moments AI is already useful and the moments it isn't yet."
Where we focused
In two weeks, you can't redesign everything. I narrowed down the moments that surrounded the existing scribe experience:
Before — the setup, the consent, what the clinician sees in the seconds before a consultation starts
During — what the AI offers in real time without pulling attention away from the patient
After — review, edit, integration into the record, surfacing of follow-up actions. Designing the "after" also meant designing the failure modes: clinical AI being wrong isn't a UX problem, it's a safety event.
Most of the design opportunity lived in "after." That's where the disconnect was sharpest, and where clinicians felt the existing tool abandoned them.
Prototyping in code with Claude
Instead of static Figma frames, I built a working web prototype using Claude as a pair-programmer for parts of the experience alongside the engineers. I described the interaction; Claude wrote the code; I refined it in the live prototype. My CS background meant I could read the code, and stay close to engineering reality; every interaction had a feasibility check baked in.
This changed what the hackathon could produce:
Interactions that don't survive a Figma click-through — streaming output, edit-in-place, real-time AI behaviour
A demo clinicians could actually use, not a story they had to imagine
A handoff engineering could read, not a deck they had to translate
A blurred image of one of my designs
Outcome
What it produced
A working code prototype and a clear point of view about how to evolve the scribe from a single-purpose feature into something that runs through the whole consultation. "Connected experience" became the shared frame the team now uses to scope this product line.
The build hasn't been picked up yet. Ongoing contract discussions with the third party providing our current scribe infrastructure mean the timing isn't right and the vision itself presses against what's possible through someone else's APIs. The work has, however, opened a different conversation in the org: what could this experience be if we owned the underlying capability ourselves? That's a different kind of question than the hackathon brief asked, and probably the more consequential one for where the product line goes next.
What I took forward
The best research insight is usually the most obvious one stated plainly. "Great at starting, not much else" did more to shape the design than any feature ideation we did.
Vision work earns its keep when it produces shared language. A team that can name the problem in three words designs faster than one that can't.
Designers who build are designers who get listened to. A working prototype settles arguments a Figma deck only starts and AI-assisted development changes what one designer can ship in two weeks.