Sparks Pay — Redirected journey
Identifying a broken post-signup flow and designing the optimal path from email acquisition through to app onboarding and account binding.
Product Designer
Journey mapping · Acquisition · Onboarding
Stakeholder interviews · User journey mapping
Overview
This project focused on a critical gap in the Sparks Pay post-signup experience. New customers who signed up but didn't have the M&S app installed were landing on a dead end page — unable to access the product they had just signed up for.
The goal was to identify the correct intervention point and redesign the flow to remove this barrier, ensuring users could complete the binding process without friction.
Problem statement
How might we enable non-app M&S customers to successfully download the Sparks Pay app — without relying on deep-links?
M&S customers navigating to Sparks Pay were getting stuck in a broken loop. Deep-link failures caused by device privacy settings meant users couldn't complete the app download journey — and the existing /sparks/bind URL simply redirected to the wrong page, offering no clear path to download the app.
Appsflyer deep-links are unreliable due to device-level privacy settings outside M&S's control
New Sparks Pay customers who don't have the M&S app installed
A standalone fallback page that reliably guides users to download the app — in time for in-store launch
Research methods
To understand the problem deeply before designing, I used two methods — one to gather context from the people closest to the product, and one to trace exactly where the customer journey was breaking down.
Qualitative · Discovery
Spoke with the apps team and the wider project stakeholders to understand the technical constraints, what had already been investigated, and what a successful solution needed to achieve.
- — Understand Appsflyer limitations and why deep-links were failing
- — Clarify what a "tactical, low-cost" solution meant in practice
- — Align on timeline constraints around the in-store launch
Qualitative · Analysis
Mapped the end-to-end Sparks Pay flow from a non-app user's perspective to pinpoint exactly where the journey broke and what the user experienced at each failure point.
- — Identify the exact drop-off point at /sparks/bind
- — Understand what information a user needs at that moment to continue
- — Define the minimum viable page content to unblock the journey
How Sparks Pay works
Understanding the product flow was essential before diagnosing where it broke down.
- 01Customers sign up for Sparks Pay through M&S
- 02£500 worth of credit is automatically attached to the account, provided by M&S Bank
- 03To use the credit in store, the customer scans a QR code found inside the M&S app at the till
Mapping the gap
Before any design work began, I mapped the current journey against the ideal state side by side. This made it immediately clear where the experience broke down and what the correct intervention point was — giving the design a focused, evidence-based direction.
- Welcome email
- Sparks Pay landing page
- Dead end — no clear next step
- Welcome email
- App Store — download M&S app
- M&S app → Sparks hub
- Binding process triggered
A broken acquisition flow
After signing up, customers receive a Welcome email directing them into the Sparks Pay experience. However, customers who do not have the M&S app installed — which is required to access the product — are redirected to a generic Sparks Pay landing page rather than being guided to download the app.
This creates a dead end at the most critical moment of the journey. The correct flow would route these users directly to the App Store, prompt them to download the M&S app, then navigate them to their Sparks hub to trigger the binding process.
Why this matters
Fixing the redirect at this stage removes a significant drop-off point and ensures users can actually activate the product they signed up for.
Removing the dead-end redirect eliminates the key abandonment point in the post-signup journey.
Users are guided to exactly where they need to be — no ambiguity, no friction.
More users completing the binding process means more users able to use the product they signed up for.
From system to screen — components in practice
The landing page was assembled using a structured component library, mirroring how design systems work in production environments.
Each element on the page maps directly to a reusable component: the Hero Banner establishes hierarchy and primary CTA placement, App Buttons communicate platform availability using a standardised pattern, and the Info Feature surfaces supporting content in a consistent, scannable layout.
This approach reflects how real product teams work — designers compose from a shared system, ensuring visual consistency, faster iteration, and handoff-ready output. Every component applied here was chosen with intent: the right pattern for the right content, in the right position.
