SCIEX OS: Designing for Regulated Precision and Scientific Workflows

Role: Senior Product & UX Designer
Scope: Core Instrument Workflows, Scientific Interaction Architecture, Design System
Domain: Mass Spectrometry & Analytical Science (Regulated 21 CFR Part 11 Environments)

Overview

SCIEX builds analytical mass spectrometers and laboratory software used worldwide in pharmaceutical development, clinical research, and bioanalysis. The operational reality of these laboratories leaves zero margin for ambiguity: an instrument run can take hours, samples are often irreplaceable, and every parameter change must withstand regulatory scrutiny.

As Senior UX/UI Designer on SCIEX OS, I worked to consolidate a fractured ecosystem of legacy instrument applications into a coherent workspace. The core challenge was designing an interface that maintained the rigorous depth domain experts require while eliminating the friction, cognitive fragmentation, and setup errors inherent in legacy lab software.

The Workflow Ecosystem

Mass spectrometry work runs across four tightly coupled stages:

Stage	Focus Area	Key Operational Activities
1. Method & Batch Setup	Software Definition	Defining acquisition parameters, calibration curves, and sample plate mappings in software.
2. Instrument Acquisition	Physical Execution	Executing the physical run through the mass spectrometer and automated autosamplers.
3. Data Processing	Quantitative Analysis	Peak integration, spectrum review, and baseline verification.
4. Documentation	Compliance & Reporting	Reviewing audit logs, electronic signatures, and generating compliant reports.

My focus centered primarily on Experiment Setup and Acquisition Oversight. This is the highest-leverage juncture in the lab: a misconfigured plate position, incorrect polarity switch, or faulty calibration curve during setup spoils physical reagents, wastes instrument runtime, and invalidates downstream datasets.

Key Architectural Challenges

1. Unifying Legacy Paradigms Without Sacrificing Power User Speed

The ecosystem had accumulated years of disparate desktop utilities, each with bespoke window management, divergent table grids, and conflicting mental models. Rather than imposing a consumer-style abstraction over complex analytical controls, I worked to establish architectural consistency:

• Standardized high-density data tables and sample queue builders to preserve quick keyboard navigation and batch data entry.
• Established consistent spatial hierarchies across parameter configuration panels, ensuring critical instrument states (flow rates, source temperatures, voltages) remained visible without occluding sample tracking.
• Designed predictable state indicators and error-handling patterns that surface hardware readiness before an acquisition run is initiated.

2. Integrating Compliance Directly into the Interaction Layer

In pharmaceutical and clinical settings under regulations such as FDA 21 CFR Part 11, data integrity and traceability are operational mandates. In legacy systems, compliance often felt like an obstructive modal dialog bolted onto every minor interaction.

• Contextual Audit Trails: Redesigned the audit logging architecture so parameter alterations, reason codes, and user attribution were captured naturally within the modification flow rather than forcing detached verification steps.
• Granular Role-Based Permissions: Modeled distinct UI states for routine operators versus method developers and QA administrators, ensuring non-privileged users were protected from accidental parameter changes while still having complete visibility into active run statuses.
• Traceable Approvals: Built explicit review gates into batch completion, turning data sign-offs into structured verification checkpoints rather than generic confirmation dialogs.

3. Designing in Collaboration with Scientist-Product Owners

At SCIEX, Product Owners were frequently practicing analytical scientists and mass spectrometry specialists. Designing effectively in this environment required:

• Translating deep scientific requirements (such as MRM transition tables and chromatogram visualization controls) into clear, reusable component specifications.
• Rapidly testing interactive prototypes against real-world sample lists to stress-test dense data views, edge cases, and high-frequency operator tasks.
• Serving as the bridge between scientific stakeholders and software engineering, establishing strict component behavior specs that accounted for real-time instrument data streaming.

Design System and Scalability

To support continuous platform evolution, I helped build and govern the internal design system supporting SCIEX OS:

• High-Density UI Components: Created accessible components specifically tailored to dark and low-light laboratory environments and dense technical datasets.
• Standardized Layout Patterns: Established unified structures for spectrum displays, multi-well plate maps (96-well, 384-well), and run queues.
• Engineering Specifications: Provided teams with detailed interaction specifications, state machines, and tokenized layout guidelines to accelerate front-end delivery and minimize visual regression across releases.

Feature Deep Dive 01: Batch Creation & 96-Well Plate Mapping

Context: In high-throughput bioanalysis, operators configure sample batches (blanks, standards, quality controls, and unknowns) across physical microtiter plates before queuing an unattended overnight mass spec run.

The Problem (Legacy Workflow)

In legacy software, batch definition and physical plate mapping were treated as disconnected steps across detached windows:

• Abstract Coordinate Entry: Technicians manually typed alphanumeric vial/well positions (e.g., Plate1:B04, Plate1:B05) into a tabular text grid.
• Invisible Spatial Errors: Accidental duplicate standards or inverted injection sequences offered zero visual feedback. Errors were only caught hours later when autosamplers collided or produced uninterpretable chromatograms.
• Repetitive Data Entry: Replicating series dilutions or technical replicates required clunky external spreadsheet manipulation (copy-pasting from Excel) with high risk of column misalignment.

The Redesign (SCIEX OS Solution)

We replaced decoupled coordinate entry with an interactive spatial plate layout integrated directly alongside the real-time sample queue:

• Direct Manipulation & Visual Mapping: Operators click-and-drag across interactive 96-well and 384-well grids. Selecting a block of wells automatically generates and numbers the corresponding rows in the acquisition table.
• Contextual Color-Coding by Sample Type: Wells dynamically highlight based on sample role (Calibrator, QC, Unknown, Blank). Operators can verify standard curves and dilution gradients at a glance before initiating the run.
• Proactive Collision & Duplicate Guardrails: Real-time validation flags duplicate well assignments and missing injection volumes before the batch can be submitted to the active queue.

Dimension	Legacy Workflow	SCIEX OS Redesign
Data Input	Manual text typing of plate coordinates	Interactive click-and-drag selection on plate maps
Error Feedback	None; caught post-run during autosampler failure	Real-time visual validation and collision warnings
Setup Time	Several minutes per 96-well plate	Under 60 seconds via spatial drag-fill

Design Impact

• Eliminated pre-run coordinate transcription errors.
• Reduced batch setup time for 96-well plates from several minutes of manual table entry to under 60 seconds with drag-fill patterns.
• Protected physical samples and prevented lost overnight instrument runs caused by autosampler positioning mismatches.

Feature Deep Dive 02: In-Line Audit Trail & Parameter Change Approvals

Context: Under FDA 21 CFR Part 11 and GLP regulations, any modification to acquisition methods, source temperatures, or integration baselines must include an authenticated user ID, timestamp, and audit reason.

The Problem (Legacy Workflow)

The legacy architecture treated regulatory compliance as a punitive, intrusive interruption:

• Modal Bottlenecks: Every single parameter adjustment triggered a modal dialog demanding user re-authentication and a free-text reason code before the change was accepted, grinding routine method development to a halt.
• Low-Fidelity Audit Logs: Free-text inputs led operators to type meaningless filler reasons (e.g., “test”, “asdf”, “update”) just to dismiss modals, degrading forensic value for quality assurance.
• Detached Forensic Review: Inspecting past parameter changes required opening a separate administrative viewer displaying raw database diffs without visual context showing where the change occurred.

The Redesign (SCIEX OS Solution)

We restructured compliance into an in-line verification layer that balances operational momentum with audit integrity:

• Staged Batch Commits: Parameter changes are staged in-context with subtle visual indicators (highlighting modified cells/inputs). Operators review the full diff of intended edits and provide a single, authenticated batch sign-off prior to saving the method.
• Structured Reason Taxonomies: Replaced arbitrary open-text fields with categorized, pre-approved reason codes (“Matrix Optimization”, “Baseline Drift Adjustment”, “Column Maintenance”) paired with optional supporting notes.
• Inline History Inspector: Users and QA auditors inspect the audit trail directly within the method editor via a side panel, viewing side-by-side parameter comparisons with timestamps and digital signatures without leaving their active workspace.

Dimension	Legacy Workflow	SCIEX OS Redesign
Change Capture	Blocking modal dialog on every single input edit	Staged in-context edits with a single batch sign-off
Reason Quality	Unstructured free-text (frequent filler data)	Categorized, pre-approved reason code taxonomy
Audit Inspection	Separate app displaying raw database diffs	Side-panel inspector with inline parameter diffs

Design Impact

• Removed repeated blocking modal dialogs during routine method optimization.
• Significantly improved compliance data quality by standardizing reason codes for regulatory inspection.
• Accelerated internal QA audit reviews by embedding audit provenance directly into the method authoring workspace.

Strategic Impact & Outcomes

• Reduced Configuration Vulnerability: Streamlined batch creation flows and clearer pre-run parameter checks directly minimized setup mistakes prior to physical acquisition.
• Cohesive Multi-Tool Experience: Eliminated jarring context switches across previously siloed applications, establishing a unified layout and navigation schema across the software suite.
• Seamless Regulatory Inspection: Made electronic signatures and audit trail inspection an organic part of the scientist’s daily workflow, reducing the prep time required for quality and compliance audits.
• Engineering Velocity: Centralized UI component libraries and interaction guidelines dramatically reduced cross-team rework and improved implementation fidelity across releases.

Senior Design Takeaway

Designing for scientific instrumentation requires respect for expert mastery. The product designer’s job is not to conceal complexity, but to give professionals total situational awareness, reliable muscle memory, and structural guardrails when the stakes are high.

Redesigning SCIEX OS to support regulated lab workflows with speed, precision, and trust

SCIEX builds analytical instruments and software used in scientific labs, including mass spectrometry and related workflows. The software environment is high stakes by default: results must be accurate, workflows must be repeatable, and every action must be traceable in strictly regulated conditions.

At SCIEX, I worked as a Senior UX/UI Designer on SCIEX OS, helping unify a fragmented ecosystem of legacy applications (similar to my work on the Gig Marketplace platform) into a more coherent platform experience. The goal was not to simplify the science. It was to reduce cognitive load, prevent avoidable mistakes, and make complex work feel predictable, especially when users are moving quickly and compliance is non-negotiable.

The reality of the workflow

A typical lab workflow spans four interconnected stages:

1. Experiment setup in the software
2. Running the experiment through the instrument
3. Analysis of results and processes
4. Reporting and documentation

I designed and improved workflows across these layers, with a major focus on experiment setup, where small UX errors can compound into costly downstream problems. The work required careful attention to clarity, repeatability, and the relationship between multiple systems communicating with each other.

My role

I contributed end-to-end across UX, UI, and system design, including:

• building and evolving a scalable design system across the SCIEX OS ecosystem
• redesigning workflows across setup, run, analysis, and reporting
• bridging design and development with detailed interaction specs and iterative alignment
• conducting research with scientists and lab teams through interviews, shadowing, and usability testing
• prototyping complex flows to validate understanding and reduce ambiguity before implementation

Compliance as a built-in constraint

This was a strictly regulated environment. Compliance was not something added at the end of the flow. It was part of the flow.

The platform needed to support:

• audit trails (traceable, reviewable records of actions and changes)
• permissions and role-based access
• approvals and validation steps
• protocols and coordination across systems

Audit trail functionality was a dedicated part of the software and had its own UX requirements. The experience had to make compliance legible and reliable without slowing scientists down or turning everyday tasks into bureaucratic friction.

Approvals were not abstract. They were driven by real decision-making with stakeholders, especially scientists who also served as product owners inside the organization. That hybrid role shaped the process: the primary users were deeply involved in defining what “correct” looked like, and the work moved through concrete rounds of review and approval to ensure accuracy and regulatory integrity.

Design strategy

Unification without flattening expertise

SCIEX OS was supported by many legacy tools with different patterns and interaction assumptions. I worked to unify navigation, layout, and component behavior so moving between tools felt consistent, while preserving the depth expert users require.

Repeatability and error prevention

In experiment setup especially, the design focus was on making repeatable workflows easier and reducing opportunities for avoidable error. Clear structure, consistent interaction patterns, and predictable system feedback mattered as much as the visual layer.

System-level thinking across interconnected tools

Because multiple systems and protocols were involved, UX decisions had to reflect what was happening beyond a single screen. The work emphasized clarity in states, transitions, and user intent across the workflow rather than isolated UI improvements.

Outcomes

The work contributed to:

• a unified experience across a large suite of legacy applications
• a scalable internal design system that improved consistency and development efficiency
• clearer, more dependable workflows across setup, run, analysis, and reporting
• strong alignment with scientists and QA stakeholders through iterative validation and approval cycles

Why this project matters

In regulated lab environments, usability is not just about comfort or preference. It is a risk and reliability issue. The work on SCIEX OS focused on making complex workflows faster, clearer, and more dependable, while honoring the strict requirements of traceability, permissions, and validation that define the domain.