Case Study 08 · Biotech / Clinical Research Platform

Clinical Trial
Oversight Dashboard

Site coordinators managing Phase II oncology trials were drowning in disconnected spreadsheets and missing adverse event windows. This is the UX process behind a unified patient monitoring system that cut protocol deviation reporting time by 34% and improved AE response rates to 97%.

Product Thinking Data-Dense UX Design Systems Biotech / MedTech Regulated Industry AI-Assisted Flagging
ROLELead / Solo Designer
SCOPEDiscovery → Design system → Prototype
USERSSite Coordinators, Principal Investigators
TOOLSFigma, FigJam, HTML/CSS/JS, Framer
TIMELINE8 weeks discovery → hi-fi prototype
OUTCOME↓34% deviation reporting time
Phase 01 — Discovery & Problem Definition

The real bottleneck wasn't the data — it was the workflow.

Before any wireframes, I spent two weeks embedded with site coordinators and two PIs at a Phase II oncology trial site. The system in use was a combination of a legacy EDC (electronic data capture) tool, a shared Excel tracker, and a physical binder of protocol amendments. The design problem wasn't a missing feature — it was a missing model of how the work actually happened.

01
Contextual Inquiry — What I Observed
Rather than interviews alone, I shadowed coordinators during morning rounds and adverse event reviews. The behavioral patterns I observed directly contradicted what users said they needed in the intake survey — a classic research gap that only direct observation surfaces.
FIELD OBSERVATIONS · KEY FINDINGS
OBSERVED Coordinators maintained personal Excel files because the EDC system showed data but didn't prioritize it. Everyone built their own triage layer.

OBSERVED AE windows (24hr, 72hr, 7-day reporting deadlines) existed only in coordinators' heads or in paper calendars. No system surfaced them.

OBSERVED Protocol deviation reports required pulling from 3 separate systems. Average time to file: 47 minutes. Target: under 15.

INSIGHT PIs spent the first 20 minutes of every weekly meeting asking for status updates that already existed in the EDC — just in an unusable format.

CORE TENSION Data completeness ≠ Data usefulness · The EDC had everything; it surfaced nothing actionable.
02
Stakeholder Interviews — Two Personas, One System
The system had to serve two fundamentally different mental models: site coordinators (task-oriented, high volume, time-pressured) and principal investigators (decision-oriented, lower frequency, pattern-seeking). Designing for one persona at the expense of the other was the failure mode of the existing tool.
INTERVIEW SYNTHESIS · VERBATIM QUOTES
"I know which patients are at risk. The system doesn't." — Site Coordinator, 6yr experience
"I need to see three things when I open this: who's in trouble, what needs a decision today, and what I might have missed." — Principal Investigator
"Every AE I miss is a regulatory problem. Not a software problem — a regulatory problem." — Senior Coordinator
"The data is in there. Getting it out in a useful form takes longer than just calling the coordinator." — PI, Oncology

DESIGN MANDATE The system must do the triage — not ask users to do it manually on arrival.
03
Problem Statement & Design Principles
From synthesis, I derived a crisp problem statement and four non-negotiable design principles. Every subsequent decision — component choice, information hierarchy, color system — was tested against these.
DESIGN PRINCIPLES · RANKED BY REGULATORY WEIGHT
PRINCIPLEIN PRACTICEPRIORITY
Surface risk, not dataThe dashboard opens to what needs attention today — not an alphabetical patient list. Triage is the system's job, not the coordinator's.Critical
AE windows are non-negotiableAdverse event reporting deadlines are regulatory requirements. They get primary visual treatment — always visible, never buried in a detail view.Critical
Two personas, one surfaceNo role switching. Coordinators and PIs see the same interface — coordinators drill down into tasks; PIs read the summary layer without context-switching.High
Audit everythingIn a regulated clinical environment, every action — including a read — is potentially auditable. The design must make this invisible to users but complete for compliance.High
Phase 02 — User Flow Mapping & Journey Analysis

Mapping the critical paths — and the failure modes.

I mapped four flows: the coordinator's daily triage, the AE escalation path, the PI's weekly review, and the deviation reporting workflow. The deviation flow had the most friction and the highest regulatory stakes — it became the first prototype target.

04
Primary Flow — Daily Coordinator Triage
The coordinator's morning workflow needed to collapse from a multi-system, 25-minute process into a single-surface 5-minute review. This flow maps the as-is state and the target state, with the specific friction points that became design targets.
FLOW — TARGET STATE (REDESIGNED)
Coordinator opens dashboardSingle entry point
System surfaces priority queueAI flags AE windows + deviations
Review flagged patientsSorted by urgency tier
Action or escalateAudit entry auto-created
FLOW — AE ESCALATION PATH (HIGHEST REGULATORY RISK)
AI detects AE signalLab value or symptom flag
24hr window opensCountdown visible
Coordinator reviews & gradesCTCAE grade selection
PI notified if Grade ≥ 3In-app + email
Report auto-draftedRegulatory submission ready
05
Information Architecture — Mapping What Lives Where
The IA decision that unlocked the design: patient data flows in three layers — status (always visible), events (surfaced on flag), and history (accessed on demand). This matches the coordinator's mental model exactly: they think in terms of current state, not record history.
IA LAYER MAP · COORDINATOR VIEW
LAYERWHAT IT CONTAINSWHEN VISIBLEDESIGN TREATMENT
L1 · StatusPatient ID, current visit, enrollment status, AE flag, last contactAlways — in table rowFull width, sorted by risk tier, color-coded left border
L2 · EventsActive AEs, open deviations, upcoming visit windows, pending formsOn row click — slide-in panel300px panel, non-modal, preserves table context
L3 · HistoryFull visit log, prior AEs, lab trends, consent versionsOn explicit request — new viewFull-screen patient record; intentional navigation cost
Phase 03 — Design System & Visual Language

Tokens before components — building for compliance and scale.

Clinical software has an earned reputation for visual chaos — dense tables, inconsistent status colors, no hierarchy. I built the token system before touching a single component, with a specific constraint: every status color had to be WCAG AA compliant at the background values used in the product, and every semantic color had to carry only one meaning across the entire system.

06
Color Token System — Semantic, Not Decorative
The hardest design constraint: in regulated healthcare interfaces, color is communication — not branding. Every color maps to exactly one meaning. Red means adverse event risk. Amber means attention required but not urgent. Green means on protocol. No exceptions. This is enforced at the token level so future designers can't accidentally misuse it.
COLOR SYSTEM · SEMANTIC TOKEN MAP
--risk-critical
#e05c6a · AE active / SLA breach
--risk-elevated
#f5a623 · Action required / window open
--status-ok
#3ecf8e · On protocol / cleared
--interactive
#4f9cf9 · All interactive elements
--data-secondary
#2dd4bf · Charts, secondary data
--ai-flag
#a78bfa · AI-generated signals only
07
Typography System — Hierarchy Under Information Density
Clinical interfaces fail at typography more than anywhere else. Everything is 12px, everything is the same weight, nothing is actually readable after 6 hours on shift. I built a three-tier type hierarchy with an explicit rule: no data value may share visual weight with the label that describes it.
TYPE SPECIMENS · THREE-TIER HIERARCHY
DISPLAY
Fraunces 100
Section headers
KPI values
Trial Overview
Phase II Oncology
UI BODY
Syne 500
Patient names
Nav, labels, actions
Margaret Harrington · Patient enrolled · Visit 4 complete
MONO
JetBrains 400
IDs, timestamps
Status codes, data values
PT-40821 · 2026-05-14 08:32 UTC · AE-CTCAE-G2 · WINDOW: 18h remaining
08
Component Hierarchy — The Status Row
The patient row is the most-used component in the system — viewed hundreds of times per shift. I iterated through 8 versions of the row before settling on the final pattern: left-border color coding (always visible, requires no reading), status chip (scannable at a glance), and a monospaced ID column (fast pattern recognition). No version passed until it was readable in 1.5 seconds in a usability test.
ITERATION LOG · PATIENT ROW COMPONENT
V1: Text-only status label · FAILED — coordinators missed alerts during fast scanning
V2: Color-coded background rows · FAILED — too visually noisy; hard to distinguish at density
V3: Icon + text status · FAILED — icons required learning; non-obvious to new coordinators
V4: Left border color + text chip · PASSING — border is pre-attentive; chip adds semantic label
V5: V4 + monospaced ID column · WINNER — ID scanning improved 2.3× in timed tests
V6: V5 + AI flag indicator (purple, distinct from status colors) · Final production version
Phase 04 — Working Interactive Prototype

The full working interface

Production-fidelity prototype of the Site Coordinator Dashboard. Click any patient row to open the detail panel. Use the filter controls to triage by status. The AI flag system, status chips, and detail panel all work as they would in the shipped product.

Meridian Clinical · Trial Operations · NCT04821660 · PHASE II ONCOLOGY
NCT04821660 · CATALYST-2 Ovarian Cancer Study
Site 007 · Manchester, NH  ·  Dr. Sarah Okonkwo, PI  ·  Last sync: 08:41 UTC
Phase II
● Recruiting
Protocol v3.2 ↗
Enrolled
34
↑ 2 this week
Active AEs
3
2 within 24hr window
Open Deviations
1
Report due Fri
Protocol Adherence
97%
↑ 4pts vs last cycle
6 patients
Patient ID Name Status Visit Last Contact AE Window
PT-40821 Margaret Harrington ⚠ AE Active V4 · C2D1 Today 06:18 18h remaining
PT-40799 Robert Park ⚠ AE Active V6 · C3D8 Yesterday 14:22 41h remaining
PT-40844 Diane Okonkwo ↻ Deviation V3 · C1D15 2d ago No open window
PT-40866 Thomas Vásquez ◎ Screening V1 · Baseline Today 09:04 Pre-enrollment
PT-40788 Linda Mehta ✓ On Protocol V7 · C4D1 3d ago Cleared
PT-40812 James Chen ● Complete V9 · EOT 1w ago Completed
✕ close
Full Record ↗
File AE Report
Phase 05 — Outcomes & Measured Results

Results measured against the baseline that mattered.

The prototype was validated in a two-week usability study with 6 coordinators at the original trial site. Measurements were taken against the existing EDC + Excel workflow. Three metrics were defined before the study began — no post-hoc cherry-picking.

DEVIATION REPORTING TIME
↓34%
47min → 31min avg · Pre-defined success threshold: 20%
AE WINDOW COMPLIANCE
97%
↑ from 81% · All AEs filed within regulatory window
COORDINATOR TRIAGE TIME
↓58%
22min → 9min avg morning review · Biggest surprise finding
PI STATUS MEETING TIME
↓40%
Status updates replaced by dashboard review; meetings focused on decisions
SYSTEM ERROR RATE
↓71%
Data entry errors down from 4.2% → 1.2% of records
COORDINATOR NPS
+62
vs. −14 for legacy EDC tool · Measured post 2-week trial
09
Tradeoffs Made — What I Chose Not to Build
Good product design requires explicit decisions about what to cut, not just what to add. Three features were removed from the v1 scope after research, with documented reasoning.
DESCOPED FEATURES · RATIONALE
FEATUREWHY CUTFUTURE STATE
AI auto-grading of AEsCoordinators need to own the CTCAE grade — automated grading created liability ambiguity and eroded trust faster than it saved time. The AI flags; the human grades.V2 — AI as suggestion with explicit override
Real-time lab value chartsCoordinators don't act on trends — they act on thresholds. A sparkline adds cognitive load without triggering different behavior. The threshold flag is enough.Available in L3 patient history view only
Cross-site comparison dashboardPIs found it interesting but couldn't act on it in a single-site context. Built a better single-site tool first; multi-site is a logical v2 with sponsor access controls.V2 — requires sponsor-level permissions design
10
What I'd Do Differently
Honest retrospective — the things that would change in a v2 engagement.
RETROSPECTIVE NOTES
REGRET I underscoped the mobile use case. Coordinators check patient status on their phones between clinic rooms. The prototype is desktop-first — mobile was an afterthought. Mobile should have been a constraint from Week 1, not a v2 consideration.

REGRET The AI flag system (purple) wasn't tested with colorblind coordinators until Week 7. It passed WCAG contrast but failed real-world legibility for deuteranopia users. Purple + blue in the same table is a known fail pattern I should have caught earlier.

WIN Starting with field observation instead of interviews. Every assumption from the intake survey was wrong in at least one meaningful way. The Excel workarounds were invisible until I watched someone use them.