Product page


Project summary

  • The project team kicked off without a design lead and had begun with a solution, rather than with research. Their solution was 'making options easier to select on the product page'. When I joined the team as design lead I advocated for the use of JTBD to ensure we were focusing on user needs and opportunities rather than going straight to an assumed solution.

  • Going back and carrying out a research phase meant that the focus was changed from ‘I can select the product I want’ to ‘I can determine if this is the right product’.

  • We'd been consistently receiving anecdotal feedback from Account Managers that there were elements on the product page that buyers found confusing and/or frustrating but the feedback had not been collected in a structured or contextual way.

  • Our problem to solve pivoted to become about helping the user complete the job of determining if the product they were viewing was what they were after, thanks to the findings of the research.

Problem to solve


  • User interviews

  • Market analysis



  • Job map

  • Functional and emotional outcomes for each step

  • Card sorting

  • Maslow's hierarchy of needs

Plot twist, once we reached this point the project changed (again). Different project teams on another stream were about to make changes to the product page. We had a workshop session where we discussed our different projects and the impact they could have - it was significant!

We agreed that we would take my research, and from that I would build the content hierarchy and information architecture so we were all singing from the same hymn sheet. This was then used by the design team and we translated it into a new visual layout for the page. Finally, in a twist of fate, the other projects were paused and the business focused on the hierarchy and visual changes, with the rest to be picked up in due course.

Final designs

  • The business may change the product priorities, but the research can be used as a basis for many pieces around the subject area.

  • It is always worth pushing back on a solution based project kick off to make sure the problem is fully understood. When I joined the team, I couldn't tell them what else was missing from their solution, as I didn't know the full extent of the user's problem. The research really showed the full extent of the user’s struggles and frustrations and meant we could focus on something that would be useful and valuable to the user.

  • I really love this type of work, and while not everyone may geek out on the process, the impact of the findings was unanimous amongst the teams.

Key learnings