Start an onboarding redesign by defining the first useful outcome, not by targeting fewer screens. In a booking app, that outcome might be selecting a suitable service and valid appointment, then understanding the confirmation. Completing a profile or reading every welcome message is not necessarily the useful result. The brief should identify the task, the information it genuinely requires and what can wait without undermining operations.
A shorter journey can hide conditions a person needs to understand. Equally, collecting every preference before showing any value creates work whose purpose is unclear. The design problem is to place decisions at the point they become necessary while keeping refusal, correction and choice understandable.
Establish what is actually going wrong
Collect the current journey map, event definitions if available and relevant support examples, removing unnecessary personal information. Separate people who never attempt the task, people who try but cannot continue and people who decide the service is unsuitable. These are different situations, not a single abandonment problem.
“Registration is too long” is not enough evidence. Ask for concrete observations. Does the app request information someone does not have? Does requesting a verification code look like submitting a booking? Does the selected appointment disappear during registration? Where evidence is missing, label these as hypotheses to investigate rather than confirmed causes.
User Research can observe a defined first-use task. GOV.UK’s guidance recommends tasks that do not reveal the solution to participants. Ask someone to arrange a suitable visit rather than instructing them to press Continue and create an account. Moderated usability testing guidance.
Classify requests before removing them
For every field, permission and decision, record:
- Which operational decision depends on it?
- Is it needed before showing the service, during booking or afterwards?
- Who approves its necessity and explanation?
- What happens when the person refuses or does not know the answer?
- Can the answer be changed later, and where?
The product owner explains operational needs. The client’s appropriate specialists confirm applicable privacy or regulatory requirements. The designer should not invent a justification for collection or remove a necessary consent to improve a funnel number. Device permissions also need an implementation review: an early permission request is not automatically appropriate for every platform or use case.
This classification makes the commercial scope clearer. A wording change, a reordered step and a new guest-account architecture are not equivalent amounts of work. Ask the supplier to distinguish interface changes from dependencies that require engineering or policy decisions.
Worked hypothetical: the first home-service booking
Suppose an app begins with six groups: account creation, contact details, service selection, appointment, address and preferences for future offers. The quantities are illustrative, not an ideal step count or a client case study.
The team defines success first: the person understands the service, appointment and address, reviews them and sees a confirmation that reflects the actual booking status. A prototype allows service exploration before requiring a completed account. Contact details are requested when needed for confirmation, subject to the client’s approved requirements. Offer preferences become a separate choice, not an unexplained obstacle to the primary task.
The prototype does not assume that an appointment is automatically reserved during registration. Engineering must confirm whether the booking system can hold it and under what conditions. If availability changes, the interface must offer a clear route to alternatives rather than imply the original booking succeeded.
Testing includes someone returning after an interruption, someone correcting a contact number and someone declining optional preferences. Observers record where each participant needs help and whether they understand the distinction between choosing an appointment and confirming it. The result is evidence about this journey under the study conditions, not a forecast conversion rate for every visitor.
The team can then decide whether to retain the proposed sequence, revise a confusing transition or investigate a booking-system constraint before further design. It need not redesign unrelated account settings to answer this first-use question.
Specify deliverables that support testing and construction
User Experience Design should provide the normal flow, alternative paths and reasons for each information request. Mobile App Design adds small-screen layouts, interruptions and bilingual states within the agreed scope.
Useful acceptance criteria include:
- Required and optional requests are distinguishable before submission.
- Returning to a previous step does not silently alter the selection.
- Errors explain what can be corrected while retaining valid entries according to the agreed policy.
- Declining a nonessential choice has a documented path rather than a dead end.
- Final confirmation states the actual outcome and next step, not merely that a button was pressed.
These are proposed product outcomes that need implementation verification. Screens and clickable prototypes do not prove that account creation, booking integration or interrupted-session recovery works.
Evaluate without mistaking a cleaner screen for commercial proof
Define the journey’s start and finish. Where the data permits, distinguish repeated attempts from individual users. Track task completion, errors and requests for help alongside safeguards such as invalid bookings. Disclose campaign changes or booking-rule changes that occurred during the observation period.
Conversion Rate Optimisation can choose an evaluation method suited to traffic and measurement quality. That does not automatically mean a split test, and an uplift cannot be promised before examining the evidence. A release may be justified by removing a documented obstacle while the commercial effect remains under observation.
A useful report keeps those conclusions separate: what changed, what was directly verified, what participants understood and what remains unknown about live behavior.
Frequently asked questions
Should account creation disappear entirely?
Not necessarily. Examine why an account is needed, when it is needed and how a person later identifies their booking. Delaying the request or explaining its value may be preferable to removing it.
Is a single-screen journey better?
Not inherently. One screen can become crowded or hide relationships between decisions. Compare understanding and recoverability, not click count alone.
Can we test an unbuilt prototype?
Yes, for sequence and wording, provided the limits are explicit. It cannot establish real verification-code delivery, appointment holding or persistent data recovery.
What if we have no analytics?
Begin with journey inspection and observation of suitable users, then define modest, reliable measurement. Missing data is not permission to invent reasons for abandonment.
Bring the first useful task, the current information requests and their decision owners to the briefing. The project can then remove a defined burden rather than becoming an unbounded app redesign.
Source
- GOV.UK: Using moderated usability testing, reviewed 26 October 2026.
