How London fintech teams can scope mobile onboarding

A London fintech team should scope an onboarding redesign as one mobile task that may cross screens, devices, services, and time. Include interruptions, document capture, verification handoffs, and return states in the brief. A sequence of attractive forms will not fix a journey that loses the person when the phone switches to a camera, browser, or review state.

This guide focuses on how the product experience carries a person through onboarding. It does not set identity-check policy or give legal advice. The product owner and relevant specialists decide which checks apply; design makes the approved steps understandable and recoverable.

Where does the mobile journey really begin and end?

Start with the user’s goal, then map the complete route to a usable account state. Record what happens before the first form, what information is requested, which steps depend on another service, and what the user sees when the process pauses.

A practical map might track:

• The entry point and explanation of what the person needs to complete.
• Each input, permission request, and document or image capture.
• Transitions to a camera, browser, identity provider, or other verification service.
• Loading, review, retry, rejection, and continuation states.
• The point where the person can use the product, plus any remaining action.

Mark the responsible system and product owner at every handoff. If the app cannot know why an external check is pending, do not design a precise promise about its duration. Show what is known, what the person can do, and how they can return to the task.

What happens when a person is interrupted?

Include calls, messages, weak connectivity, low battery, and the need to put the phone down among the conditions to test with the product’s users. Treat them as scenarios to investigate, not assumptions about every London customer.

For each step, ask what survives an interruption. If a person leaves during document capture, should the app retain earlier fields? Can they safely restart only the failed capture? Does a verification handoff return to the same account and task? What state appears after a timeout or app restart?

Write the answers into a state table before redrawing screens:

These are prompts for investigation, not claims that every product supports each behavior. Confirm technical and operational constraints with the teams responsible.

How should document capture and errors work?

Document capture needs clear preparation, a visible frame or placement cue, and feedback that explains why an image cannot be used. Keep entered information when a retry is possible, and tell the user whether the image uploaded or still needs attention. Test with devices and conditions relevant to the intended users, including accessibility needs.

The W3C Forms Tutorial recommends concise feedback, errors located near the relevant controls, and instructions that explain how to correct an error. Apply that guidance to capture and form states, then test it with the supported assistive technologies and devices. See W3C guidance on form notifications.

Do not rely on color or an icon alone to distinguish success from failure. After submission, make the result clear, preserve correctable information, and give a next step. These are usability choices; they do not replace review of the product’s approved requirements.

How should verification handoffs be designed?

Make the boundary visible before a person leaves the main flow. Explain that another step or service will open, what information they may need, and how they will know they have returned. On return, restore the relevant task state and show whether the check is complete, still pending, or needs attention.

Draw at least three paths: successful return, interrupted or abandoned handoff, and an outcome that needs the user to act. Confirm the meaning of each status with the product owner and the system that supplies it. Avoid using a generic “Something went wrong” message when the system can provide a clear recovery action.

How can a London team test the journey?

Recruit people who match the product’s actual or likely users and define criteria around the research question, not a broad location label. If London is the launch market, the team can recruit within its intended service area and include relevant account types, devices, and access needs. GOV.UK’s research guidance recommends recruiting actual or likely users and reviewing criteria against the questions the team needs to answer. Read the participant-selection guidance.

Test the end-to-end task on a phone, including the camera switch and external handoff. Ask participants to resume after a deliberate pause, explain what they think each status means, and show what they would do after an error. In hybrid sessions, assign one person to moderate and another to capture state changes so observers do not steer the participant.

Keep the brief grounded in product evidence: current completion and failure events where available, support themes, system boundaries, and the exact decision the redesign should unlock. The fintech product design overview gives broader context; for agency selection and evidence questions, see the London fintech agency guide.