Smartwatch Purchase Journey

Customers only discovered they needed an airtime plan when they reached the basket, after already investing time in the process. I translated a verbal brief into a full JIRA story, moved the requirement messaging earlier in the journey, and redesigned the basket as a guide rather than a gatekeeper. I also independently flagged a login bug that was clearing basket contents mid-journey.

The problem wasn’t just missing information. It was that the journey was designed to fail gracefully rather than designed to succeed.

My Role

The Product Owner flagged the issue verbally and I took it from there. I wrote the JIRA story and acceptance criteria from that conversation, mapped the existing journey to find where it was actually breaking down, designed the solution, and wireframed the key basket states. I also spotted a technical issue that hadn’t been flagged: when an existing customer logged in mid-journey, the smartwatch was being removed from their basket. I made sure it was captured as a separate story rather than left to surface post-launch.

Approach

Find the real source of the problem

The instinct might have been to fix the basket error state. But the actual problem was further upstream. Users weren’t being told what they needed before they started building their basket. I focused on moving the information earlier, to the device listing page, so users understood the pairing plan requirement before committing to anything.

Design the empty state as a prompt, not a failure

Errors feel like the user has done something wrong, even when they haven’t. My solution was a placeholder “Airtime Plan Required” component that appeared in the basket where the SIM would eventually sit. It’s not an error. It’s a clear, calm next step with a direct CTA to the SIM Only journey. The basket becomes a guide rather than a gatekeeper.

Design for all the states, not just the happy path

The wireframe covers four basket states: no airtime plan present, airtime plan added, airtime plan removed after being added, and the error state if one is still needed. Each state has a clear, specific response. The dev team could pick it up without needing a lengthy walkthrough, and edge cases were handled rather than left to chance.

Work within the constraints, flag what’s outside them

Saving basket contents through login wasn’t feasible without significant engineering work, so I designed around it rather than blocked on it. Moving forward on the immediate fix didn’t mean pretending the bigger problem wasn’t there.

Status

The wireframe and JIRA story were completed and handed over. The project was moved to the backlog following organisational restructure after the Three and Vodafone merger. The UX work is complete and ready to pick up.

Reflection

The most useful reframe on this project was shifting from “how do we handle the error?” to “how do we stop the error happening?” A lot of ecommerce UX ends up papering over journey problems with better error messages rather than going back to where the confusion starts. The login issue is also worth noting. It would have been easy to treat it as out of scope and move on. Flagging it cost nothing and meant the team at least knew it was there.

Leave a Comment: