A clearer system for the people running clinical trials.
Study setup was spread across three platforms. I designed a unified workspace around how clinical teams actually work: set up the study, organize its sites, and manage participants with the right level of access.
- My role
- Product Designer
- Scope
- 0 → 1 · IA & workflows · Stage 1
- Constraints
- Existing patterns · regulated context · fixed deadline

Align the information hierarchy with the work, then make each role’s responsibilities clear.
One platform. Two very different responsibilities.
Clinical Affairs Admins set up studies and manage their lifecycle. Study Admins handle day-to-day participant operations. The old workspace did not make that distinction clear.
Clinical Affairs Admin
Creates and configures studies, adds sites, and assigns the admins responsible for initial enrollment.
Study Admin
Manages participant accounts, exports participant lists and reports, and supports execution at each site.
The challenge was to bring both roles into one system without flattening their responsibilities or creating unfamiliar patterns inside an existing medical platform.
The friction started before the first screen.
“I have to juggle three different platforms just to set up one study.”Clinical Affairs Admin
Create
Study setup crossed three platforms. Teams needed a single entry point for the whole task.
Find
Dozens of active and ended trials made it difficult to identify the right study by name or code.
Manage
The system structure did not match site-by-site trial operations, causing repetitive navigation.
These findings shaped the information architecture, study list, and creation workflow. Each design decision addresses a specific part of the work.
Fix the structure. Then design the screens.
Match the hierarchy to trial operations.
I organized the workspace around Study → Site → Participant. Shared setup belongs at the study level; day-to-day execution stays within the relevant site. This gives each action a clear scope and reduces backtracking.

Make the right study easier to recognize.
The dense table gave every field similar weight. Study cards emphasize the identifiers admins look for first: code, name, type, and status. Separating active and ended studies narrows the scan before users open a record.
Give study setup one clear starting point.
A guided creation flow brings Basic information, Sites, and Admins into one sequence. It shows required inputs at the relevant step and makes progress visible, replacing the handoffs across three tools.


Sometimes the right design decision is to remove an action.
Validation revealed accidental clicks on “End Study.” In a clinical workflow, easy access to a destructive action was the wrong tradeoff.
On the study card
Fast to access, but exposed during routine scanning.
Inside study details
Lower exposure, but still available in the working interface.
Through a controlled path
Removed from the routine UI surface to reduce accidental activation.

I prioritized a safer action path over fewer clicks. The decision was about how much exposure a high-risk action should have in everyday work.
A connected workflow, from setup to site-level execution.

01 · Set up a study
A Clinical Affairs Admin creates a study through one guided sequence.
02 · Add participants
Participants are added at the study level before site-level execution begins.
03 · Export site-level data
A Study Admin exports participant information for reporting and audits.
A foundation the team could build on.
Ease-of-use rating
Moderated usability sessions with 5 participants, rated after task completion.
Used at Stage 1 launch
The Clinical Trial lead confirmed that the workflow fit the team’s day-to-day operations.
A structural baseline
The Study → Site → Participant model carried into subsequent Source Admin work.
A deliberate safety choice
The End Study action moved out of the routine interface and into a controlled path.
The hierarchy was the most consequential design decision. Once the structure reflected how people worked, the individual screens became easier to resolve. New patterns also had to earn their place: useful for the task, and familiar within the existing platform.
