CLS Healthcare · Clinical Microbiology · Case study

Clinical Microbiology Setup & Results

Building new Clinical Microbiology functionality into CLS: one traceable, task-based workflow for a fragmented, multi-day laboratory process, from specimen setup through organism workup and resulting.

01 · Executive summary

Fitting a cyclical, multi-day process into a system built for predictable tasks.

Bringing Clinical Microbiology into CLS meant fitting a cyclical, time-dependent healthcare workflow into a task-based system originally designed for Environmental laboratories. This research ran in parallel with Clinical Pathology Results Review, allowing this project to concentrate on what was genuinely different about Microbiology.

Research with five client laboratories revealed that workflow continuity depended heavily on memory and physical organization. I translated those findings into a service blueprint, cyclical workflow model, and information architecture, then designed and evaluated the proposed workflow through two rounds of moderated testing. The resulting design connected previously fragmented stages of work and shifted responsibility for tracking follow-up work from the user to the system.

The workflow shipped, and client response grew more positive over successive monthly demonstrations.

02 · Approach

Understand the current state, model the system, then test and measure the trade-offs.

Contributions

Attended an ongoing Client Advisory Group of five client laboratory organizations
Conducted three current-state workflow interviews
Created the service blueprint, cyclical workflow model, and information architecture
Translated findings into workflow principles and interface requirements
Conducted two rounds of moderated usability testing
Analyzed interaction cost across the current and proposed workflows

Method

I combined qualitative research, workflow modeling, information architecture, concept evaluation, and interaction-cost analysis. The work progressed from understanding the current state to defining a system model, testing that model first as wireframes and then as an interactive prototype, and measuring the trade-offs raised during evaluation.

03 · Context & problem

Newly built functionality, not a redesign, running on a platform built for a different kind of work.

Clinisys was extending a laboratory platform originally designed for Environmental workflows to support Clinical Microbiology. That created a structural mismatch: the platform assumed predictable, task-based progression, while microbiology work repeatedly cycles through incubation, observation, organism workup, and follow-up testing over several days. CLS had a Microbiology workflow built for scientific laboratories, but no dedicated Clinical Microbiology workflow: clinical work was run through the same task-based screens built for Environmental laboratories, so setup, task execution, and resulting were distributed across multiple generic screens, and laboratory staff relied on memory, physical organization, and manual tracking to determine what needed attention next.

Constraints

Existing CLS platform architecture
Established task-based LMS framework
Support for both Clinical and Environmental laboratories
Traceability and audit requirements

04 · Research: Client Advisory Group

The underlying system architecture didn't reflect how the work actually progressed.

Key discovery

The Client Advisory Group made clear that the problem wasn't individual screens. The underlying system architecture didn't reflect how Microbiology work progressed over time. View the summary ↗ · Read the full report ↗

Cyclical progression

Results determine the next action, so microbiology cannot be represented as a fixed sequence. The system needed to generate and resurface work throughout repeated incubation and observation cycles.

"I have to come back to this later. There's nothing in the system that tells me when." Clinical Microbiology Lab Technologist

Fragmented visibility

Staff moved between screens and used manual tracking to remember pending work. The new workflow needed to show active, completed, and upcoming work in one place.

"I'm going back and forth between screens just to finish one observation." Clinical Microbiology Lab Technician

Context and traceability

Organism work could not be separated from its originating specimen and media. These relationships needed to remain visible throughout workup and resulting.

"Entering the data is easy. It's finding it again that's the problem." Sr. Clinical Microbiology Lab Scientist

05 · Research: Service blueprint

A gap between the workflow the product team assumed and the one laboratories actually followed.

The Client Advisory Group revealed a gap between the workflow the product team assumed and the process laboratories actually followed. To investigate it, I conducted three 60-minute interviews with microbiology laboratories and mapped the current state across roles, system interactions, and backstage dependencies. The blueprint showed that workflow continuity depended heavily on memory and physical organization: important information moved between roles and screens without a reliable system-level representation of what was pending. This established workflow visibility, not data entry, as the central design problem. View the blueprint ↗ · Read the full report ↗

Key discovery

Internal subject-matter experts brought valuable microbiology experience, but some assumptions reflected earlier laboratory practices. Client laboratories had since developed local workarounds that were not represented in the platform. Direct research helped the team distinguish historical expectations from current operational behavior.

06 · Synthesis: Workflow model & information architecture

One connected system, not two documents.

Research established that the solution needed two connected structures: a cyclical workflow model describing how work progresses, and an information architecture preserving the relationships among specimens, media, tasks, organisms, and workup activities. Tasks became the system's primary unit of work. Condition codes generated subsequent tasks based on observations and results, allowing work to move through repeated incubation and follow-up cycles until a final report is ready for release. View the workflow model ↗ · Read the full report ↗ · View the information architecture model ↗ · Read the full report ↗

1 · SETUP

A received specimen initiates the workflow. The user checks in the specimen, the system generates the required plates, and the user places them in incubation.

2 · INCUBATION

The system is configured with the number and frequency of reads, performs scheduled reads, and notifies the user when one is due. Incubation and reads repeat until results are released.

3 · TASKS

The system guides the user through organism identification, workup, plate reading, and condition-code entry, assigning the next task automatically after each cycle.

4 · RESULTS

The system compiles all data, results, and interpretations. Results can be reviewed by authorized users before being approved, released, and made available as a final report.

Task orchestration rules

Only one task can be active for a media at any given time. Completed tasks move to Released and remain in task history. Tasks inform users what needs to be performed and when (follow-up tasks may be timed at 24, 48, or 72 hours), and results cannot be reviewed or released until all required workup tasks are released.

07 · Design principles

Each principle traces back to a specific finding from research.

1. Preserve context across the workflow

Keep specimen, media, organism, and task information together so users can move between activities without reconstructing context.

2. Let the system track what comes next

Generate time- and condition-driven follow-up tasks so pending work no longer depends on memory or physical tracking.

3. Support repetition without breaking continuity

Allow plating, incubation, observations, organism workup, and resulting to repeat while remaining part of one traceable workflow.

08 · Wireframe & validation

Low-fidelity testing evaluated the workflow structure, information architecture, and terminology.

I tested low-fidelity wireframes with five Clinical Microbiology professionals in individual, 60-minute remote sessions. Because the designs were not yet interactive, the sessions evaluated workflow structure, information architecture, and terminology rather than task-completion performance. Testing supported the overall direction but exposed five issues that needed to be addressed before prototype validation. Read the full report ↗

Wireframe of the worklist table with batch rule tiles — Worklist

Wireframe of the Manage Tile panel for batch rule query parameters — Manage tile

Wireframe of the Batch Resulting panel with barcode scan field — Batch resulting

Wireframe of the Bin panel for scanning a bin and aliquots — Bin

Wireframe of the materials tree and task details — Materials & tasks

Terminology confusion

Finding: "Backlog," "aliquot," and "matrix" were unfamiliar or ambiguous.

Decision: Replace them with microbiology-specific language such as "pending list," "order ID," and "plates," or support configurable terminology.

Role-specific workflows

Finding: Receiving and setup tasks are distinct and handled by different roles with minimal overlap.

Decision: Tailor workflows to align with the distinct tasks handled by receiving, setup, and result-entry roles.

Missing workflows

Finding: Setup time tracking, no-growth reporting, and mixed flora result handling were missing from the design.

Decision: Add functionality for setup time tracking, no-growth reporting, and mixed flora result handling.

Plate management

Finding: Participants preferred preconfigured plates over manually adding or deleting them, but wanted permissions where that flexibility exists.

Decision: Develop permissions to control adding or deleting plates and direct exams, keeping preconfigured workflows the default.

Data presentation

Finding: The material tree differed radically from participants' existing systems, and order comments, special requests, modifiers, and pending work outside the current encounter were not visible on the main screen.

Decision: Incorporate the Clinisys Design System for visual consistency, and surface comments, requests, modifiers, and a unified pending-work view directly on the main screen.

09 · High-fidelity prototype & validation

What changed between rounds, and what didn't.

The second round evaluated an interactive prototype with five Clinical Microbiology professionals using representative scenarios from backlog prioritization through resulting. The underlying workflow model continued to perform well. Participants valued personalized worklists and improved access to specimen context, and the unfamiliar material hierarchy became understandable with use. However, visual refinement had not reduced the number of steps as much as participants expected, and the primary concern shifted from structural usability to interaction efficiency. Read the full report ↗

Processing screen showing batch tiles for Incubation, Gram Stain, and other tasks — System-level view

Sample processing screen showing the materials tree for a urine specimen — Drill-in view

Supported: task-based workflow & personalized worklists

The task-based model supported representative Clinical Microbiology activities end to end, and participants consistently valued organizing and prioritizing their own work from the backlog rather than working strictly in system-assigned order.

Improved with use: material-based navigation

Unfamiliar at first, the material hierarchy became easier to understand as participants worked through representative scenarios, suggesting onboarding could address some of the initial confusion.

Still unresolved: interaction cost

Participants expected fewer steps than the prototype required. The interaction-cost analysis below tests that concern directly.

10 · Consumption map & interaction cost

Testing the interaction-cost concern objectively, rather than defending the design on intuition.

Participants felt that the new workflow required more effort than the current system. I tested that concern by mapping representative workflows across both experiences and comparing clicks, screens, modals, scrolls, and data fields. Read the full report ↗

TaskClicks / screensDetail

Search (either workflow)2 clicks · 1 screenUnchanged between systems

Enter/update organism & workup (today)8 clicks · 1 screen5 data fields, no modals

Launch & complete a worksheet (new workflow)13 clicks · 3 screens2 modals, 13 data fields

Key discovery

The map showed the same finding twice: two current-state paths through "enter organism & workup" (one starting clean, one starting by deleting an existing test code first) both converged on the same 8 clicks, 1 screen, 5 data fields. The new workflow's added cost wasn't scattered friction across the whole experience; it was concentrated in one new step doing new work, launching and importing a worksheet, that supported task orchestration, incubation management, and specimen progression the current system didn't provide.

Interaction count wasn't the whole measure

The new workflow introduced additional interactions, but those steps supported task generation, incubation management, specimen progression, and workflow visibility that the current system left to user memory. The goal became reducing unnecessary effort without removing the context and orchestration the new workflow provided.

Inline the worksheet modals

Investigate whether the worksheet modals can become inline interactions instead of blocking dialogs.

Reduce effort, not context

Preserve the additional context the new workflow surfaces while reducing the effort required to scan and enter it.

These recommendations were carried into the shipped workflow.

11 · Outcome

A deliberate trade-off, made visible rather than defended on intuition.

The clearest evidence of impact

The new workflow was developed and shipped. Because it differed substantially from the previous system, clients initially needed time to understand the task-based model and material hierarchy, but reception became more positive over successive monthly demonstrations, with clients increasingly asking when the workflow would become available to their laboratories.

Next case studyKeyboard Accessibility & Interaction Strategy →