ACCEPTED
The journey
What the user does, in what order, and what the product shows while it happens — including empty, loading, and failure states.
// PROCESSES · CASEFILE 01
Product Experience.
Product Experience is the method a user-facing build goes through before it is called done: work out what the user actually does, choose one interface direction deliberately, write down the rules it gets built to, then judge the real running product instead of the mockup. Not every job needs the full route.
APPLIES WHEN
A new user-facing product, a redesign that changes how it works, or a launch-critical surface.
WHY IT EXISTS
Building is an expensive place to discover that the journey or the interface direction was wrong.
AUTHORITY
AI may assist throughout. The decisions that matter, including whether to release, are made at explicit human gates.
mounted record: product-experience
01 / OVERVIEW
What Product Experience decides, and in what order.
Four layers stack up, and each one narrows what the next is allowed to do. The first two are accepted — this is what we are building. The third is authorized — you may now build it. The fourth is not a decision at all: it is the running product, which is where the first three get tested.
THE LOAD-BEARING IDEA
The next stage should never have to guess what the previous stage meant.
Decisions about how a product works are cheap while they are still words and expensive once they are code. The order exists so the expensive part inherits settled answers instead of unresolved ones.
A finished-looking screen proves very little on its own. The question is which journey, which chosen direction, and which agreed rules it was built to satisfy.
ACCEPTED
The chosen direction
One interface answer, selected over alternatives that differ in real ways, with the reasons the others were rejected.
AUTHORIZED
The build rules
Components, states, responsive behaviour, accessibility and content rules — specific enough to guide the build and review the result.
INSPECTED
The running product
The real thing, running with realistic content, judged against every decision stacked above it.
02 / ROUTE MAP
How Product Experience moves from scope to acceptance.
Read left to right. Each box is a phase, each one ends in a decision a person makes, and the diamond near the start is where the job is matched to a route it actually needs. The red path is what happens when a later phase exposes an earlier mistake. The dashed box at the end sits outside this process entirely.
- 01
Context
Work out who it is for, what it has to do, and which route the job actually needs.
Human · accept the context and the route - 02
Journey
Map what the user does step by step, including the empty, slow and failed moments.
Human · accept the journey - 03
Directions
Compare interface options that differ in real ways, not in colour and spacing.
Human · select one, request another, or return - 04
Build rules
Turn the chosen direction into rules specific enough to build against and review against.
Human · authorize the build - 05
Running surface
Build the smallest real version of the main path and inspect the actual product, not the mockup.
Human · accept, or return to an earlier phase - 06
Final experience
Stress it with difficult content, narrow screens, failures, and keyboard use.
Human · accept, correct, or reject
03 / CONTROLS
What keeps the process from becoming ceremony.
These controls keep common failures from carrying forward into later work. Each one exists because of a specific failure that is easy to recognise once you have hit it.
- BOUND
Choose the smallest route that still preserves the decision.
Process weight follows risk. A clerical change should not inherit the same ceremony as a new product journey.
- STRESS
Design against the content that will actually arrive.
Empty, slow, failed, overlong and half-finished states are decided alongside the journey. Placeholder content hides exactly the problems worth finding early.
- COMPARE
Explore answers, not cosmetic variations.
Comparing directions is only useful when they make materially different choices about hierarchy, interaction, or what the product is pretending to be. The same layout in three palettes is not a choice.
- RETURN
Send the defect back to where it originated.
Do not keep polishing implementation when the real failure is the journey, the direction, or the rules the build was given.
04 / EVIDENCE
What the process leaves behind.
A useful workflow leaves more than a finished screen. Each accepted decision becomes evidence the next stage can work from: what was decided, what the build was meant to satisfy, what changed when something failed, and what can be reused later.
- DECISION TRACE
Know why the product ended up here.
Accepted context, journey, direction, build rules, and final decisions leave a trace of what changed and why. Later work can follow that chain instead of reconstructing intent from memory.
- SHARED BUILD REFERENCE
Give the next stage something concrete to work against.
The accepted journey, states, direction, and build rules become reference points for implementation and review. They make it easier to tell whether the running product matches what was agreed.
- TRACEABLE DEBUGGING TRAIL
Find where the problem actually entered.
When a later stage exposes a defect, the evidence helps separate a journey problem from a direction problem, a build-rule problem, or an implementation problem. Correction can return to the layer that caused it.
- REUSABLE CONTEXT
Let useful decisions survive the run.
The record can inform later hardening, revisions, related workflows, and future product work without forcing anyone to rediscover the same reasoning. Reuse is selective: the evidence is context, not an automatic instruction.
05 / LIMITS
The process protects decisions. It does not guarantee outcomes.
The workflow improves how decisions are made and checked. It cannot guarantee the product will succeed.
- LIMIT 01
No universal route.
Plenty of work is legitimately small enough for a lighter route or an inherited system. Running the full route on it would be theatre.
- LIMIT 02
Acceptance covers one exact build.
What was accepted is the specific version that was inspected, with the content it was inspected with. A later build inherits nothing automatically.
- LIMIT 03
Process cannot supply a missing capability.
A well-ordered set of decisions will not compensate for a product that cannot do the thing the user came for. It can expose that earlier, which is not the same as fixing it.
- LIMIT 04
No market claim.
A coherent, accepted experience can still fail to find anyone who wants it.