EPH/QD-01

Quest Diagnostics

Healthcare

Employer Health Platform

Three products into one platform, and the warehouse and equipment system inside it.

Nobody asks the designer to write the spec. Somebody has to.

Information architecture

Warehouse operations

Asset lifecycle

AI in design ops

A picklist queue row showing client, location, shipping destination, event identifiers and a fingerstick collection type, not yet started.

A tablet picklist view listing requisitions, iPad assignment and supplies, each line showing quantity to pull against quantity already picked.

A side sheet for adding a self-collection dried blood spot program, showing a confirmation that the instructions file uploaded successfully.

EPH/QD-01

Role

Senior Product Designer

Scope

Information architecture, three-product consolidation

Designed

Logistics application, seven functional areas, end to end

Team

One fractional designer, directed

Duration

Jan to July 2026, logistics handed off at 5 months

Tools

Figma, Claude Code, Cursor

products into one platform

months, discovery to handoff

Three products, one platform

A tech packs a kit against a picklist, scans it out on an iPad, ships it to a screening event, and three weeks later the equipment comes back. Something is missing, something is out of calibration, and the record of what left the building disagrees with what returned.

That is one of seven functional areas. The platform had three products’ worth of them and no single account of how any of it was supposed to work.

Employer Health Platform was three products. Logistics, internal admin, client admin, each its own entity with its own history. The goal was one roof.

I owned the information architecture for that merge, and I designed logistics end to end, which was the largest of the three and the one nobody wanted to touch.

I knew the requirements were backend-first within the first few weeks. User stories described what the system did rather than what a person was trying to do, and for whole domains no business requirements doc existed at all. That is not hard to spot.

Knowing it and being able to do anything about it are different problems.

What changed was a TPM asking me, three months after a handoff, how a flow was supposed to behave. The answer was in my head and in some Figma frames that had gone stale. At that point it stopped being my complaint and became somebody else’s blocker, which is the only version of a problem you can actually get time to fix.

That is not a system. That is a person, and people leave.

So I wrote the system down. A Master Reference, an index that maps them, and nine feature specs, the last of them backfilled at the end to close the two gaps the index still lists. Not because a platform ought to be documented. Because you cannot merge three products whose logic lives in the heads of the people who built them, and the same rule written three slightly different ways is invisible until somebody sets all three down next to each other.

The Master Reference holds what applies everywhere: UX principles, table-type patterns, a four-part status model, system-enforced business rules, a domain glossary, and a register of known risks. Feature specs handle one domain each. Picklists, shipping and labels, paper mapping, custom picklists, the admin dashboard, EOD inventory, CSR scheduling, the wellness engine.

Two are marked Needs Spec. iPad check-in and equipment management. Defined at domain level, not yet written out.

That is deliberate. A document that says this part is not written yet is more useful than one that pretends otherwise, and the index shows status per row precisely so nobody builds against a gap without knowing it is a gap.

What reconciliation actually looks like: four separate status models, deliberately never mixed. Equipment transactional status is system-controlled, derived from condition, calibration and checkout state. Equipment condition status is user-controlled, the physical assessment. Picklist process status tracks where a supply order sits in the workflow. General record status governs availability across library screens.

The spec says never mix them, in those words, because mixing them is the most common cause of UI confusion in this product.

Three products with three sets of logic, resolving into one platform. The seams are where the same rule existed three times and nobody had reconciled them.

Seven functional areas, end to end

Logistics is the one I took end to end, discovery through engineering handoff, in five months. Seven functional areas: procurement of the order, packing list generation, pick and pack from an iPad, the QC check, label generation, shipping and inventory, and the equipment report with check in and check out.

I was the only designer on it, directing one fractional designer.

The hardest surface was program configuration. One program carries modality-driven panel sets, tube requirements, requisition text, location rules and visibility flags. A form that wants to be a table, inside a sheet that wants to be a page.

That tension produced two decisions I would defend anywhere. Side sheets are 640px, one tier, from the design system token. And content that cannot fit a 640 sheet moves to a modal or a page. Sheets never get widened for one feature.

The second rule exists because widening a sheet is always the easy answer and always the wrong one. Do it twice and you do not have a system, you have six sheet widths and an argument every sprint.

Scheduling broke a different way. A screen where some fields are editable and some are not, and the reason differs by field.

Two independent mechanisms lock a field. Mode-based: program type plus order type, permanent, applies to every role. Date-based: an Editable, Locked, Completed lifecycle computed by comparing today against a linked program’s begin date. It moves on its own.

Two mechanisms, one model, and it has to resolve identically on Edit and on View. Not similarly. Identically. The moment each screen derives its own answer you have two state machines and one of them will drift.

The merge showed itself most plainly in navigation. The Logistics dropdown had twenty-two flat items and no record of why any of them were there. I wrote down what should happen to each and why: straight regroup, fold in because the destination already covers it, or remove. It came out as six groups with a stated reason for every move.

Venipuncture and Fingerstick came out. They are not screens. They are a filter dimension on the Picklist Queue that had been sitting in a menu pretending to be destinations.

Five I could not resolve against anything written: machine status, inventory control, product dispensing, control kit, shelf locations. Those went to the Director of Logistics as a sign-off request, not into the document as my guess.

A designer who guesses at five items and gets four right is worse than one who flags all five. The wrong one ships silently and nobody knows to look for it.

The index. A master reference, nine feature specs and a decisions log, with a status against each so anybody could tell what was written and what was not.

One of seven functional areas. The spec came first and this was built against it.

Seven functional areas, reorganised. Twenty-two ungrouped items became six groups with a stated reason for every move.

Keeping the logic straight across three systems

Every conflict becomes a row. Item, decision, owner. Resolved rows turn into spec text. Open rows get a number and a name and stay visible until somebody closes them. Twenty-seven decisions logged.

The rule governing all of it is one line from a July working session:

Stories-as-written govern the design. Divergences from the BRD get annotated for PO review, not corrected unilaterally.

That sounds like process. It is not. It is the difference between a designer who quietly fixes a contradiction and one who makes it somebody’s problem to decide. I have been the first kind. The second is better.

Owners in the log by role: Product Owner, Technical Program Manager, Leadership, Dev, QA, Design, Product. Every row records one. Where the log names an individual, this page does not reproduce it.

Halfway through, I built a requirements distiller.

Not because the tooling was interesting. Because decisions with the product owner kept coming unstuck, and the same ambiguity kept arriving in a new shape a week later.

The distiller runs a draft against six checks: a PRD drafter, a feature documenter, an end-to-end map, a decision log, acceptance criteria, and a gap finder. A second agent builds documentation from transcripts and the loose stories from PM, then checks my designs back against it to confirm the end-to-end flow still holds.

That is where the twenty-seven came from. The log fills itself from the transcripts rather than from my memory of what we agreed, which matters. A log a designer maintains by hand is a designer being diligent until they get busy.

The gap finder is the one that earned its place. It caught loose logic redundancies, the same rule written three slightly different ways, which is exactly what you get when three products merge and nobody has reconciled them. Finding those is what let logic and patterns get reused across pages instead of rebuilt per screen.

The check back caught things too. On the panels flow it found three requirements the mockup had silently dropped: panel type, panel description, and requisition text lines two and three.

The rule underneath all of it: every field-level fact traces back to source text. Structure is mine to propose. Semantics live in the story. That is not a formality. It is the entire difference between AI making one designer faster and AI making one designer confidently wrong at scale.

The distiller. Six checks on every draft, and the gap finder is the one that earned its place: it caught the same rule written three different ways across merging systems.

What it cost

An executive director took direct ownership of delivery partway through, which usually means a date exists somewhere above him. Scope reset, and a rule came with it: do not redesign screens engineering has already built and QA’d.

My instinct was to fight it. That would have been a mistake and I would have lost.

Redesigning tested screens genuinely does trigger endpoint rework and regression cycles. For internal ops tooling, dev-built CRUD is often fine. And “developers aren’t designers” is an argument about credentials, which leadership in delivery mode does not hear.

So I changed the ask. A ten-minute design-acceptance check before a story is marked done. States, statuses, error handling, navigation rules. Not a gate, an audit. It got accepted because it organised flow instead of adding process.

I also stopped spreading quality evenly. High-blast-radius surfaces, the ones ops staff sit in for hours, got real attention. Low-traffic admin CRUD got let go, loudly. Conceding the small stuff where people can see you do it is what buys you the screens that matter.

Conceding the small stuff visibly is how you win the big stuff.

The handoff was not clean. Backend logic had been accounted for, but at the scale of three separate systems rather than one merged platform. The same rule existing three times is not a gap anybody can see until you try to make it one rule, and that only happens at handoff.

Logistics was handed off and I had moved on to internal admin. I kept meeting the product owner about logistics anyway, regularly, to work through the function and logic of the flows and find solutions.

Not redrawing screens. Explaining a system to the person who owned it now, while my attention was supposed to be somewhere else, because the documentation that would have done that job was the thing I did not finish.

The goal was end-to-end EPH in a form anybody could follow. Flows, process, tech, logic, all of it. I got ten documents in.

Two specs went out marked Needs Spec, both inventory. The iPad check-in flow and equipment management.

I wrote them after the handoff, from the dev review transcript, while I was supposed to be on internal admin. The index still lists them as unwritten, which tells you exactly how well I maintained the index.

Internal admin I did not finish. Client admin I never touched. What that cost was time and coverage, not documentation.

What shipped

Three products have one information architecture. Logistics is designed end to end across seven functional areas, discovery through engineering handoff, in five months, and it went to engineering with a written description of how it behaves.

A platform with no written description now has ten documents, an index that says which to open and when, and a status per document so nobody builds against a gap by accident. Twenty-seven decisions logged, every row with an owner. Eleven open items routed rather than guessed at. Three requirements recovered in a single flow audit. The Logistics dropdown went from twenty-two ungrouped items to six groups with a stated reason for every move.

None of that is a percentage. All of it is checkable: whether the Director signs off on the five flagged items, and whether anyone joining the pod can find an answer without asking me.

Framed for the people funding it: fewer UAT regression cycles, less re-litigating of settled decisions, and shorter ramp for anyone new, because behaviour is written down instead of remembered.

Five months from discovery to handoff was not mine alone. A product owner who kept re-litigating decisions until they were actually settled, a TPM who made the dependencies visible, and engineers who took a spec seriously enough to argue with it. What I contributed was a single account of how the system was supposed to behave, and the discipline to keep it current while everything around it moved.

What I’d do differently: start the decisions log in week one, not week nine. Most of what I did in months two and three was reconstructing intent that would have cost nothing to capture as it happened.

What I wanted to show you

Most portfolio work starts with a brief. This started with three products, a handful of screenshots, and a shrug.

I want to show what the first months look like when the requirements genuinely do not exist and somebody has to go make them.

The distiller is the piece that outlived the project. I built it for one product and it worked. I am building an agnostic version now, for designers generally.

A written answer scales and one that lives in my head does not. That was the argument the whole project ran on, and the only real test of whether I believed it was what happened to the two chapters I had not finished when I handed off.

I wrote them from the transcript, on a project that was already somebody else’s problem. Nobody asked. That is either the most useful thing on this page or the least, depending on what you need from a designer.