JD App Onboarding

Turning a permission-heavy onboarding flow into a more trusted first experience

UX Onboarding Mobile App
RoleSolo designer
TeamPM, PO
Duration3 Weeks, 2023
ToolsMiro, Figma, Microsoft Excel

Outcome

Increased registration rate

iOS 9.5% → 20.6% +11.1 percentage points over 23 days
Android 12.7% → 24.7% +12 percentage points over 41 days

Overview

JD UK’s app onboarding asked users to accept permissions, share data and create an account before they had experienced much of the product.

The existing journey was also largely unbranded, making it feel disconnected from the JD experience.

I was asked to improve the iOS onboarding experience, with the eventual intention of applying the approach to Android and other areas of the business.

The result was a more branded, transparent and user-controlled journey and, after launch, registration increased from 9.5% to 20.6% on iOS and from 12.7% to 24.7% on Android.

The problem

The existing onboarding had a lot of asks and very little explanation.

Users were prompted for:

  • Push notifications

  • Location services

  • Data tracking

  • Account creation

But there was little context around why JD needed this information or what users would get in return.

The experience also lacked JD branding, making the onboarding feel separate from the app itself.

The brief was to improve the journey while meeting the existing acceptance criteria. But before jumping into screens, I wanted to understand whether the underlying journey was right.

The question became: how can we ask for more from users without making the experience feel intrusive?

Looking beyond the brief

I started by analysing the existing onboarding and benchmarking how competitors approached similar permission and account-creation moments.

A pattern quickly emerged: JD was asking users to make several commitments before giving them much reason to do so.

Competitors were often allowing people to get into the product first, then introducing account creation, personalisation and permissions at moments where the value was clearer.

That led me to explore three different journeys rather than immediately redesigning the existing one.

01

Improve the existing flow

Keep the overall structure, but:

  • Introduce JD branding
  • Explain why information is being requested
  • Improve the language
  • Ask users to create an account towards the end
02

Introduce account value earlier

Explain the benefits of creating a JD account earlier in the journey, so users understood how personalisation and permissions could improve their experience.

03

Build trust through the product experience

Instead of asking for everything upfront, let users browse first.

Account creation could happen when they wanted to:

  • Add something to their basket
  • Save something to a wishlist
  • Continue to checkout

Permissions could then be requested at a relevant moment for example, location services when helping users find their nearest store.

The Key Trade-off

The third approach was the most interesting.

It changed the fundamental relationship from:

“Give us permission so you can use the app.”

to:

“Experience the app first, then we'll explain why this permission is useful.”

The stakeholder agreed that this was the least intrusive experience from a user perspective.

However, there was a business trade-off.

The approach relied on users becoming engaged with the product before being prompted to register or opt in. That introduced a risk: some users might never reach the moments where those prompts appeared.

Given the three-week timeframe, the decision was to ship a more pragmatic version first, while keeping the longer-term approach as a future direction.

What changed

The final experience focused on three principles:

Give context

Explain why JD is asking for information rather than presenting a series of unexplained permission requests.

Give control

Allow users to defer decisions where possible instead of forcing an immediate commitment.

Build trust through the experience

Use JD branding and clearer language so the onboarding feels like part of the product rather than a separate permissions process.

Learnings

The biggest lesson wasn't about onboarding UI.

It was that a brief can describe the problem without necessarily prescribing the best journey.

The acceptance criteria initially made the experience feel fairly solutionised: ask for permissions, encourage registration and introduce personalisation.

Exploring the journey before designing the screens uncovered a different possibility, one where the product earns those commitments by demonstrating value first.

The final shipped solution was deliberately more pragmatic than that longer-term concept, but exploring the alternative helped me make that trade-off consciously rather than simply accepting the original flow.

The result was a better immediate experience, measurable improvement in registration, and a clearer direction for how JD could build trust earlier in the customer journey.