From stakeholder interview to working prototype in 24 hours

Large organisations usually lose time between hearing a need and shipping something that meets it. Research sits in reports, prototypes wait for review cycles, and engineering gets static designs with gaps it has to fill alone.

We collapsed that gap. Recruitment is where trials most often slip, so the prototype followed it end to end. Site teams needed to see their candidate pipeline, from eligible pool to enrolment, and which patients on trial needed a check-in. Trial operations needed enrolment against target across the portfolio, with early warnings before a study fell behind. Patients needed a simple daily check-in. We built all three views through a delivery loop designed for speed.

The company is not named here. The images are from the working prototype, rebuilt with dummy data under an invented brand.

What I did

As Senior Principal Designer, I designed the delivery model around four steps that ran continuously.

Continuous discovery. We interviewed people across the organisation throughout delivery, in place of a single research phase at the start. They included study leads, study managers, local delivery leads, start-up teams and resourcing leadership.

AI-assisted synthesis. We fed interview insights into an AI model to find patterns, sort needs and generate prototype directions. A stakeholder interview in the morning became a working prototype by the next day.

Rapid prototyping and guerrilla testing. We put working prototypes back in front of the same users for short usability sessions. The people who described a problem verified the fix.

Production-ready handover. We moved validated prototypes into production and handed them to the development team with full implementation notes. Engineering received working, validated code with the reasoning attached.

Each round produced two outputs: fixes to ship now, and opportunities to hold for later, such as AI-generated study narratives. That split kept speed from crowding out the bigger ideas.

The constraint

Speed in a regulated R&D environment carries a risk: AI synthesis can sound confident and still be wrong. Testing every iteration with the same users who raised the original need kept the loop honest.

Users liked the prototypes but questioned the data underneath them. Every participant cross-checked figures against source systems, and no screen showed when the data was last refreshed. Manual update features duplicated risk logs that teams already kept elsewhere. The loop surfaced these issues early enough to fix them before launch.

What happened

The prototype was tested with every participant. Study leads saw the enrolment view as ready for leadership and a direct replacement for manual charts and weekly reports. Their conditions for the pilot were clear: make the logic behind the figures transparent, and scope views to each role. Those fixes went straight into the next iteration.

Every insight reached a working prototype within 24 hours of the interview that produced it. Findings went from the last usability session to a prioritised, shippable list in days.

What I would do differently

I would map the systems of record before prototyping any input screen. The loop caught stale data and duplicate entry quickly, but both were knowable on day one. A fast loop rewards a strong starting position.

This work was delivered with Slalom.