ADGScribe.ai
A clinical documentation tool designed to keep physicians present in the room. I shaped the UX for a system that transcribes patient encounters, structures notes into the clinician's format of choice, and surfaces the right context at the right moment in the clinical workflow.
The average physician spends two hours documenting for every hour with a patient
That imbalance doesn't just create burnout. It erodes the quality of care itself. Manual note-taking during consultations reduces eye contact and patient trust, while post-visit documentation stretches into personal time.
Existing tools either required full manual transcription or generated notes so rough they needed heavy editing before meeting clinical standards. Neither respected how physicians actually work.
Why AI documentation is genuinely hard to design
Designing an AI scribe is not a standard productivity problem. Clinical notes are legally and financially consequential. A missed medication, a misattributed symptom, or an incorrectly structured code can affect diagnosis, billing, and liability. The AI output has to be trustworthy enough to use quickly and editable enough to correct without friction. And the person using it has almost no tolerance for extra steps.
An AI scribe built for the flow of clinical work
ADGScribe.ai automatically transcribes patient encounters, generates structured notes in the clinician's preferred format, from SOAP to specialty-specific and fully custom templates, and surfaces the right patient context at the right time. I worked across UX strategy, information architecture, and content design to make sure the system supported physicians without asking them to adapt to it.
Structuring the information architecture
One of my primary contributions was defining the navigational structure and content hierarchy. The challenge: surface enough context to be useful at a glance, without overwhelming a physician mid-workflow. Below is each surface, the job it had to do, and the tradeoff that shaped it, not just the finished screens.
By aligning each section to a real task in the clinical day, the system reduces context-switching and keeps attention on the patient, where it matters most.
Content designed around how physicians actually work
Clinical software is often written for the teams who manage it, not the people who use it daily. The content approach here was the inverse: plain language, action-oriented, with system state surfaced proactively so physicians are never caught off guard mid-session.
A full design system handed to engineering
We completed and handed off a full design iteration to engineering across all six core surfaces: home, recording flow, sessions, patients, appointments, and referrals. The work was grounded in real feedback from physicians, doctors, and medical billers throughout the process, validating that the system mapped to actual clinical workflows rather than an idealized version of them.
Physician feedback confirmed that structured note templates reduced post-visit review time and that the recording-first homepage matched how they actually entered the tool. Templates were validated as useful by billers, who flagged that encounter-specific structure reduced coding errors on their end.
A few things this project left me with.
Working on this project shifted how I think about an entirely different profession. Not just what physicians do, but how their workflows are structured, how medical coding actually functions behind the scenes, and how much clarity matters in fast-paced clinical environments. It made me think more intentionally about IA, especially in how CTAs are organized to make something complex feel immediately graspable.
Something as small as a mislabeled section or a buried action isn't just a usability issue in this context. It can mean a delayed note, a missed detail, or a physician staying late to finish documentation that should have happened in the room. That weight changed how I approached every labeling and hierarchy decision on this project.
