Rethinking clinical trial safety tool
Who’s the client
More than 90% of the medications and devices approved by the FDA got there on Medidata’s platform. They serve millions of patients in clinical trials all over the world.
They run 50+ separate products across the trial lifecycle — data capture, payments, safety reporting, medical imaging, and more. Rave Safety Gateway is one of them.
What is this
When someone in a clinical trial has a bad reaction to a drug, the trial site logs it in Medidata’s system. That information then has to reach a separate safety system — fast, since regulators need to know. The problem: the two systems can’t talk to each other directly.
Rave Safety Gateway is the bridge. One team sets up which piece of data goes where. Another team checks and approves it before it’s sent off.
The tool did its job. But it was built around how the backend worked, not around how the people using it actually thought and worked. That’s what we were brought in to fix.
How the work started
The product team came to us with a request: update the visual design, clean things up, make it feel more current.
Research stage (~6 weeks)
- Kicked off with the product team to align on scope
- Mapped how people actually used the current tool, step by step
- Talked to 8 users (study developers)
- Looked at how competitors solve the same problem
- Looked at how other Medidata products handled similar problems
- Ran a few rounds of brainstorming with the team
What we learned
Turns out “update the visuals” was the wrong problem to solve.
The real issues weren’t about how things looked — they were about how confusing the tool was to think with. It showed users the internal plumbing instead of hiding it. Study developers and safety specialists had to hold a mental map of the whole system in their heads just to get through their work.
The product team had a list of small visual tweaks they wanted made. We pushed back — kept what users said was already working, and spent the redesign on what they said was actually hard.
Before After The key insight
Study developers don’t complete a configuration mapping in one go.
A full mapping session can take hours. Users routinely stop partway through and come back later, sometimes days later.
The old interface had no memory of this. There was no way to see at a glance what was done, what was left, or what state a section was in. Every return meant re-orienting from scratch, scanning the entire mapping to figure out where you left off.
The tool needed to hold the user’s place — not just technically, but visually. So dropping back in after a break meant immediate orientation, not re-discovery.
1/3 Design decision — Navigation
The old design was just a flat list — click into a study and you had no idea where you were, or how to jump to another section without starting over.
We built a clear structure instead — client, then study group, then study, then the Safety Gateway tab inside it. A sidebar that’s always visible lets people jump between sections without losing their spot.
2/3 Design decision — Versioning model
Behind the scenes, every configuration had multiple versions, and each version could be live in different places — a testing environment, or the real production system. None of that showed up on screen. Users had to remember it all themselves.
We made it visible. Each form now has named versions (V1, V2, V3), each with a status — Draft, Ready, or In Use — and each one clearly shows where it’s deployed. One table shows the whole picture. No more clicking around to find out what’s actually live.
Now people can see the whole picture at a glance instead of having to remember it. We designed this versioning system from the ground up.
3/3 Design decision — Progress sidebar
From user interviews, we decided that the mapping interface needed to tell users both where to go and what was done.
Drop back in after a break, open the sidebar, immediately know what’s done and what’s not. No scanning. No re-discovery.
Hardest decision
The product team asked for a visual refresh. Six weeks of discovery showed the real problems were structural, not cosmetic.
The hardest call was pushing back on the brief I was given, protecting what already worked and arguing for the deeper redesign the research pointed to.
Outcomes
- ~75% faster
- configuration cut from around 2 hours to roughly 30 minutes
- 1 admin in 1 sitting
- where it used to take multiple specialists across several sittings
- +4 new clients
- just after the demo presentation