Designing a research-platform suite for pharmaceutical R&D

TL;DR

• Context: ~5.5 years as UX lead for an R&D unit at a global pharmaceutical organization.
• Problem: Study plans and results lived in Word and Excel — unsearchable, uncomparable across studies, and gone when the author left.
• What I did: Designed a study-planning tool plus a lab task-list module, and a new analysis-and-meta-analysis platform.
• Result: Study planning ~2 weeks → a few days (~70% faster); report building ~3–5 days → a few hours.

Diagnosis

For years, the scientific knowledge here lived in documents — study plans in Word, data in Excel, charts pasted by hand into reports. You couldn’t search it, compare it across studies, or feed it forward into the next piece of work. Both platforms in this case study attack the same core problem: turning research knowledge from documents into structured data the organization can reuse.

flowchart LR
    A["Plan a study"] --> B["Auto-generated lab task list"]
    B --> C["Analyze results"]
    C --> D["Meta-analyze across studies"]

    classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
    class A,B,C,D neutral
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

What I did

• Led UX for a portfolio of research platforms spanning the full scientist journey: plan a study → generate the lab’s task list → analyze results → meta-analyze across studies.
• Designed from scratch two new tools inside a legacy research database: a study-planning tool and the auto-generated lab task list it produces.
• Designed a new analysis & meta-analysis platform that replaced manual spreadsheet–calculator–Word workflows.
• Managed a pool of ~15 UX contractors — recruiting and matching them to projects across the portfolio.

Results

• Cut the time to plan a study from ~2 weeks to a few days (~70% faster).
• Moved study plans and analysis knowledge out of scattered documents into a structured, searchable system (knowledge retention).
• Built the planning tool to be mature enough to hand over to an internally recruited successor (autumn 2019) as I moved into a more strategic, portfolio-wide role.
• Adopted at launch by ~50 scientists across two research areas, designed to scale to further scientific domains over time.
• Cut the time to produce a research report from ~3–5 days of manual work to a few hours for several reports (an order of magnitude). Before, scientists assembled reports by hand in documents; the old analysis tool was a calculator with no memory — once closed, the work was gone.
• Turned that memoryless calculator into a playground: scientists can run many analyses with different parameters and keep them all, then explore variants and pick the best one — a way of working that simply wasn’t possible before.
• Made finding and comparing past studies instant (structured search) across a database holding hundreds to thousands of studies. Before, finding a comparable study was near-impossible, so some were simply re-run instead of found.
• The analysis methodology my collaborators developed on this tooling was published in a peer-reviewed oncology journal (cited dozens of times). (Full citation kept in the presentation variant — omitted here to stay anonymized.)

The problem

What was planning a study actually like?

Study plans were written in documents, as unstructured text — not as structured data. That meant a plan couldn’t be queried, compared with past studies, or turned into anything actionable downstream. Planning was slow and lived in prose.

Planning also runs on two clocks at once, which is the real source of complexity:

• Study time — the science is defined in days of the study: when to weigh subjects, administer the compound, and draw blood.
• Calendar/lab time — the laboratory operates in real dates: equipment, staff, and facility slots. On top of that, a study has cohorts (subject groups started at different times) and recurrence (measurements that repeat). Reconciling study-day timepoints with real calendar availability — across cohorts and recurrences — was slow and error-prone as long as it lived in a Word document.

And analyzing the results?

Reports were built manually in Word. Scientists collected data by hand into Excel, then used an online tool that worked like a calculator with no memory — analyzed data wasn’t stored, so charts and analyses had to be downloaded and pasted into documents by hand.

The biggest business pain was finding and comparing past studies: each study carried only limited metadata, so finding research with similar parameters was nearly impossible. The new system had to collect structured data and make it searchable.

My role / scope

• UX lead for the portfolio. The planning tool was entirely mine — I set the direction from day one. The analysis platform I designed as lead.
• Led ~2–3 contractors working on the legacy system, within a ~15-contractor pool I managed across the portfolio.
• Worked mainly with scientists (the people running and analyzing studies) and a dev team that had biostatisticians embedded in it — the people who knew the statistics sat with the people building the software, not in a separate silo. The analysis platform ran on R Shiny with a custom Bootstrap front-end, plus Angular for the interactive chart grid.

Process

• Continuous research loops: interviews with researchers → prototyping → testing → collecting feedback — repeated throughout. Mostly remote, but also on-site with the US research team.
• Analysis platform: UX research into scientists’ daily work surfaced the two core problems (manual reports; search/comparison). I then worked with developers to design a new architecture — the old “calculator” had to disappear so data could live in the system.

Key decisions & trade-offs

• Universal across scientific domains. The tool served areas with very different requirements — cancer research, neurology, and others — so it had to be flexible enough to adapt to each domain rather than hard-coded to one area’s workflow. (The same principle drove the universal analysis module on the analysis side — flexibility is the through-line of both platforms.)
• The study as the core entity. One study = one instance in the system, but it can hold many analysis documents, because several scientists use the same study’s results and each analyzes different parameters. (Strong IA decision.)
• Keep raw data, mark exclusions. A data-cleaning rule: always retain the original dataset and explicitly mark what’s excluded and why (the old system attached both raw and processed data with no clear record of exclusions). An exclusion screen lets researchers arrange data by subjects / days / groups, exclude single points or in bulk, and produces a summary so others can review what was removed and why.
• A universal analysis module. Analyses had to serve multiple departments. Flow: pick an endpoint (e.g., subject weight, blood results) → pick the study → set parameters; multiple analyses with different parameters can be arranged on a grid.
• An irregular chart grid (small multiples with non-uniform axes). Lay analyses out as a grid — rows = drugs, columns = doses — and each drug has a different set of doses. So the grid can’t be regular; the layout has to absorb that non-uniformity. Nailing this was the single biggest readability win on the analysis side.

• A Notion-like report builder — free-form text layout with analysis elements dropped in.
• Meta-analysis built from scratch — “comparison layers.” This module didn’t exist before; studies were compared by hand. The hard part was mapping research groups across studies, because every study numbers its groups differently. The solution: the scientist first defines comparison layers (most often drug + dose), then for each layer picks — via dropdown — which group in each study belongs to it (in study 1 that’s group 2, in study 2 group 6, in study 3 group 3). Simple, effective, clear. The rest of the flow (data cleaning → analysis playground → report) reuses the main platform.

flowchart LR
    A["Study 1<br/>group 2"] --> W["Comparison layer<br/>drug + dose"]
    B["Study 2<br/>group 6"] --> W
    C["Study 3<br/>group 3"] --> W

    classDef info    fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class A,B,C info
    class W accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

• Dual-time model (planning tool) — and the hardest part wasn’t the two clocks themselves, but reconciling the study calendar with the real one. A lab is staffed by real people — bank holidays, staffing gaps on certain days — so an event defined in study-time (e.g., “draw blood on day 50”) could land on a day the lab simply doesn’t operate. Rather than auto-resolve those clashes against lab capacity (too tangled, too human), we gave lab staff a calendar view of the events so they could see what falls on a holiday or a gap day and handle it. Transparency over automation.

flowchart TD
    S1["Study time<br/>day 50: draw blood"] --> X{"Collision with lab calendar?"}
    C1["Calendar time<br/>real date is a holiday"] --> X
    X -->|"yes"| V["Calendar view for lab staff<br/>transparency, not auto-resolve"]
    X -->|"no"| Y["Event scheduled normally"]

    classDef info    fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
    classDef good    fill:#e6f2ea,stroke:none,color:#1f4d33,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class S1,C1 info
    class X info
    class Y good
    class V accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

• Hand-off. Autumn 2019 — I moved into a more strategic, portfolio-wide role and handed the planning tool to an internally recruited successor; by then the process was defined enough that there was little conceptual work left for them.

How it turned out

• The analysis side moved report-building from ~3–5 days of manual work to a few hours for several reports, and turned a memoryless calculator into a playground where scientists explore variants rather than compute one-shot.
• The strongest demand signal: after seeing the analysis platform, a neurology team asked to be next to adopt it — the tool sold itself inside the organization.
• On the planning-tool side: ~70% faster study planning; planning knowledge moved out of documents into the system.

What I took away

• Design for non-uniform complexity. Real scientific data doesn’t sit in tidy matrices — one drug has three doses, the next has three different ones. The design has to absorb that irregularity rather than force uniformity.
• “Faster” wasn’t the real win — a new way of working was. The biggest shift wasn’t cutting report time; it was turning a one-shot calculator into a persistent playground where scientists could explore variants they couldn’t before.
• Embed domain experts in the build. Biostatisticians sat inside the dev team. When the people who know the math sit with the people who write the code, the analysis is actually correct.
• Universality as a constraint, not a feature. Serving cancer research and neurology at once forced a parameter-driven system instead of a hard-coded workflow — which made the tool reusable across domains it wasn’t originally built for.