Could your website be working harder for you?
Quantitative data can tell you what is happening on your website. User research tells you why. When you combine the two, you get something far more in-depth. It's difficult to overstate the value of layering qualitative research in helping us to understand the nature of friction points in detail.
This layering enables you to build out a testing roadmap built on real customer behaviour rather than assumptions.
That's exactly the approach we took with Greater Anglia.
We had already looked at the quantitative insights for behaviour on Greater Anglia’s site but we wanted to dig a bit deeper further. Our goal was to take what was already known about customer behaviour and layer on targeted user research to deepen that understanding and turn it into something actionable: a prioritised experimentation roadmap grounded in real observed behaviour.
Specifically, we set out to pressure-test whether their key onsite journeys were:
Unmoderated Task-Based User Testing
We recruited 15 users and set them real journey scenarios; things like planning a trip, buying a ticket, and checking for disruptions. By watching them navigate the site without any guidance, we could see exactly where they hesitated, where they got confused, and where they dropped off.
This gave us direct insight into usability barriers and missed revenue opportunities across the homepage and booking funnel that analytics alone couldn't explain.
Tree Testing
We also ran tree testing to assess how well the current navigation structure was working. Rather than testing visual design, tree testing isolates the information architecture itself — asking users to find specific content using only the site's menu structure.
It's helpful to identify whether the way you've organised information actually matches how your users think.
The research surfaced some clear, actionable patterns.
73% of users were using the booking flow to check train times, not to book. This explained the drop-off Greater Anglia were seeing from the very first step of the flow. Users weren't abandoning because the booking experience was broken; they were using it as a timetable lookup tool, which meant the experience wasn't set up to serve that need.
Users missed season tickets entirely. This high-value product was inaccessible to the users most likely to buy it missing out on key revenue driving activity.
Disruption information was being found via multiple routes, pointing to a lack of consistent messaging across the site. Conflicting messages developed confusion and friction amongst users.
The booking funnel itself actually performed strongly. The trust badges and confidence signals in the flow were highlighted as helpful and effective at reducing decision effort and cognitive load. This was a useful counterpoint: not everything needed fixing, and knowing what was working was just as valuable as knowing what wasn't.
Not only did the research validate suspicions, it generated a prioritised, evidence-backed set of nine initial A/B test hypotheses, ready to go into the experimentation roadmap.
Each hypothesis was grounded in observed behaviour, not guesswork.
That matters. When you're making the case internally for why a test should be prioritised, being able to say "15 real users showed us this" is a very different conversation from "we think this might be an issue."
Why This Matters
User research and experimentation are often treated as separate disciplines. Research informs strategy; testing validates changes. But the most effective programmes bring them together much earlier in the process.
By running research before building the test backlog, Greater Anglia could invest their experimentation budget where we see the most friction as we have both the quantitative and qualitative data to back it.