Skip to main content

The complete experience lifecycle

UX/UI work is not a straight line from idea to launch. It is a learning loop: a decision reduces uncertainty, an interface makes the hypothesis visible, a test reveals the gap and the team chooses the next improvement.

observe → frame → structure → design → prototype
    ↑                                      ↓
    └──── measure ← ship ← test ←─────────┘

The loop does not mean starting over. It means keeping a trace of what is known, what is uncertain and what evidence comes next.

0. Receive an idea without confusing it with a need​

A request may be a symptom, a business constraint or an imagined solution. Reframe it:

Request: “Add a dashboard.”
Question: which decision should the dashboard make easier?
Person: who makes it, in what context and with which data?
Evidence: how will we know the decision became more reliable?

Write non-goals as well; they protect the scope from growing without evidence.

1. Observe and research​

Choose a method for the uncertainty: interview for reported experience, observation for context, content analysis for words and categories, task test for a journey and existing data for behaviour already in production.

Responsible research requests understandable consent, collects the minimum, protects notes and recordings, keeps counter-examples and explains what is observed versus inferred.

2. Frame the problem​

For [person] in [situation],
the problem is [observable friction],
because [evidence or context].
We will know it improves when [observable criterion].
We are not trying to [non-goal].

A good frame can be corrected. If research invalidates the hypothesis, the project learned something; do not hide the signal to preserve the first idea.

3. Structure information and flow​

Before high fidelity, define intents, categories, labels, entry and exit, required data, main flow, loading, empty, error, denied and resume states. A wireframe checks order and density without distracting with color. If people cannot find the right content in black and white, polish will not repair the taxonomy.

4. Design the interface​

Work from essential to detail: semantic HTML and content order, primary goal and next action, visual hierarchy and reading width, components and tokens, microcopy and errors, states/focus/responsive/motion, then visual polish.

For every decision ask: what should the person recognise, predict, hear back and be able to correct or undo?

5. Prototype at the right level​

A sketch tests structure; a clickable prototype tests order, words and states; a code-near prototype tests responsive behaviour, data and accessibility. Do not add fidelity without a matching question.

6. Test with tasks​

You return after two days. Resume your learning session
and explain how you know which card to open.

Observe first look, first click, hesitation, backtracking, error, help request, rephrasing and completion. Ask what the person was trying to do; do not ask them to grade every screen like a school exercise.

7. Ship with guardrails​

Check data source of truth, loading and recoverable errors, keyboard/focus/labels and contrast, mobile/zoom/long copy, privacy and minimisation, build/tests/logs without sensitive data, deployed version, smoke test and rollback. UX delivery includes copy and messages, not only the JavaScript bundle.

8. Measure and learn after launch​

Choose a small number of measures tied to decisions. Define numerator, denominator, population, period and limits:

Unaided resume rate
= correctly resumed sessions / eligible interrupted sessions
Segment: beginners on mobile
Period: seven days after version 2
If it drops: observe the journey and check the source of truth

A click increase can hide confusion. Watch errors, abandonment, accessibility, trust and support. A metric is a decision signal, not a team reward.

9. Document the decision​

Facts: …
Hypothesis: …
Decision: …
Expected evidence: …
Version: …
Result: …
Next: …

This trace helps a new person understand why the product looks as it does. It describes observable evidence, not private chain of thought.

Running example: resume a session​

Research shows that learners return after an interruption but do not know which card to resume.

  1. Frame: observable friction, beginners, mobile, interrupted session.
  2. Architecture: a “resume” state with last room, current card and explicit action.
  3. Interface: heading, text progress, “Resume” button, recoverable network error and announced status.
  4. Accessibility: native elements, focus to heading, contrast, responsive layout and no hover-only information.
  5. Prototype: test order, label and resume message.
  6. Measure: unaided correct resume over eligible sessions, time and errors.
  7. Iterate: change one variable when the signal lets you isolate it; document the result.

Final workshop​

For one project friction, write the person, context and observed behaviour; problem and non-goal; hypothesis and success criterion; main flow and two alternative states; HTML and primary action; component states and recovery; keyboard, screen reader, mobile, zoom and contrast; prototype and task; metrics with denominators; iteration decision and rollback plan.

If you cannot explain how a design decision will be checked, it is still a preference or hypothesis.

Reliable sources​

The interactive UI/UX path turns each stage into verifiable work. For implementation, see design system components and accessibility rules.