Floi8 — From Fragmented to Unified Execution
Reduced a 9-hour manual lab process to under 5 hours — 1.8× faster, with human error virtually eliminated through end-to-end automation.
Role
End-to-end UX ownership -- User research to handoff
Industry
Biotechnology
Teams
UX Designer, Backend Engineer, SQA, R&D Team.
Year
2026
Context
Formulatrix builds lab instruments used by Roche, MIT, and Biogen — but before any machine ships, it has to pass a validation process. That process ran on 3 disconnected tools, took 9 hours per cycle, and depended entirely on whoever happened to be running it that day.
THE PROBLEM
The operators weren’t slow. The process just wasn’t built for them.
The Goal
Three things had to be true by the end of this project:
Operators shouldn't need to touch three different tools just to run one test
Two operators running the same test should land on the same score, every time
When a test fails, operators should know exactly where it stopped — not start over blind
The Flow
This is the AS-IS flow — before any redesign. Three distinct phases, all manual, all dependent on the operator.
Setup
Files pulled from server, uploaded separately to two tools. No sync.Execution
If dependency pass, test runs. Mid-run failure? Abort — and start over.Post-processing
Logs parsed by hand. Score calculated manually. Every step.
KEY FINDINGS
Before opening any design tool, I conducted user interviews with operators from engineering, production, and SQA — the people who actually ran the process every day. I chose interviews over surveys because the most critical pain points weren't documented anywhere. They existed as workarounds, habits, and unspoken rules that only surfaced through direct conversation.
What I found on the field.
The Intention
Before touching the interface, I needed to align three directions — what users needed, what the business needed, and what the design should protect.
HOW MIGHT WE
With those directions in mind, I turned the key findings into design questions.
How might we reduce the number of tools an operator needs to touch before a test can run?
How might we make scoring consistent — regardless of who runs the test?
How might we give operators a clear view of what happened — so a failed run doesn't mean starting blind?
These questions shaped every decision I made.
Design Decision 1
One Upload, Everything Configured
Operators kept switching between two platforms just to run one liquid validation test, even though the platforms were already connected behind the scenes.
I first tried adding a global upload button, but the team pushed back since the test wasn't universal; so I moved it into a dedicated section built just for the operators who needed it, and the team signed off.
Updated User Flow (TO-BE)
Design decision 2
Instant Results. No Spreadsheet.
After every test, operators had to manually parse a spreadsheet full of data, running it through a formula just to get a score, eating up most of their time right when they needed answers fastest.
So I redesigned the flow to calculate and surface the score automatically the moment a run finishes, cutting the parsing step out of the workflow entirely.
Edge Cases
Most design decisions cover the ideal flow. But in a lab, things go wrong constantly and I wanted operators to never be left guessing when they do. Here's how the system responds to four scenarios that break the happy path.
Protocol Mismatch on Upload
Mismatches used to surface mid-run, wasting the whole test. I moved the check to the upload step instead, so operators catch it before they've lost any time.
Interrupted Test Execution
When a run stops unexpectedly, operators had no way to tell what state things were left in. I made state syncing happen in real time, so they always know exactly where it stopped.
Partial Channel Failure
One failed channel used to fail the whole test, hiding which part actually broke. I redesigned results to show status per channel, so operators know exactly what to fix.
New Test Before Software Update
Blocking new tests until an update landed would've stalled operators completely. I kept manual configuration available instead, guided so it's still safe to use.
Outcome & Impact
One workflow replaced three. What previously took 9 hours of manual coordination now runs in under 5 hours — a 1.8× speed improvement. Scoring that once required manual calculation across spreadsheets now completes automatically at the end of every run, with human error virtually eliminated through full automation.
reflection
The real design challenge wasn't the interface. It was convincing the team that a process they'd lived with for years was worth fixing.
When something is broken long enough, it stops feeling broken. Making that visible was the first thing I designed.
Floi8 — From Fragmented to Unified Execution
Reduced a 9-hour manual lab process to under 5 hours — 1.8× faster, with human error virtually eliminated through end-to-end automation.
Role
End-to-end UX ownership -- User research to handoff
Industry
Biotechnology
Teams
UX Designer, Backend Engineer, SQA, R&D Team.
Year
2026
Context
Formulatrix builds lab instruments used by Roche, MIT, and Biogen — but before any machine ships, it has to pass a validation process. That process ran on 3 disconnected tools, took 9 hours per cycle, and depended entirely on whoever happened to be running it that day.
THE PROBLEM
The operators weren’t slow. The process just wasn’t built for them.
The Goal
Three things had to be true by the end of this project:
Operators shouldn't need to touch three different tools just to run one test
Two operators running the same test should land on the same score, every time
When a test fails, operators should know exactly where it stopped — not start over blind
The Flow
This is the AS-IS flow — before any redesign. Three distinct phases, all manual, all dependent on the operator.
Setup
Files pulled from server, uploaded separately to two tools. No sync.Execution
If dependency pass, test runs. Mid-run failure? Abort — and start over.Post-processing
Logs parsed by hand. Score calculated manually. Every step.
KEY FINDINGS
Before opening any design tool, I conducted user interviews with operators from engineering, production, and SQA — the people who actually ran the process every day. I chose interviews over surveys because the most critical pain points weren't documented anywhere. They existed as workarounds, habits, and unspoken rules that only surfaced through direct conversation.
What I found on the field.
The Intention
Before touching the interface, I needed to align three directions — what users needed, what the business needed, and what the design should protect.
HOW MIGHT WE
With those directions in mind, I turned the key findings into design questions.
How might we reduce the number of tools an operator needs to touch before a test can run?
How might we make scoring consistent — regardless of who runs the test?
How might we give operators a clear view of what happened — so a failed run doesn't mean starting blind?
These questions shaped every decision I made.
Design Decision 1
One Upload, Everything Configured
Operators kept switching between two platforms just to run one liquid validation test, even though the platforms were already connected behind the scenes.
I first tried adding a global upload button, but the team pushed back since the test wasn't universal; so I moved it into a dedicated section built just for the operators who needed it, and the team signed off.
Updated User Flow (TO-BE)
Design decision 2
Instant Results. No Spreadsheet.
After every test, operators had to manually parse a spreadsheet full of data, running it through a formula just to get a score, eating up most of their time right when they needed answers fastest.
So I redesigned the flow to calculate and surface the score automatically the moment a run finishes, cutting the parsing step out of the workflow entirely.
Edge Cases
Most design decisions cover the ideal flow. But in a lab, things go wrong constantly and I wanted operators to never be left guessing when they do. Here's how the system responds to four scenarios that break the happy path.
Protocol Mismatch on Upload
Mismatches used to surface mid-run, wasting the whole test. I moved the check to the upload step instead, so operators catch it before they've lost any time.
Interrupted Test Execution
When a run stops unexpectedly, operators had no way to tell what state things were left in. I made state syncing happen in real time, so they always know exactly where it stopped.Partial Channel Failure
One failed channel used to fail the whole test, hiding which part actually broke. I redesigned results to show status per channel, so operators know exactly what to fix.
New Test Before Software Update
Blocking new tests until an update landed would've stalled operators completely. I kept manual configuration available instead, guided so it's still safe to use.
Outcome & Impact
One workflow replaced three. What previously took 9 hours of manual coordination now runs in under 5 hours — a 1.8× speed improvement. Scoring that once required manual calculation across spreadsheets now completes automatically at the end of every run, with human error virtually eliminated through full automation.
reflection
The real design challenge wasn't the interface. It was convincing the team that a process they'd lived with for years was worth fixing.
When something is broken long enough, it stops feeling broken. Making that visible was the first thing I designed.