Case study · IQVIA
A self-serve tool that took trial setup from weeks to hours for two new enterprise clients.
Trial setup from weeks to hours
Two enterprise clients onboarded
Reusable templates for a new product offering
Before a new medicine can be tested, hospitals and clinics in many countries have to be approved to run the trial. Each one needs a checklist of paperwork, such as patient consent forms and ethics-board approvals, and the checklist changes by country. Drugmakers (called sponsors) and the research firms that run trials for them track that paperwork in our platform. Someone has to build the checklist for every new trial.
Getting a trial ready to start is slow, and it is where much of the time goes. One industry survey of clinical research professionals put it at about 61% of a trial's timeline, and 81% still relied on spreadsheets and manual hand-offs. Our product was no different: setup was manual, and it took weeks.
That was about to become a problem. Two new enterprise clients were each about to start 12+ trials a month, more than we could set up by hand. The goal was 24+ trials a month, plus reusable templates we could eventually offer as a product.
Before designing anything, I mapped, step by step, how four client teams had been onboarded. There was no standard process, and the time ranged from 2–3 days to 18–24 months. Returning clients with the same countries and sites were fast, while a new client took 6–10 weeks at best. The more a setup resembled one we had done before, the faster it went. That told me the slowness was not mainly a screen problem. Every team set things up its own way, so a tool that simply digitized today's steps would digitize the inconsistency too. The design had to make setup repeatable.
1. Learned the work before designing it. I mapped the setup tasks end to end, then built personas and empathy maps for the three people who do the work: the study manager, the country lead and the study team member. I ran workshops with internal subject-matter experts who knew the work first-hand. The country lead mattered most. They know each country's rules, rules change often, and everything downstream waits on them.
2. Started with the smallest useful version. The requirements list was long. I prioritized it with stakeholders as must-have, should-have and nice-to-have, and defined a first release small enough to ship: an admin creates a catalog (a library of reusable checklist templates for one client), picks the studies, and publishes. That gave engineering and stakeholders something concrete to agree on before any detailed design.
3. Made setup reusable. Paperwork repeats from trial to trial, so I designed templates for checklist items, milestones and approval workflows. An admin builds them once. A new trial starts from a template, and the admin only chooses what is specific to it, such as which countries.
4. Kept everyone aligned. I wrote the governance document that laid out the problem and the proposed features, and I joined quarterly planning with engineering to map dependencies and size the work. I presented a plan each quarter so stakeholders knew what was coming, and walked them through prototypes in design reviews. We shipped in two releases: core setup first, then the advanced pieces.
Measure beyond the pilot. The "weeks" came from my customer research and the "hours" from beta pilot users, which is a fair comparison but a small one. I would track setup time across all new trials after launch, so the result held up at full scale, not just in the pilot.
Test with the people who run it. My personas came from internal experts. I would also put prototypes in front of the clients' own admins early, since their habits were the ones the tool had to replace.
Design for rules that change. Country requirements change, and a published template can go out of date. If I did this again I would design how a change reaches trials already in progress, not only new ones.
