QIAGEN: UX for Molecular Testing

My responsibilities, delivered in two tracks

Track A: Improve the operator workflow

Identify the critical tasks and error conditions with the highest risk and frequency.

Redesign the interaction points to prevent avoidable errors, remove ambiguity, and make recovery clearer.

Track B: Build the usability engineering evidence system (operational structure)

Define one way to record issues, rate severity, connect findings to risk controls, and prepare evidence for an audit.

Wireframes and prototypes

Low-fidelity wireframes focused on:

1. Setup sequence: Show the next step, the items it needs, and anything that’s missing.
2. Prevention: Make it clear when a state blocks the run and when it’s only a warning.
3. Recovery: Explain how to resume safely after an interruption.

Interactive prototypes used to validate:

What the prototypes tested

Did operators understand alerts under time pressure?

Could operators recover from an interrupted run without relying on a manual or a senior colleague?

Deliverables

Product design outputs

Operator flow maps covering normal work and failure modes.

Interface behaviour specifications for validation gates, confirmations, and recovery.

Alert-writing guidance and component rules based on severity.

Clickable prototypes for formative testing.

Usability engineering evidence outputs (audit-ready)

Task analysis covering critical tasks, possible errors, and the reason for each severity rating.

Use-related risk traceability linking findings to mitigations and verification.

A formative study plan, test scripts, and success criteria.

A findings log structured for engineering action and compliance traceability.

A summative-readiness checklist showing the evidence available and the gaps still open.

Context and problem statement

Clinical and research labs use QIAsymphony for time-sensitive work that has to follow strict SOPs. A small interaction mistake can lead to a failed run, a delayed result, wasted consumables, or a compliance problem.

Core problems observed in the operator experience

1. Setup errors: Operators could load consumables or reagents incorrectly, select the wrong kit, misplace samples or racks, or miss a pre-check.
2. Late validation: The interface often reported an error after it had happened, when it could have blocked it earlier.
3. Recovery: After a failed or paused run, operators often needed a manual or a senior colleague to work out what to do next.
4. Traceability: Usability findings weren’t recorded consistently enough to connect them quickly to risk controls and design decisions during an audit.

User research: what I did

I observed operators during setup, run execution, interruptions, and cleanup.

I analysed the full workflow, including normal work and edge cases.

I reviewed the interface against usability principles and safety-critical interface conventions.

In formative usability testing, representative operators worked through realistic scenarios, including planned failures.

Key insights that shaped the solution

Operators followed SOPs under time pressure and didn’t explore the interface, so the workflow needed a clear sequence and clear constraints.

A small set of repeated mistakes caused the most costly failures: kit selection, consumable placement, and run confirmation.

An error code on its own didn’t help. Operators needed to know the cause and the exact steps to recover.

It was hard to keep usability evidence traceable as the product changed.

Impact metrics and outcomes

I designed the setup to check operators’ choices before the run started, to reduce setup deviations.

I used consistent patterns and a guided setup, so new operators would need less support.

After a run was interrupted, recovery guidance showed operators a clearer next step.

The evidence structure linked usability findings to risk controls as the work went on, so the team didn’t have to rebuild that link right before an audit.

What the work produced

This was a human-reliability problem in a regulated environment, and I delivered two connected outputs:

An operator workflow designed to prevent common errors and make recovery clearer.

A repeatable evidence structure that can be maintained across releases and reviewed during audits.