JD Sports — Customer Authentication

The brief I was handed

Migrate authentication from Auth0 to AWS Cognito, maintain the existing experience, avoid drop-off. That's how it arrived: a supplier swap, framed as an engineering exercise, with the constraints already fixed. No custom fonts. Limited error state control. Restricted UI customisation, all of it inside Cognito's hosted UI.

I wasn't involved in the original decision to move to Cognito. That call, and the direction it set, had already been made before the brief reached me, and the PM I was working with had limited say over it either. Millions of registered customers across 12 regional rollouts were riding on this, so before I accepted the constraint set as fixed, I requested AWS environment access myself and went through Cognito's actual capability set directly, rather than relying on what I'd been told it could do.

What that investigation found

The brief had been built on an assumption: that Cognito's limitations were absolute. That wasn't fully accurate. Some constraints were real. Others were negotiable with the right technical approach. I wrote up the distinction and used it to reopen the scope conversation that had, until that point, been treated as closed.

The password visibility toggle is the clearest example. We'd been told it wasn't possible on the hosted UI and would have to wait for a custom build. I pushed it as non-negotiable on accessibility and usability grounds. It shipped in the hosted UI.

Font size worked the same way. Cognito's hosted UI defaulted to minimum sizes as low as 10px. I pushed for 16px as a non-negotiable floor, and it shipped that way too, alongside a screen reader pass and contrast checks against the hosted UI's constrained styling options. Small, specific fights, won by pushing rather than accepted as a platform limitation, and the same category of win as the toggle.

Once the constraint set had a credible line between real and negotiable, the brief stopped being "replicate what exists" and became a decision about what to build within a boundary I'd actually tested rather than inherited.

What I pushed for and didn't get

The capability review opened a second conversation, about what authentication could be, not just what it had to maintain. I advocated for two additions: magic links, to reduce friction for returning users, and social login via Google and Apple, to reduce registration abandonment on mobile.

Neither made it into the initial build. The PM deprioritised magic links on implementation complexity relative to the migration timeline. Social login was deferred. The migration was treated as a like-for-like swap to minimise risk, with improvements sequenced separately.

I disagreed with both calls and understood the reasoning behind them. I wrote up the case for each and made sure they entered the product backlog with the original rationale attached, rather than letting the deprioritisation erase the thinking behind them.

North Star and sequencing

I designed a North Star authentication experience: the version built without timeline or technical constraints. It gave the team a shared picture of the destination and made the sequencing decisions legible rather than arbitrary.

The phased delivery plan was signed off by the PM, Trade, and Engineering. Engineering pushed for single-phase delivery to reduce integration complexity. Trade wanted registration prioritised first given its direct impact on new customer acquisition. I resolved the disagreement by sequencing based on customer journey criticality, starting with the flows most users encounter most often, deferring lower-frequency flows to subsequent phases.

App platform

The migration covered web and the JD Sports iOS and Android app. Once it was clear a custom UI wasn't going to be funded for web, the app ceiling was set by the same constraint. I designed within it rather than advocate for investment that had no realistic path to approval.

On Android I designed a separate flow accounting for the absence of Apple Sign-In. Treating both platforms as identical would have left Android users with an unexplained gap. The Android authentication experience was designed as coherent in its own right.

Validation

There wasn't scope for formal user testing before launch. I walked a set of senior stakeholders through the new flow directly rather than relying on sign-off from a deck. The flow was close to a one-for-one match of the existing experience by design, which is what that walkthrough was checking for rather than trying to uncover new problems.

Outcome

The migration delivered without measurable drop-off across authentication flows. Across 2.1 million customer accounts in the UK, Ireland, and Italy, fewer than 2% of active customers — those who'd logged in within the previous 30 days — failed to update their password after launch: around 250,000 customers moved through the new authentication flow cleanly. Maintaining baseline performance through a full supplier change touching millions of registered customers was the right definition of success for this phase.

Switching suppliers also saved the business roughly £50k on initial cost. My own instinct going in was that the hosted UI's constraints — not looking or feeling like a proper JD sign-up screen, particularly inside checkout — would cost real trust and conversion. The numbers didn't bear that out; drop-off wasn't close to what I'd expected. Worth stating plainly rather than only presenting the parts of my judgement that were right.

What matters more long term is the backlog that now exists for authentication improvements. Magic links and social login are defined, scoped, and ready for prioritisation. The migration created the foundation; the roadmap exists to build on it.

What this changed organisationally

• Authentication improvement roadmap created where none previously existed. Magic links and social login scoped and backlogged with documented rationale.

• North Star design used as a sequencing framework, establishing a model for phased delivery decisions on the product team.

• Constraint investigation approach of requesting direct environment access before accepting a technical brief, carried forward into how I approached later infrastructure-adjacent work.

What I'd do differently

I wasn't involved in the initial decision to move from Auth0 to Cognito — I inherited the brief after that call had already been made. I'd want to be in the room earlier next time, before the supplier decision rather than after it, so constraint trade-offs like hosted-UI branding limits are weighed against alternatives rather than accepted as fixed. Given where I joined the process, I think what shipped — including the magic links and social login groundwork for phase two — was close to the best achievable outcome.

Key decisions I personally drove

• Challenged the constraint set by requesting direct AWS environment access before accepting the brief.

• Identified which Cognito limitations were real versus negotiable.

• Pushed minimum font size from 10px to 16px on the hosted UI on accessibility grounds.

• Advocated for magic links and social login and ensured both entered the backlog with documented rationale.

• Designed the North Star experience that gave the team a shared destination.

• Resolved the Engineering vs Trade sequencing disagreement using customer journey criticality as the framework.