01Introduction
Trial coordination console
Clinical sites miss visit windows. The system tells them weeks later.
A concept for the person nobody designs for: the site study coordinator, whose whole job is keeping patients inside a date range that lives in a spreadsheet.
02The Problem
The window is the job.And it lives in a spreadsheet.
Every visit has to happen inside a date range calculated per patient — protocol day, plus or minus the allowed days, counted from that patient's own randomisation date. Miss it and the visit becomes a protocol deviation that has to be explained to the sponsor. The sponsor's system records that a visit happened. It does not compute when the next one must.
- 01
Randomisation
Day zero. The patient's whole visit schedule is counted from this date.
- 02
Window calculated
In Excel, by hand, alongside three or four other trials — each with a different sponsor, portal and login.
- 03
Visit falls due
No alert fires. Nothing in the sponsor's system knows this date exists.
- 04
No slot available
Phone and email, back and forth, while the window keeps narrowing.
- 05
Window closes
Silently. Nobody is told. The visit is now a protocol deviation.
- 06
Monitoring visit
Weeks later, this is where it gets found — and explained.
One patient, one missed window — and six steps where nothing in the system was watching.
03What we threw away
Our first version was a dashboard.We threw it away.
It was a good dashboard: enrollment against plan, site health, open queries, protocol deviations, all in one calm view. It also solved nothing. Every CTMS on the market already ships that screen, and it fails the same way they all do — it reports the problem accurately, after the problem has happened.
The fix was not a better dashboard. It was changing whose day the product is built around. A study manager needs oversight across many sites; a coordinator needs to get through today at one site. Same data, opposite job — and the interface follows whoever signs the contract.
That rejected dashboard is still in the file, kept on purpose.
04The three decisions
Three decisions, andwhat each one cost.
The design bet was written first, and every screen was judged against it: move the moment of discovery earlier. Show the window while it is still open — not the deviation after it has closed.
- 01
A worklist, not a dashboard
The home screen answers one question: what must I do today. It opens on two groups only — windows closing now, and windows closing this week — each row carrying the patient, the visit, the window and the room left in it.
The trade-offA study manager gets almost nothing out of this screen. We accepted that. A screen built to serve both roles equally serves neither.
Two groups, and nothing else on the screen - 02
No date is ever shown alone
Every date is rendered as its window: the range, a marker for where today sits inside it, and how much room is left. A date tells you when something is due. A window tells you whether you are still safe.
The trade-offA window costs roughly three times the horizontal space of a date. The visit table caps at eight visits per view and pages beyond that.
Every date rendered as its window - 03
Capture the reason at the moment the rule breaks
When a booking has to fall outside the window, the reason is captured right there — category, root cause, and what happened, in the coordinator's own words. The deviation is filed from that record.
The trade-offThis puts a form in front of someone at their most rushed moment. We cut it to three fields and pre-filled two — but it is still friction, deliberately.
The reason, captured where the rule breaks 
Filed, with the trail attached
05Constraints
The constraints that shapedevery screen.
None of these are negotiable in clinical research, and each one removed an option a cleaner design would have taken.
- Regulatory
Any change to submitted trial data needs an attributable, timestamped, permanent record. Nothing here can be silently edited.
- Legacy
The sponsor's systems own the data and are not being replaced. This concept reads from and writes to them rather than replacing them.
- Commercial
The sponsor holds the budget; the coordinator does the work. A tool designed for the site has to be paid for by someone else.
- Accessibility
Window state is never carried by colour alone — every state also carries text and position.
06What this rests on
We interviewed nobody.So here is what this assumes.
This is a concept, not a client engagement. Rather than dress that up, here is exactly what it is built on — and what would have to be true for it to work.
- A1
That coordinators, not sponsors, would be given a tool of their own. Commercially this is the hardest assumption, because the sponsor holds the budget.
- A2
That window arithmetic can be derived reliably from the protocol without manual configuration for every study.
- A3
That a justification captured at booking time is acceptable to sponsors and auditors as the deviation record itself.
- A4
That site staff will adopt one more system, when fewer systems is the thing they actually ask for.
A1 is the one most likely to kill it. It is listed first for that reason.
07What exists
Built as a concept,in full.
Nothing here is measured. This section states what exists and what would be tested — not what was achieved.
- Problem framing
- The user, and the job to be done
- Four named failure moments
- Why the existing category misses them
- The design bet, written before any screen
- Four assumptions, including the commercial one
- Product design
- Eight desktop screens at 1440
- One coordinator, one job, end to end
- Worklist and visit-window matrix
- Booking conflict and out-of-window justification
- Filed deviation with audit trail
- What we would test
- Missed windows per 100 visits, against the site's own previous two quarters
- Elapsed time between a window closing and the deviation being recorded
- Whether coordinators keep their spreadsheet anyway
A missed window should be visible the day it happens — not at the next monitoring visit. That is the hypothesis. It has not been tested.