← Practice Lab

PRACTICE PROJECT / PROJECT FROM SCRATCH

Digital banking onboarding

Investigate why applicants leave before account creation, then define a safe, measurable improvement.

IntermediateFictional business scenarioReference approach included
Your task

Read the brief and work through the deliverables before opening the reference approach. Your notes stay in this browser only.

Company context

Northbank is a fictional retail bank with mobile account opening. Identity checks use an external provider; support and compliance teams review exceptions.

Business problem

35% of applicants abandon digital onboarding before account creation. A sponsor asks for a new progress bar, but no root cause has been established.

Stakeholders

  • Applicants
  • Product Owner
  • Operations
  • Compliance and fraud
  • UX
  • Engineering
  • Identity provider

Stakeholder interviews

  • Support: “Customers often call after upload retries, but we cannot tell what they saw.”
  • Compliance: “An expired session must never restore unverified identity data.”
  • Engineering: “Provider timeout events are mixed with customer cancellations.”

Existing process

  • Start application and provide details
  • Accept consent and upload ID
  • External provider verifies identity
  • Create account and activate access

Business rules

  • Applicants must explicitly consent before verification.
  • Expired identity sessions require a new verification attempt.
  • An applicant must not create duplicate active accounts.

Customer feedback

  • “I uploaded my ID twice and still got sent back.”
  • “I did not know whether I could finish later.”

Sample data

  • 35% abandon before account creation
  • Upload step has the highest visible drop-off
  • A single applicant can generate multiple sessions

Constraints

  • Do not weaken KYC controls
  • Protect ID data
  • Release in a limited cohort first

System / API information

The identity API returns a provider session ID, status and error code. Callbacks can be delayed; timeout is currently shown as a generic failure.

What would you deliver?

  1. Identify stakeholders and missing information
  2. Write discovery questions
  3. Map AS-IS and pain points
  4. Define business rules and requirements
  5. Write stories and acceptance criteria
  6. Specify API/data dependencies
  7. Design TO-BE and UAT scenarios
  8. Define KPIs and recommend a solution

Your working notes

Draft an approach here, or work offline. Notes are stored locally in your browser—not sent to a server.

View reference solution / my approach

This is one defensible approach, not the only correct answer. Compare the reasoning and trade-offs with your own work.

Discover

Why: The progress bar request is an assumption, not evidence of the cause.

Deliverable: Stakeholder map, research questions and event-data audit.

Analyze

Why: Separate customer choice, copy confusion and technical failure before prioritising.

Deliverable: AS-IS journey with error paths and segmented drop-off.

Define

Why: The smallest safe improvement should be testable.

Deliverable: Resumable-upload and error-recovery stories with security criteria.

Validate

Why: A conversion lift cannot come at the cost of fraud or privacy.

Deliverable: UAT matrix and cohort experiment with control metrics.

Measure

Why: Success requires a precise denominator and guardrails.

Deliverable: Seven-day completion, step-level failures, support contacts and fraud exceptions.