Onboarding as a product surface

NorthPay is a concept fintech onboarding flow, from account type selection through KYC verification and first-use setup.

Every field in an onboarding form sits between the user and the product. The sequence those fields appear in is a design decision, not a compliance requirement.

Onboarding is the point where first impressions, regulatory constraints, and conversion rates converge on the same sequence of screens.

Financial products must collect sensitive information before users see any value. That makes onboarding the most fragile part of the flow. People are creating an account, sharing personal details, and waiting on verification without knowing yet whether any of it is worth their time.

Long forms, unclear requirements, and weak feedback stall activation before the product is even used. Every field in the sequence is required by regulation. How that sequence is presented is a design decision.

The challenge was structural: how to collect everything compliance requires while keeping users oriented at every step. A visible endpoint and a fixed question-per-screen pattern address both.

The onboarding experience is split into a public entry point and a gated product flow. Within the product, a simple sequence guides users from account type to verification, with clear branching for personal vs. business accounts.

Account type is the first decision. Every field that follows depends on it. Making it the first screen removes the worst failure mode: mid-form type switching that wipes all entered data.

The flow is three phases: account selection, identity collection, and verification. All three are visible in the stepper from step one, so no phase is a surprise when it opens.

Low-fidelity wireframes locked in structure and sequence before visual decisions were made. A persistent stepper shows users where they are and what remains. Grouped fields keep each screen focused on a single step.

One question per screen is slower to build and faster to complete. The perceived complexity drops when each screen has one job and makes it obvious.

The interactions that matter in this flow are the ones that handle failure: inline field errors, a pending verification state, and a stepper that never hides the remaining steps.

Verification confirms the account. Users land on a setup checklist that replaces an empty dashboard with a clear next action, without front-loading every option.

I didn't design for multi-session completion. The persistent stepper works for a single visit. In real fintech, KYC can span days: manual document review, identity verification queues, pending business registration checks. The flow needs a save-and-resume state I didn't address.

Compliance constraints were simulated. For a concept, I controlled the field sequence entirely. In a real engagement, AML and KYC regulations would dictate which fields appear together and in what order. I'd want to map the legal requirements before finalizing the one-question-per-screen pattern.

The rejected approach deserved a better counterargument. My wireframe of the "account type plus form fields on one screen" was obviously bad by design. An honest validation would build that version well, not as a strawman, and compare usability scores against the one-question approach.