Clinical Notes
A clinical team documented the same patient record, but couldn't see who else was in it. Notes got overwritten and lost, with no audit trail and a real patient-safety risk. I rebuilt it alone over six months on a legacy backend that ruled out the obvious answer.
A shared record for a whole clinical team
Ultramed builds the software UK hospitals use for pre-operative assessments: the checks a patient goes through before surgery. Patient answers land in a clinical portal where a multi-disciplinary team (nurses, pharmacists, clinicians, anaesthetists) works each assessment.
Clinical Notes is where that team documents its observations against a patient. It's shared and collaborative: several roles contribute to the same record, sometimes minutes apart.
Multiple trusts had flagged the module's limited functionality and the patient risk it created. The wider customer base felt the same problem.
An unauditable form that lost people’s work
The old Clinical Notes was a simple form (text fields, radios, multi-selects) wedged into the bottom of a narrow side rail. Anyone could add, edit, or delete an answer, and there was no history and no audit trail. For a record multiple clinical roles rely on, that gap is a clinical-safety problem.
Clinicians had started keeping their notes in a separate file and pasting them in. Hitting save locked the other person out and discarded their work. A shadow copy of clinical documentation, kept in a text file, is the clearest signal a tool is failing its users.
How I knew — discovery without analytics
- Consolidated the complaints. Grouped Clinical Notes tickets in Linear and the steady stream of account-manager complaints into core problems.
- Validated with four trusts. Ran workshops mapping pain points, then used MoSCoW to sort requirements into must / should / could.
- Triangulated internally. Two sessions with in-house consulting clinicians, two with account managers, to cross-check what trusts reported.
The second half is the real difficulty. The obvious answer to collaborative documentation is live co-editing. The backend made that impossible, so this became an interaction-design problem.
Why the obvious answer was off the table
These shaped every decision, and they're why the solution had to be inventive.
- A legacy form builder at the core. Everything, including Clinical Notes, is built as a form on top of it, which set hard limits on what could change.
- No design system. Dev-first Tailwind, with three different "primary" blues across the product.
- No UI designer. I owned all visual consistency from scratch.
- Reuse, don't rebuild components, to protect a hard deadline.
- No product analytics. No instrumentation of how users behaved.
- Make collaboration feel safe and visible with no real-time backend.
- Build an audit trail at the interaction layer, not in the database.
- Fit the existing component set and ship on time.
- Resolve visual inconsistency as part of the work, not as a separate project.
Six calls that carried the design
Read the headlines for the whole story; read on for the why.
Split one long form into smaller, role-based templates
Show every committed answer in place, with per-answer authorship
Strikethrough-as-audit, with a forced reason — the headline
Awareness-based concurrency — soft by design, not just by constraint
The hardest case: cascading conditional invalidation
A side-by-side View Report panel
One pattern, every time
Across the project the same move recurs: every time I reached for richer, real-time interaction, feasibility said no — and I shipped the awareness-based fallback that preserved the core value. That consistency is the method: designing right at the edge of what's buildable.
Exploring in code, before Figma
In the project's current phase I use Claude Code to generate component variations and stress-test them against messy real conditions (long answers, stacked strikethroughs, cascading invalidations) before committing anything to Figma. I find what survives the edge cases, then build the winner out. This moves validation earlier and cheaper. I catch layout and legibility failures in code before investing in polished frames.
The cascading-invalidation block above came out of exactly this loop. I also built my own tooling to cover the missing design system: an HTML plugin that pulls live components from the test portal into Figma, so I rebuilt buttons and styling against what actually shipped. When the environment didn't give me a system, I engineered the bridge.
From a side-rail form to an auditable workspace
- A dedicated, full-width Clinical Notes tab with role-based templates as the primary structure.
- Every answer rendered in place, attributed and timestamped.
- Non-destructive, reason-logged amendment via strikethrough — extended to cascading conditional changes.
- Awareness-based concurrency from both sides — incoming editor warned and kept aware; active editor told when the record changes and prompted to refresh before finalising.
- A side-by-side View Report panel so source documents and note-taking share one screen.
The flows in detail
Honest, and still strong
The commercial driver fell away for reasons outside design, and the project paused. Worth stating, because it's outside what a designer controls: commercial priorities shift on procurement, timing, and politics. What I can speak to is whether the design solved the problem and held up. It did, on every axis that was mine to own.
- Validated & accepted. Four trusts confirmed the direction; it cleared feasibility enough that development started and one slice shipped.
- The work outlived its original driver. The finalised designs are now a live feature in sales demos to new prospects, and the project has been revived as the MVP in active development, generalised from one trust's needs to serve all trusts.
Design work that gets repurposed and revived after its original driver disappeared is, by definition, valuable. For a paused-then-revived project, that's the credible proof.
What it taught me
My first project with real constraints
Earlier work assumed developers could build anything in any timeframe. This taught me to design for the system and the deadline that exist.
MVP discipline was the biggest lesson
"These are great — now learn to cut down to what makes a deliverable MVP." I now categorise every feature as core-functional, cosmetic, or add-on, and defend the line.
Designing without a design system is far more work than it looks
Every reused component had to be found, understood, and adapted for consistency. As the only person doing UI, I held that together from scratch — and came out operating as UX, UI, and tooling at once.
What's still open
Template customisation: as trusts get multiple board templates to build their own notes, I want to learn how long those forms get in practice and whether everything still fits one coherent flow.
What's next
With the MVP back in development, I'm planning usability testing — using Claude Code to build functioning prototypes to test whether users genuinely understand the model before it ships. Validation is moving from directional buy-in to real testing.