UX Case Study · Healthcare SaaS · Ultramed

Clinical Notes

The redesigned Clinical Notes module: role-based note templates for a patient record, each note type showing status, contributors, and last update.

A clinical team shared one 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 fix.

All screens in this case study are representative. The product itself is under NDA.

Role
Sole designer: research, UX, UI, prototyping
Domain
Health-tech
Timeline
~6 months · now an MVP in active build
Team
Me on design · manager input · dev for feasibility
Tools
Figma · Claude Code (AI-native workflow)
Constraint
No design system · legacy form backend
ProblemAnyone could edit or delete another clinician's note with no history and no audit trail. The risk to patients pushed clinicians to keep shadow copies in text files.
What I didRebuilt it as a role-based, auditable workspace: every answer attributed, non-destructive strikethrough amendments with a forced reason, and awareness-based concurrency instead of a hard lock.
Where it standsValidated with four trusts and one slice shipped before the commercial driver paused. Revived as the MVP now in active development.
5
end-to-end flows designed
4
trusts validated the direction
1
designer, A to Z
~6mo
concept to development handoff
01 · Context

A shared record for a whole clinical team

Ultramed builds the software UK hospitals use for pre-operative assessments: the checks before surgery. Patient answers land in a clinical portal where a multi-disciplinary team (nurses, pharmacists, clinicians, anaesthetists) works each assessment, and Clinical Notes is where they document observations against a patient: shared, collaborative, several roles touching the same record 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.

Fig 01 · What the team kept running into
Pain points mapped around the old Clinical Notes form, attributed to three roles — nurses, anaesthetists, and clinicians: searching for abnormal values is like finding a needle in a haystack; scanability is a nightmare; the lack of context for entries is frustrating; typing notes is slow and cumbersome; I can't easily see who made which notes or why a check-box was chosen; I can't even view previous notes while I'm typing the current ones.
The pain points: what nurses, anaesthetists, and clinicians said about the old module, mapped around the form they were describing.
02 · 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, with no history and no audit trail. Several clinical roles rely on that record, so the gap put patients at risk.

Fig 02 · Clinical Notes, in use
The shared record: an interactive walkthrough of the Clinical Notes module a whole clinical team works against.
The workaround that gave it away

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. When clinicians keep a shadow copy of clinical documentation in a text file, the tool has failed them.

How might we let a clinical team contribute to the same assessment, without overwriting each other or losing the record of who changed what, on a legacy backend that can't support true real-time editing?
03 · Process

Why the obvious answer was off the table

The obvious fix is live co-editing. The backend ruled it out, so every decision below had to invent an alternative that still made collaboration feel safe.

The reality I designed inside
  • A legacy form builder at the core. It put hard limits on what could change.
  • No design system. Dev-first Tailwind, three different "primary" blues in the product.
  • No UI designer. I owned visual consistency from scratch.
  • Reuse, don't rebuild components, to protect a hard deadline.
  • No product analytics. No instrumentation of user behaviour.
So the design had to
  • Make collaboration safe and visible with no real-time backend.
  • Build the audit trail at the interaction layer instead of the database.
  • Fit the existing component set and ship on time.
  • Resolve visual inconsistency as part of the work instead of as a separate project.

The pain points

Before designing, I needed to know where the current module failed users. The research phase combined three sources:

  1. Live workshops with clinical teams
    Ran sessions with nurses, anaesthetists, and clinicians to observe workflows and capture frustrations first-hand.
  2. Outstanding tickets from Linear
    Collected all pending bug reports and feature requests related to Clinical Notes. The same complaints kept repeating.
  3. Competitive analysis
    Reviewed comparable clinical documentation tools to see how they handled the same problems.

Collating the three sources into one prioritised list of must-haves gave me the direction for the design.

Fig 03 · Three sources, one set of pain points
Discovery sketch: three research sources — workshops, Linear tickets, and competitive analysis — feed arrows into a single set of pain points, captured as five notes: no ability to view history of answers; unable to amend answers; risk of compliance; I am not sure if my observation can be overwritten; the current location is too small to work with.
Synthesis: workshops, Linear tickets, and competitive analysis converging on the five pain points that set the design direction.

Ideation

Exploration highlights

Extensive sketching and feedback sessions narrowed the note editor down to three high-fidelity directions.

Note Entry-Point

Individual Notes

✕ Decided not to move forward with this because...
  • The first direction was to have 3 tabs, Updates, History and New Notes
  • Individual Notes did not help with continuous documentation and chain of thought
Sketch: three-tab note entry point with Updates, History, and New Note

Floating Notes Panel

✕ Decided not to move forward with this because...
  • Needed a new component and extra development time
  • New user interaction might have needed extra effort.
Sketch: a floating, detachable notes panel over the assessment

Dedicated Tab

✓ Selected for implementation...
  • Visible in the main navigation at all times
  • Familiar pattern for users
Sketch: a dedicated Clinical Notes tab, always visible in the main navigation
04 · Solution

From a side-rail form to an auditable workspace

A text form with a single Edit button became an auditable, role-based workspace. The constraints never changed: no real-time backend, no design system, and a hard deadline.

Fig 04 · After: role-based templates
After: full-width, role-based note templates, with a clinician moving between note types.
01

From a single crowded form to role-based templates

Each role works its own template: Clinical Examination, Nurse Review, Anaesthetic Note, Pharmacist Note. That cuts how often two people land on the same field. A side-by-side View Report panel keeps source data and note-taking on one screen.

Fig 05 · Every answer, attributed
Answers in place: each entry carries its author and time. A new observation lands with full attribution.
02

Every answer stays in place, with a name and a time

Answers render beneath the question, each carrying who wrote it and when. The next contributor reads with full context instead of facing a blank field.

Fig 06 · Strikethrough forces a reason
Amending in place: the clinician types the replacement and gives a reason before anything commits. The original stays struck through, still carrying its author.
03

An amendment that can't happen without a reason

To change an answer, a clinician strikes it through. The original stays visible, and nothing commits until the clinician enters a reason. That builds the audit trail at the interaction layer, since the backend has none.

Fig 07 · One amendment, one container
One amendment, one container: correcting the parent answer strikes every answer that depended on it, in turn. Each one stays, struck through and still attributed.
04

The hardest case: when one answer invalidates four others

Some questions only exist because of a parent answer. Amend the parent and its children are orphaned, and deleting them without a trace would break the audit trail. One amendment, one container: the parent and every invalidated child, still attributed and timestamped.

Fig 08 · Warned, not blocked
Warned, not blocked: a colleague starts writing in the same question and publishes while you type. The banner tells you, and tells you again as the count climbs, without ever stopping you.
05

Warned, not blocked: awareness instead of a hard lock

The backend can't support real-time locking, and clinical workflow shouldn't tolerate one anyway. A banner warns you when someone's editing; publish while a colleague writes, and the app prompts them to refresh before they finalise.

05 · Takeaways

Honest, and still strong

The commercial driver fell away for reasons outside design, and the project paused. I can still speak to whether the design solved the problem. It did, on every axis that was mine to own.

  • Validated & accepted. Four trusts confirmed the direction; it cleared feasibility, and one slice reached development.
  • Outlived its driver. The designs are now live in sales demos to new prospects, and the project is back in development as the MVP, generalised from one trust's needs to serve all of them.

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," my manager told me. I now categorise every feature as core-functional, cosmetic, or add-on, and defend the line.

Designing without a design system is its own project

I had to find, understand, and adapt every reused component for consistency. As the only person doing UI, I came out of it operating as UX, UI, and tooling at once.

What's next

With the MVP back in development, I'm planning usability testing, using Claude Code to build functioning prototypes. That moves me from directional buy-in to testing whether people understand the model.