Design Intervention 01 · Enterprise UX

Go Live Companion

An operational companion that carries a project manager's context through a hospital software go live, from onsite orientation to a verified correction.

Open the working build See the FigJam
Role
Product Designer
Type
Design intervention
Domain
Healthcare operations
Scope
Workflow mapping, IA, interaction design, working build
Tools
FigJam, Figma, Claude
Data
Synthetic. No client data.
01
Where this came from

I kept leaving the task in front of me to find the context somewhere else.

I spent a stretch of my career as an implementation project manager supporting hospital software go lives for a healthcare software vendor. A go live is a few days of very high context work: you are onsite in a building you may not know, supporting clinical staff on software that was configured months earlier by people you may never have met.

To do the job well I needed to know where I was assigned, which floor and unit to walk to, who my coworkers were and where they had set up, who the hospital contacts were, what had actually been built, which devices were in the room, who owned an open issue, and whether a fix had been verified.

None of that information was missing. It was just scattered across email, travel systems, staffing lists, project systems, hospital floor plans, client device records, secure messaging, ticketing, and other people's memory.

  • Email threads
  • Travel system
  • Staffing list
  • Project system
  • Hospital floor plans
  • Client device records
  • Secure messaging
  • Ticketing
  • Hospital IT
  • Technical support
  • Coworkers

Eleven places I might have to visit to finish one task that was already in front of me.

02
Process evidence

The pain points looked unrelated until I grouped them.

FigJam · raw notes
Walking through user pain points chronologically
FigJam board of red and yellow sticky notes recording go live frustrations in chronological order, from travel logistics through onsite support
I wrote these from memory before analysing anything, in the order they happen on a trip.

I started by writing down every frustration I could remember, in the order it happens on a trip rather than sorted by severity. Rechecking flights at the last minute. Scrolling email to be sure I had not missed go live information. Looking up which coworkers were assigned with me. Arriving at a hospital with no sense of the unit, the floor plan, or the head nurse. Digging through my camera roll for reimbursement photos. Checking build status by hand. Waiting on IT. Messaging around to find out where someone was and who owned an issue.

Kept in that raw form, the list reads like a complaint. Grouped, it turned into a diagnosis.

FigJam · affinity map
Affinity mapping theme discovery
Affinity map grouping the pain points into four themes: logistics and admin, orientation and wayfinding, people and communication, operational context and knowledge, plus a moment to design column
Four themes, plus a fifth column I used to mark the moment worth designing for.
01

Logistics & admin

  • Travel and flights
  • Trip submissions
  • Reimbursement
02

Orientation & wayfinding

  • Arriving onsite
  • Finding the right unit
  • Reading the building
03

People & communication

  • Coworkers and roles
  • Who is where
  • Secure messaging
  • Hospital IT
04

Operational context

  • Go live information
  • Build status
  • Device records
  • Permissions
  • Similar prior issues

These were analytical categories, not the product's navigation. I want to be clear about that, because the obvious move would have been to ship four tabs named after them.

03
The root problem

Four different themes. One repeated behaviour underneath them.

The context needed to finish the current task does not travel with the work.

Context fragmentation
  • Step 01Leave the current task
  • Step 02Find another system or another person
  • Step 03Reconstruct the missing context
  • Step 04Return and resume

It would be easy to call this "too many apps," but consolidating tools would not fix it. The problem is not the number of systems. It is that the context sits in the systems rather than travelling with the piece of work, so the PM becomes the integration layer.

That gave me the thesis: build one operational companion that carries the relevant context through the go live workflow, and surface it at the moment it becomes useful. Not a dashboard that shows everything at once.

04
Scope and journey

I narrowed to the part of a go live where context costs the most.

Primary user: an implementation project manager supporting a hospital software go live onsite.

Scope: final preparation before arrival through active onsite support. I deliberately did not redesign the whole implementation lifecycle. This window is where fragmented information turns into immediate operational friction, because the PM is standing in a room with a clinician waiting.

Then I stopped asking what pages the app needed and started asking what context has to follow the PM through each stage.

  • Before arrivalAssignment and logistics
  • Once onsiteOrientation and people
  • During supportTechnical context, issue coordination, ownership
The golden journey
  • 01Prepare
  • 02Arrive
  • 03Orient
  • 04Support
  • 05Encounter issue
  • 06Investigate
  • 07Coordinate
  • 08Resolve

The three highlighted stages are where the product earns its place, so they became the hero interaction.

What I cut

Kept

  • Today / assignment brief
  • Onsite floor and unit map
  • Staff and role context
  • Create an issue from location and device context
  • Permitted project and device information
  • Similar issue retrieval
  • Routing, ownership, status
  • Amendments

Cut on purpose

  • Full reimbursement handling
  • Full travel management
  • Generic dashboard metrics
  • Rebuilding secure messaging from scratch

Ideation included all of it: travel, client briefing, AI questions about assignment, floor plans, staff positions, naming conventions, build status, tickets, amendments, unit chats, overall progress, similar issue retrieval, protected record validation. Reimbursement and travel are real frustrations, but they are administrative problems that already have owners elsewhere. Cutting them was a product decision, not an oversight.

05
Information architecture

I designed the information to travel with the PM.

GO LIVE PROJECT
│
├── TODAY / BRIEF      assignment · shift · current unit · team · priorities · active issues
│
├── MAP                hospital · floor · unit · room · permitted device objects
│
├── PEOPLE             implementation staff · hospital staff · roles · assignments · availability
│
├── ISSUES             originating location · related device · workflow · owner
│                      status · next action · related communication
│
├── AMENDMENTS         object changed · previous value · observed value
│                      author · reviewer · status · audit history
│
├── CHATS              linked to issue / device / unit / amendment
│
├── PROJECT CONTEXT    build status · client brief · contacts · known issues
│
└── AI CONTEXT LAYER   retrieve permitted information · identify similar issues
                       prefill known context · recommend likely ownership

   cross cutting   PERMISSIONS   PROVENANCE   OWNERSHIP   AUDIT HISTORY   CONTEXT INHERITANCE

The important part of this architecture is not the list of sections. It is that map, issue, amendment, person, and chat are not separate silos. They reference the same underlying objects.

So one workstation can exist on the map, become the subject of a discrepancy, be referenced by an amendment, be assigned to Hospital IT, and appear inside the contextual chat, without the PM retyping any of it.

One object
WS-ER-14
Workstation, Triage / Fast Track
  • On the mapA device in a room
  • In an issueThe subject of a discrepancy
  • In an amendmentThe object being changed
  • In a chatContext already attached
06
Low fi sprint

Before I coded anything, I worked out what happened after every click.

The point of the low fi pass was to prove behaviour before visual polish: what content carries forward, what changes state, and where a human has to intervene. It covered the product shell, whole building wayfinding, the hero discrepancy flow in twelve steps, and a secondary AI naming check.

FigJam · storyboard
Step 7 · Low fi interaction storyboard
Low fidelity interaction storyboard covering the product shell, whole building wayfinding, the twelve step onsite discrepancy and amendment flow, and a secondary AI naming check with secure handoff
Every panel names the content that carries forward and the state that changes.
Cleaned draft
Wayfinding + hero flow, tightened
Cleaned low fidelity wireframes showing the whole building wayfinding map for Miami General Hospital and the location discrepancy and amendment flow
The cleaned pass, once the behaviour held up.
What the wireframes had to prove
  1. Context carries forward. The PM never retypes hospital, unit, room, device, issue, or owner when moving between map, report, amendment, and chat.
  2. The human flags physical reality. The system cannot know a workstation was physically moved. The PM sees the mismatch onsite.
  3. AI validates with limited access. A narrow question can be checked against protected records without handing the PM the client's backend.
  4. Humans confirm consequential changes. AI does not silently alter a hospital record.
  5. Amendments are auditable. Original and proposed states both stay visible.
  6. Ownership is explicit. The interface always answers who owns the next action.
  7. Related objects behave like one system. Map, device, issue, amendment, person, and chat share context.
07
Hero interaction

The floor plan became the starting point for resolving the issue.

Here is the scenario the product is built around, using synthetic data. At Miami General Hospital, outpatient emergency clinic, the PM is assigned to Triage / Fast Track on the ground floor.

The system says workstation WS-ER-14 lives in ER-108, Exam Room 3. Standing in the unit, the PM can see it installed in ER-110, Triage Bay 2. Somebody moved it and nobody updated the record.

The PM taps the device on the unit map and reports a location discrepancy. Because the report starts from the map, the hospital, unit, room, and device are already attached.

System record
ER-108
Exam Room 3
Observed onsite
ER-110
Triage Bay 2
AI validation response

These locations differ. I can create an amendment for Hospital IT to verify.

It does not say the database is wrong, and it does not move the device. The PM chooses to create the amendment.

The amendment record
Object
WS-ER-14
Device location
Original
ER-108
Exam Room 3
Proposed
ER-110
Triage Bay 2
Assigned to
Hospital IT
Submitted by Sabrina May

After the PM confirms, the operational map can show WS-ER-14 in ER-110, but it is clearly marked amended, awaiting verification. The original value stays in the history. The PM has not overwritten the hospital's canonical record, and nobody downstream has to guess whether the change was authoritative.

State model
  • System record
  • Observation differs
  • Discrepancy reported
  • AI validation
  • Human confirmation
  • Amendment submitted
  • Awaiting Hospital IT
  • Verified
  • Applied
  • Terminal alternative · Rejected

The product models the uncertainty instead of hiding it. Amber means somebody still has to look.

Ownership never goes unnamed
  • You are investigating
  • Report sent
  • Waiting on Hospital IT
  • Hospital IT verifying
  • Resolved
Secondary flow · asking a narrow question of protected data

The PM asks: is LABPRNTR402 the correct printer name for ER-110? Naming conventions matter during a go live because a mislabelled device routes print jobs to the wrong floor.

AI checks the protected end user device context, finds the expected convention and the registered name, and offers to create a prefilled discrepancy report. The PM reviews it and sends it to Hospital IT. Status becomes waiting on Hospital IT, and a secure chat opens with the context already attached.

Convention
P-ER-##
Registered
P-ER-04
Observed
LABPRNTR402
08
Three design decisions

These three calls matter more than showing every screen.

01

Physical reality needs a human input.

Why it exists

No amount of retrieval tells the system that somebody wheeled a workstation from Exam Room 3 into Triage Bay 2. There is no sensor and no event. The only source of truth is a person standing in the room.

So the map is not a read-only diagram. Every device on it is a reporting surface, and reporting starts from the object rather than from a blank form.

02

Permission limits should change the answer, not break the workflow.

Why it exists

During real go lives I often needed device context I had no clearance to browse. The usual outcome is a dead end and a message to somebody with access.

The AI context layer answers a narrow question against permitted records without granting general access. The PM learns that the registered name is P-ER-04 without being handed the client's device inventory. A permission boundary shapes the response instead of stopping the work.

03

A correction needs an owner, a history, and a verification state.

Why it exists

The tempting version writes ER-110 straight into the record. That is faster and it destroys the audit trail, and in a hospital the audit trail is the point.

So the amendment becomes pending. Original and proposed values both persist, the reviewer is named, and the map carries an awaiting verification marker until Hospital IT confirms. The correction is useful immediately and authoritative only after review.

Where the line sits

AI does

  • Retrieve relevant context
  • Connect permitted sources
  • Recognise similar prior issues
  • Prefill issue details
  • Suggest a likely owner
  • Explain the known record state

The human does

  • Observe physical reality
  • Verify the context
  • Edit or reject suggestions
  • Choose to escalate
  • Approve the amendment
  • Resolve and close

AI reduces search and re-entry. Judgment on anything consequential stays with the person who is accountable for it.

09
From board to build

Then I turned the interaction into working software.

The sequence mattered. The FigJam produced the problem, the affinity map produced the diagnosis, and the storyboard settled the behaviour. Only then did I use Claude to build it, which meant I was implementing decisions rather than discovering them in code.

The result is a clickable build of Miami General Hospital: assignment brief, whole building wayfinding, unit map, device objects, the discrepancy flow, the amendment log, and the contextual chat.

  • Step 01FigJam pain points
  • Step 02Affinity mapping
  • Step 03Low fi storyboard
  • Step 04Built with Claude
  • Step 05Working prototype
Open Miami General
FigJam · scoping steps
Decision, user, journey, feature cuts, scenario, wireframe
Six scoping cards from the FigJam covering the product decision, primary user and scope, golden journey, core capabilities and feature cuts, hero scenario, and wireframe plan
The six scoping decisions that sat between the affinity map and the wireframes.
10
What I would test next

This is a concept, so here is what I would put in front of PMs.

  1. Does starting an issue from the map actually remove the re-entry step, or do PMs still reach for the systems they already trust?
  2. Can a PM tell the difference between an amended value awaiting verification and a confirmed record, at a glance, mid shift?
  3. Does a narrow AI answer about protected data feel trustworthy enough to act on, or does the permission boundary read as evasive?
  4. Does explicit ownership reduce the amount of messaging around to find out who has the next action?

The part I am least sure about is the amendment. It is the right systems answer, but it asks a PM in a busy unit to accept that the fix is not finished. If that friction turns out to be unacceptable, the honest response is to redesign the verification handoff rather than quietly let the app overwrite the record.

All hospital, device, and staff data here is synthetic. Nothing in this project uses real client information.