A restaurant's pay-at-table tablet runs a four-step checkout form — split, tip, payment, receipt — and guests abandon it midway; how would you redesign its steps, progress and back navigation?
answer
- find the step where people leave
- one topic per step
- named steps, 'Step 2 of 4'
- back keeps every answer
- review before the charge
basics
~20 sMeasure where guests leave, give each step one clear topic, show named progress in text, keep every answer on back navigation, never ask for the same data twice, and add a review step before the card is charged.
solid answer
~50 sI start with **where** people leave — per-step drop-off plus a few observed sessions — because quitting at the split step and quitting at payment have different causes. Then the pattern: each step has one topic and a heading; the progress indicator names the steps and says 'Step 2 of 4: Tip' in text, not by colour alone; completed steps can be revisited, future ones are not skipped into. **Back** — the on-screen control and the platform's own back gesture or history — returns to the previous step with every answer intact. Nothing entered earlier in the flow is asked again, which WCAG 2.2 3.3.7 Redundant Entry (Level A) requires. Each step validates its own fields before moving on. Because the flow charges a card, a **review step** lets guests check and correct before paying, one of the options WCAG 2.2 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) accepts.
go deeper
Recall the parts of a multi-step form: named steps, 'Step N of M' progress in text, a back control that keeps answers, and a review before any payment.
Explain step boundaries by topic and dependency, per-step validation, and how editing from the review returns the user to the review.
Start from drop-off data and observed sessions, then map fixes to causes, and cite 3.3.7, 3.3.4 and 2.2.1 where they bind a payment flow on a shared device.
Weigh multi-step against a single grouped page for each flow, and decide which step behaviours the system bakes in versus leaves to product teams.
## Diagnose before redesigning A **multi-step form** splits one task into a sequence of screens, each with a subset of the fields, and usually shows a **progress indicator** of where the user is in the sequence. When people abandon one, the first job is to find out where and why: - **Per-step drop-off** from product analytics shows which step loses people. - **Observed sessions** — even five guests at real tables — show why: a confusing split, a tip screen that feels coercive, a payment error that wipes the form. - **Back-navigation traces** show whether people go back and then give up, which usually means going back lost their answers. Only then does the redesign target the actual failure. ## Designing the step boundaries - **One topic per step.** Split the bill; choose a tip; pay; get a receipt. A step that mixes topics makes its heading a lie. - **Not too fine.** Every step adds a transition and a moment to quit. Splitting a three-field form over three screens adds friction without adding clarity. - **Dependencies flow forward.** The tip is calculated on the split amount, so split comes first; nothing on an earlier step should depend on a later one. - **Validate at the boundary.** Each step checks its own fields before the next opens, and shows its errors in the form's normal error pattern, so no guest reaches payment with a broken split. - **Irreversible actions last.** The card is charged only after the guest has seen everything they are paying for. ## The progress indicator | State | Visual treatment | What must also be true | |---|---|---| | Completed | Check mark and step name | Can be tapped to revisit, answers intact | | Current | Emphasised marker and step name | Text says 'Step 2 of 4: Tip', and the current state is exposed to assistive technology | | Upcoming | Muted marker and step name | Not selectable until earlier steps are valid | Colour may distinguish the states, but never alone — WCAG 2.2 **1.4.1 Use of Color** (Level A). Naming the steps tells guests what is coming, which is what reduces the fear of a surprise charge. ## Back, forward and editing 1. The on-screen **Back** control returns to the previous step with every answer preserved. 2. The **platform's own back** — a web history entry or a native navigation stack — does the same thing, not exit the checkout. Treat each step as a real destination. 3. A **review step** before payment lists every answer grouped by step, each group with an edit control. 4. Editing opens that step with answers intact, and confirming it returns the guest to the review rather than through every later step again. 5. When an edit changes a dependency — a different split — later values such as the tip and total are recalculated and flagged on the review before payment. ## The standards that apply | WCAG 2.2 criterion | Level | What it means for this checkout | |---|---|---| | 3.3.7 Redundant Entry | A (new in 2.2) | Information already entered or provided in the same process is auto-populated or available to select — an email address typed on the payment step for the receipt is not asked for again on the receipt step. Exceptions: re-entry is essential, needed for security, or the earlier value is no longer valid. | | 3.3.4 Error Prevention (Legal, Financial, Data) | AA | A financial transaction must be reversible, checked for input errors with a chance to correct, **or** confirmable through a mechanism for reviewing and correcting before finalising. The review step is the usual way. | | 2.2.1 Timing Adjustable | A | A shared tablet that times out between guests must, for most time limits, let the user turn off, adjust or extend it — typically a warning with a simple action to extend. | | 1.4.1 Use of Color | A | The current step is not shown by colour alone. | ## Putting it together for the pay-at-table flow Suppose the data shows guests quit on the tip step and after payment errors. The redesign: a named four-step indicator with 'Step 2 of 4: Tip'; the tip step offering presets and a clear no-tip option, with the amount each preset adds; payment errors shown inline without clearing the split or tip; a review step before charging; and back navigation, from any control, that keeps every answer. ## When not to split at all Multi-step is a tool for long or branching tasks and for putting an irreversible action last. A short form with one topic is better as a single page with grouped sections: fewer transitions, everything visible, and no progress indicator to design.
- Should guests be able to jump ahead by tapping a future step in the progress indicator?Usually not: later steps depend on earlier answers, such as a tip calculated on the split amount. Let completed steps be revisited and make upcoming ones visibly unavailable. If the steps are genuinely independent, the task may not need to be sequential at all.
- The tablet is shared and must time out between guests; how do you reconcile that with a long checkout?Warn before the time limit expires and let the guest extend it with a simple action, which WCAG 2.2 2.2.1 Timing Adjustable (Level A) accepts for most time limits. When it does expire, clear the guest's payment and personal data, and set the limit generously enough for a slow, careful guest.
- What should happen to the review step when the guest changes the split after choosing a tip?Recalculate everything that depends on the split — the tip amount if it was a percentage, and the total — and flag the changed values on the review before payment, so the guest never pays an amount they have not seen.
saying these in an interview costs you the question
- More steps with fewer fields always make a form easier to finish.
- A coloured dot per step is enough to show where the user is.
- Going back can reset the step, since the guest will fill it in again.
- Asking for the email again on the receipt step is harmless double-checking.
- An emailed receipt after the charge counts as the review step.
- The platform's back gesture may exit the checkout; only the on-screen back matters.