The Workflow Was the Specification

1. A reported number had a history

One of our projects asked whether a number inside a clinical study report could point back to the records that produced it. That path crossed standardized trial data, analysis datasets, tables or figures, specifications, metadata, and the report itself. Reconstructing it meant opening several artifacts and following the transformations by hand.

I worked with the IT and statistical-programming group on a 15-week proof of concept. We used anonymized subsets from two clinical studies and represented the datasets and their relationships as linked data. A browser let someone select a derived value and inspect the source records that contributed to it. A unique link could also be placed in a Word document and resolved back to the underlying value.

The browser was the part people could see. But the interface only made sense after we understood where the data came from, how one dataset derived values from another, and where the manual handoffs introduced ambiguity.

2. The first design broke on real derivations

The derivation rules mixed natural language and pseudocode. A clinical programmer could interpret them. Software could not do that reliably without solving a much harder language-processing problem. Our original design for complex derivations was not feasible within the project.

So the team changed the approach. The programs that generated the analysis datasets also produced intermediate data describing which source rows contributed to a derived value. We reduced the scope, loaded those relationships into a graph database, and exposed them through the browser.

The result could trace a derived value to contributing data, resolve references in a report, and let a power user query the dependency graph. It also made the unfinished work explicit. A production system would need a more robust way to represent complex derivations at scale.

Earlier in my career, I would have treated the smaller scope as a weaker result. I started to see it differently. The prototype had found the boundary between an attractive idea and the system the idea would actually require.

3. The mouse brain was not a graphics problem

The mouse-brain project looked like a visualization problem. We had scans used in Alzheimer’s research and needed an interface for exploring them. It would have been easy to start by choosing a graphics library and drawing something impressive.

But displaying a brain was not the job. We first needed to understand which data belonged together, what scientists wanted to inspect or compare, which interactions made the structure useful, and what the experiment was meant to prove.

A complete research platform was unnecessary at that stage. We needed enough real data and interaction in one place for scientists to challenge the idea. Working software turned a vague request into specific questions about the data and the research workflow.

4. The work continued outside the screen

Scientists were already using Excel for a peptide workflow. We built a tool that accepted their spreadsheet, let them work with the peptide data in a drag-and-drop dashboard, and exported the CSV their next step expected.

The visualization was only the middle. Upload and export mattered just as much because the tool had to connect to work that already existed. Asking scientists to abandon the surrounding workflow would have made our interface cleaner and their job harder.

Vaccine tracking made the same lesson physical. The software ran on Zebra handhelds, so scan speed, movement, and where someone looked while working mattered. A desktop mockup could validate the layout. It could not validate the job.

I stopped treating the screen as the boundary of the product. Files, devices, physical movement, and the next decision were part of the interface even when none of them appeared in the component tree.

5. Short projects forced me to learn the work

Most of these projects lasted around three months. In two years I moved between clinical data, scientific visualization, VR, web applications, and scanning hardware. There was no single stack I could master once and reuse everywhere.

The durable skill was learning enough of an unfamiliar domain to become useful. I had to follow the existing workflow, find the assumption that could make the idea fail, and build the smallest complete path that put that assumption in front of the user.

Moving quickly did not mean ignoring the environment. The clinical-data prototype used anonymized study data. The peptide tool had to preserve its Excel and CSV boundaries. The vaccine product had to work on the actual handheld device. The shortcut could not remove the condition we were trying to test.

I arrived at MSD thinking a strong engineer turned requirements into code. I left understanding that the requirements were often the result of the engineering work, not its starting point.