Skip to content
, Home

Product & Venture Building

UX
for every step, including the ones that fail.

UX covers the core user journeys, the interface designs and a prototype where one is useful. It matters when the scope is agreed but nobody has decided what the user sees at each step, including the steps that fail.

The real question

Who decides what the user sees when a step fails: the design, or whoever writes the code that day.

Step 03 of 06 · Product & Venture Building

The path

From idea
to launch.

Six steps, each feeding the next. This page is one of them.

  1. Product discovery
  2. MVPs
  3. UX (this page)
  4. Implementation
  5. Brand
  6. Launch support

01Questions

The questions
it answers.

  • Which journeys are core, and where does each one end?

    Each core journey runs from a named starting point to an outcome the user can see; the rest are listed as not designed.

  • Is every state of each screen designed?

    Every screen in a core journey has its empty, loading and error states drawn before the build starts.

  • Is a prototype needed, or is the build cheaper?

    A prototype is made only where it answers a named question sooner than working software would.

  • Is the design specific enough to build without guessing?

    Screens come from one component set with named states and recorded decisions, so the build can be checked against the design.

02Pitfalls

Where it
usually breaks.

  • Designs that show only the working path

    Every screen is drawn with the step succeeding. Empty, loading and error states are decided in the build by whoever reaches them, and no two screens fail alike.

  • A prototype built with no question to answer

    The prototype is made because the process has one. It is approved on how it looks, tests no assumption, and delays the build that would have tested one.

  • Sample content standing in for the real thing

    Screens are drawn with tidy sample text and stand-in images. Real content turns out longer, thinner or missing, and the weakest part of the product is found after launch.

  • Screens drawn without an engineer in the room

    A screen shows a figure the system cannot compute or data no service returns. The gap is found in the build, and the screen is redesigned under deadline.

03Approach

How I work
on it.

  1. Write the journeys before the screens

    I start from the agreed scope and write each core journey as steps, with what the system must know or do at each one, checked with your engineers.

  2. Prototype only the open question

    Where a journey rests on an untested assumption, I build the smallest prototype that can test it and state what result would change the design.

  3. Design the states, record the decisions

    I draw the screens from one component set, with their empty, loading and error states, and record each design decision with its reason.

What you leave with

  • The core user journeys written step by step, with the journeys left out of this version listed beside them.
  • Interface designs for those journeys from one component set, with empty, loading and error states and contrast checked.
  • A prototype of the riskiest journey where one is useful, with the question it was built to answer and what it found.
  • A brief for the build: decisions with reasons, a screen list to report against and the events to record at each step.

04Measures

What I
would measure.

Signals to read, not targets to hit: what counts as good enough is your team’s decision.

  • Completion of each core journey, step by step

    A drop at one step points at the screen to change; no movement after a redesign says the screen was not the problem.

  • Design decisions first made in the build

    Where they cluster shows which journeys or states the design left open. A question asked is the healthy case; a silent guess is the cost.

  • Recovery after a failed step

    The share of users who still finish after hitting an error. Where it is low or falling, the error state says what went wrong but not what to do next.

05Evidence

The topic,
in practice.

From my own ventures: the design stage of each product timeline, with the venture’s actual status stated. None records a design or prototype tested with users before the build.

Ventures of my own

  • YoMaxi

    In development, not released: the Design and prototyping stage records a design system, one component set for both themes, that every screen since is built against.

    In development

  • Deal Wizard

    Live as a free public beta: the report was designed to put summary and score first, then the numbers, so that assumptions can be checked.

    Launched

  • City Dreams

    A trading business with a live site: the brief put the full price before any interaction, and the outcome was a documented system with every page drawn in it.

    Launched

Building or launching
something similar?

Tell me about the product, where it is today and what you need next.