Designing a research-platform suite for pharmaceutical R&D

TL;DR

• Context: ~5.5 years as UX lead in the R&D division of a global pharmaceutical company.
• Problem: Study plans and results lived in Word and Excel. You couldn’t search or compare them, and knowledge left together with its author.
• What I did: I designed a study planning tool, a lab task-list module and a new platform for analyzing and comparing results.
• Result: Study planning takes a few days instead of ~2 weeks (~70% faster). A research report takes a few hours instead of ~3–5 days.

Diagnosis

For years, scientific knowledge in this organization lived in documents. Study plans were in Word, data in Excel, and charts got into reports by copy and paste. None of it could be searched, compared with earlier studies or reused in the next piece of work. So both platforms in this case study solve the same problem: they turn documents into data the organization can use again and again.

flowchart LR
    A["Plan the study"] --> B["Auto task list for the lab"]
    B --> C["Analyze results"]
    C --> D["Compare many 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

• I led UX for research platforms covering a scientist’s whole path: from planning a study, through the lab’s task list and results analysis, to comparing many studies.
• I designed two new tools from scratch inside the existing study database: a study planning tool and a lab task list generated from the plan.
• I designed a new platform for analyzing results and comparing studies. It replaced manual work across Excel, an online calculator and Word.
• I looked after a pool of UX contractors that grew from 1–2 to ~15 people. I recruited them and matched them to projects.

Results

• Study planning: ~2 weeks → a few days (~70% faster).
• Research report: ~3–5 days of manual work → a few hours for several reports.
• Study plans and analysis results moved into a searchable system. Knowledge stopped disappearing with its author.
• At launch ~50 scientists from two research areas used the tool. I designed it so more areas could be added.
• Finding a similar study in a database of hundreds, even thousands of studies takes a moment. Before, it was almost impossible, so some studies were simply repeated.
• An analysis method my colleagues developed on these tools was published in a peer-reviewed oncology journal (dozens of citations). (The full citation is in the presentation version; I leave it out here for anonymity.)

The problem

What did study planning look like?

Scientists wrote study plans in Word, as plain text. A plan like that couldn’t be searched, compared with earlier studies or turned into a task list for the lab. That made the whole planning process slow.

The hardest part was that a plan runs on two clocks at once:

• Study time. Science counts in study days: on which day to weigh the animals, dose the drug, draw blood.
• Calendar time. The lab works in real dates, with people, equipment and days off.

On top of that, a study has cohorts (groups that start at different times) and measurements that repeat. Matching study days to the real calendar in Word was slow and easy to get wrong.

And what about analyzing results?

Scientists collected data into Excel by hand. Then they pasted it into an online tool that worked like a calculator with no memory. Nothing was saved there, so charts had to be downloaded and pasted into a Word report by hand.

What hurt the business most was finding earlier studies. Each study had only a few pieces of metadata, so finding work with similar parameters was close to impossible. The new system had to collect data in a structured form and make it searchable.

My role / scope

• I was UX lead for the whole area. The planning tool was entirely mine; I set its direction from day one. I designed the analysis platform as lead, and after a while one contractor joined me.
• On the existing study database I led 2–3 contractors.
• I worked mostly with scientists and with a development team that had biostatisticians in it. The analysis platform ran on R Shiny with a custom Bootstrap front end, and we built the interactive chart grid in Angular.

Process

• Research with scientists, in a loop. I talked to scientists, prototyped, tested and collected feedback. Round and round, for the whole project. Mostly remote, but also on site with the research team in the US.
• Results analysis. Watching scientists’ daily work showed two main problems: manual reports and searching for earlier studies. Then, together with the developers, we designed a new architecture. The old calculator had to go so the data could stay in the system.

Key decisions & trade-offs

• One tool for different fields. Teams from cancer research, neurology and other areas used the tool. Each area had its own requirements, so instead of tailoring the tool to one team, we built it on parameters. The same rule later applied to the analysis module.
• The study as the main object in the system. One study is one entry, but it can hold many analyses. Several scientists use results from the same study, and each looks at different parameters.
• Raw data stays, exclusions are documented. The old system kept raw and processed data with no record of what was removed and why. In the new one the original dataset always stays. On the exclusion screen a scientist sorts data by subject, day or group, excludes single points or whole series, and leaves a summary for others.
• One analysis module for many departments. A scientist picks an indicator (e.g. weight or blood results), then a study, and finally the parameters. Many analyses with different parameters can be laid out in a grid.
• A chart grid that isn’t even. Rows are drugs, columns are doses, but each drug has different doses. Some cells have to stay empty. I have to admit that fitting the layout to this unevenness did the most for how readable the analyses were.

The analysis grid can’t be even. Each drug has different doses, so empty cells are normal here.

• A report built like in Notion. A scientist writes text and drops charts and tables from the analyses into it.
• Comparing many studies, from scratch. This module didn’t exist before, and studies were compared by hand. The hardest part was matching groups, because each study numbers them its own way. A scientist first defines a comparison layer (usually drug + dose). Then, for each study, they pick from a list which group belongs to it: in the first study it’s group 2, in the second group 6, in the third group 3. The solution is simple, and in my view that’s exactly why it worked. After that the scientist uses the same steps as in the main platform: data cleaning, analyses, report.

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

• The calendar shows conflicts instead of solving them on its own. Labs are run by ordinary people. There are holidays and days when someone on the team is missing. A blood draw planned for study day 50 could land on a day the lab isn’t working. Moving such events automatically would have been too complicated and too dependent on people, so we gave lab staff a calendar view. They see what lands on a holiday or a short-staffed day and decide themselves what to do about it.

The schedule runs on two clocks at once, study days and the lab calendar. The tool shows the conflict instead of hiding it.

• Handing the tool over. In autumn 2019 I moved to more strategic work across the whole area. The planning tool was taken over by a person hired internally on a permanent contract. By then the process was settled enough that little conceptual work was left for them.

How it turned out

Study planning shrank to a few days, and plans stopped living in Word. On the analysis side, a report that used to take several days now takes a few hours. Scientists can also try different variants of an analysis, because the system remembers each one. In my view the best signal was that after seeing the analysis platform, the neurology team asked on their own to be the next to adopt it.

What I took away

• Real scientific data doesn’t fit into even tables. One drug has three doses, the next has three different ones. The design has to accept that, because forcing an even layout hurts readability.
• Time mattered less than the new way of working. A shorter report is nice, but in my view the bigger change was that scientists can save and compare many variants of an analysis. Before, they simply couldn’t.
• It pays to seat experts next to developers. Biostatisticians sat in the development team, so the calculations were right from the start.
• The “for every field” requirement turned out to be an advantage. We had to support cancer research and neurology at once, so we built the system on parameters. Thanks to that it could later be used in areas it wasn’t originally designed for.