marco.
All work
StillMorrowgate Health8 min read

The handoff improved in the prototype. It never reached the ward.

A coordination concept for Morrowgate Health exposed an ownership problem that interface design alone could not resolve.

Cancelled before rolloutThe prototype worked in simulations. We never resolved who would own the operational record.
Client / employer
Morrowgate Health
Engagement
Design partner · Service innovation programme
My role
Lead product designer
Timeline
March–October 2022 · 16 active design weeks
Prototype direction · Stopped before production rollout.
Still mobile care coordination app showing patient handoffs and shift priorities

First, where this project ended.

Still began as a service innovation project to help ward teams pass operational tasks between shifts. I joined to map the handoff and build a prototype. Seven months later, the project closed without a production release. The interaction work was useful; the delivery assumptions were not ready.

What I owned

I led service mapping, prototyping, and interaction design. Alice ran the observation logistics and co-facilitated simulations. I wrote the final design handover and stop recommendation.

What I worked with

A service team trying to reduce coordination work across three wards, plus an existing clinical record we were never authorized to replace.

The people I worked with

Helen Park
Service sponsor · ward operations
Samir Patel
Technical architect · identity and integration
Jo Bennett
Shift coordinator · workflow review
Alice Morgan
Researcher · observation and simulations

No clinical advice, no patient data in the prototype, and no production integration. The project needed a named operational owner and an approved identity route before a ward pilot.

A task could be prepared and still belong to nobody.

Shift coordinators passed transport, equipment, and follow-up tasks through a mixture of paper lists and verbal updates. A task could be written down by an outgoing colleague without being accepted by the next shift. We initially called both states “handed over.”

Alice and I interviewed fourteen staff and observed eight shift changes across three wards. We kept operational coordination separate from clinical decision-making. The repeated breakdown was the gap between preparation and acceptance, especially when someone was interrupted.

The service sponsor wanted a lightweight layer outside the clinical record. The architecture review asked an unavoidable question: if the two systems disagreed, which one was authoritative? We did not have an approved answer.

Follow the handoff through an interruption.

We mapped one item through an entire shift boundary: transport to imaging, an outgoing note, an interruption, a resumption, and an incoming coordinator accepting responsibility. The diagram revealed two ownership changes that our first prototype had compressed into one button.

I separated Prepared from Acknowledged, with an explicit Interrupted state for a saved review. Preparing a handoff saved the work but left the outgoing owner visible. Acknowledgment recorded the accepting role and timestamp. An interrupted review could resume without silently acknowledging the remaining items.

Samir and I kept a parallel dependency log for identity, record ownership, device access, and support. I should have made that log the first page of the project readout. Instead, the prototype gave the impression that rollout was closer than it was.

Make acceptance a visible event.

01

Prepared is an explicit state

The outgoing team can finish its notes without claiming the incoming team has accepted them.

02

Interruptions preserve reviewed items

The saved draft shows its timestamp and progress. Resuming returns to the unreviewed item, rather than forcing a restart.

03

Acceptance has a record

A separate acknowledgment identifies the accepting coordinator. The prototype never treats opening a screen as acceptance.

Interaction contract · a prepared draft, a saved interruption, and an accepted handoff are three different states. All patient details in the prototype are synthetic.
Still mobile coordination screens for prepared, interrupted, and acknowledged handoffs
Interactive state studystill
still / handoff

Room 412

Pending item Transport to imaging

Owner Outgoing coordinator

Prepared by outgoing team · Not yet acknowledged

Coordination prototype using synthetic patient details. No clinical advice.

Twelve simulations are not a ward deployment.

Twelve staff took part in facilitated simulations using synthetic records. Six scenarios included an interruption. These sessions tested the interaction model; they did not measure clinical outcomes, real shift duration, or operational safety in production.

01

Four participants initially read “Prepared” as a completed transfer.

Revision. Kept the current owner beside the status and added “Not yet acknowledged.”

Readout. 11 of 12 explained the distinction in the revised simulation.

02

An interrupted review restarted at the first item.

Revision. Saved progress and returned to the next unreviewed coordination item.

Readout. 5 of 6 resumed without repeating completed steps.

03

Staff asked whether a changed clinical record would update this screen.

Revision. Documented the unresolved source-of-truth dependency; did not simulate an integration we lacked.

Readout. The ward pilot remained blocked and was ultimately cancelled.

A useful prototype and a project that stopped.

In October, Helen and the architecture group closed the project. The programme could not fund the integration work or name a team to own the operational record. A standalone release would have created a second place to keep patient-adjacent coordination up to date.

I recommended stopping the standalone build and handed over the state model, annotated prototype, simulation observations, and unresolved-dependency log. The service team used the preparation-versus-acceptance distinction in a paper handoff checklist. We did not formally evaluate that change.

There is no time-saved figure for this project. We never ran the ward pilot needed to establish one. The outcome was a clearer interaction model and a decision not to ship a disconnected service.

What I would change

I should have treated record ownership as a discovery question, not an implementation dependency. A convincing prototype can conceal an unresolved service model. In this case I helped make something look ready before the organization could support it.