Designing a Shared Laboratory Experience

Clinisys builds Clinisys Laboratory Solution (CLS) for laboratories spanning healthcare and scientific testing alike, including anatomic pathology, clinical pathology, genomics, reproductive medicine, environmental testing, pharmaceutical QC, and forensic science. Building each discipline as its own product would have been slower and more fragmented than the business could sustain. The goal instead was one agnostic application: find what's genuinely shared across disciplines, design that once, and reserve discipline-specific design for where the work actually diverges.

That's a research problem before it's a design problem. You can't decide what to share until you know, in detail, what a pathologist, a genomics scientist, an environmental chemist, and a lab director each actually do. I ran weekly SME interviews and workshops over several months and used the findings to build a four-lens analytical framework (who does the work, what the work touches, how the work happens, and what the system needs to support it), which then became the standing interview guide for the rest of the project.

Applying that framework produced a role map spanning sixteen role families, a taxonomy of twelve laboratory domains, fifteen distinct workflow models, and twenty-nine discipline-specific application flows: the concrete, buildable evidence of where CLS could share one experience and where it needed to branch.

CLS needed to support laboratory disciplines that, on the surface, have almost nothing in common. A pathologist reading tissue under a microscope and an environmental chemist testing water samples don't look like the same job. But underneath the domain-specific vocabulary, both are moving material through receipt, processing, testing, interpretation, and reporting, with results that need to be traceable back to their source. The challenge was proving that structural similarity existed, and precisely enough to act on it, before any application design decision could be made with confidence.

With roles and domains mapped, the next question was process: does the work follow the same shape across disciplines, or does it fundamentally diverge? Investigating how each discipline actually operates, their purpose, testing methods, samples, terminology, and major activities, came directly from the same weekly SME interviews and workshops used throughout this research, not from documentation alone. The output was a working library of fifteen laboratory workflow models, each one mapped to the specific specialties it applies to, with its own typical step sequence:

Four of these models (Transplant/Histocompatibility, IVF/Embryology, Pharmaceutical QC, and Research/Biotechnology) sit outside disciplines Clinisys applications currently support. That was a real gap in the original taxonomy, though not one this framework needs to solve: it only matters if Clinisys builds or acquires into those disciplines, and until then it doesn't change how the framework applies to the businesses it serves today.

Comparing those fifteen models stage by stage, across four representative domains, made the shared-versus-specific pattern explicit. The same nineteen stages run through every discipline; what changes is the vocabulary, the artifacts, and where the emphasis sits.

The framework became the team's standing reference for evaluating shared-versus-specific design decisions going forward, and the twenty-nine application flows gave product and engineering a concrete, discipline-by-discipline starting point for translating that model into CLS's interface behavior, rather than relitigating the shared-vs-specific question from scratch for every new laboratory domain the platform takes on.

Shared versus discipline-specific was never decided at the level of a whole workflow. It was decided flow by flow, sometimes step by step within a single flow. Testing and interpretation diverge sharply by discipline, because that's where the domain expertise actually lives. Collection, reporting, and storage converge, because the underlying operations (receive it, document it, release it, keep it) don't actually depend on what "it" is. The framework's job was to make that distinction legible and repeatable, rather than left to case-by-case debate every time a new domain came up.

This project sits apart from CLS's other case studies: the deliverable wasn't a screen or a prototype, it was a way of thinking that made every subsequent screen decision faster and more defensible. Twelve laboratory domains, sixteen role families, and fifteen workflow models don't reduce to a single interface by accident or by intuition. They reduce to one by first proving, rigorously, where they actually agree.

The most important output wasn't any individual artifact above. It was a repeatable four-lens method for asking "is this shared or specific?" and answering it with evidence instead of assumption, a method built to extend to the next laboratory domain CLS takes on, not just the twelve mapped here.