EPH/QD-01

Quest Diagnostics

Healthcare

Employer Health Platform

Three products merging into one, and the logistics system inside it.

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

Service design

Design ops

AI-augmented

Spec systems

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

The merge

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, eight feature specs, and an index that maps them. 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.

The work

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.

How the work actually moved

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. Forty-one 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. No row names a person. That is deliberate. A decision log that names individuals turns into a record of who was wrong, and people stop putting things in 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 forty-one 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.

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 of them are still marked Needs Spec, and what stopped me was not disagreement. Shipping and picklists were blocking active development and iPad check-in and equipment management were not yet.

Internal admin I did not finish. Client admin I never touched. A system that is eighty percent written and honest about the twenty beats one that is complete and three months late, and I would still rather have finished it.

Outcome

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. Forty-one decisions logged, every row with an owner. Ten 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, whether the two Needs Spec documents get written, 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.

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. Including the part where you ship the document with two chapters missing, because the alternative is shipping nothing.

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.

ケビン・チャップマン

No. 26 / Lot 01 / SS26

SUBJECT 26 // K.Chapman

K.Chapman

// K.Chapman

Open / Lead roles

Remote / SoCal