Driving web channel adoption

Or: are we even designing the right solution?

Role

Strategic recommendation

Constraint identification

Problem reframing

Insight synthesis

Assumption validation (User interviews)

Research design (Discovery)

Strategic recommendation

Constraint identification

Problem reframing

Insight synthesis

Assumption validation (User interviews)

Research design (Discovery)

In a nutshell

Background

The company’s eCommerce marketing team approached us with their key objective for the year: transition all customers who traditionally placed orders via email to the web shop. This initiative was based on the team's recent observation: hundreds of customers were still submitting orders by email. These orders required manual processing and limited cross-selling opportunities.
The briefing was: design an experience that makes the shift from email ordering to the web shop as easy as possible for customers.

Approach

Before focusing on the solution, we needed to understand the problem first: Who are the customers that place orders via email? Why do they prefer ordering this way? We had some general assumptions (Users feel reluctant to change their habit of ordering) but also suspected product-specific constraints (Users feel intimidated by the account creation and validation process of the web shop).
To answer these questions, we conducted 5 interviews with customers who had purchased via email.

Results

Our research revealed something unexpected, nowhere near our assumptions: customers were not actively placing orders via email. Instead, they submitted manual orders through their eProcurement systems, which then generated automated emails to us. They relied on the manual order function because our company lacked full integration with their procurement platforms. And their organization required them to use these platforms in the first place to ensure compliance, streamline workflows, and access negotiated pricing.
This led to an uncomfortable truth: these customers could not realistically be transitioned to the web shop. The right recommendation was to stop, not to proceed.

Kanban-style codebook interface showing categorized tags and their definitions for research analysis

Meta

This project is a good example of UX research doing exactly what it should – and still being uncomfortable. We didn't deliver the concept stakeholders had briefed us on. Instead, we presented something more valuable: evidence that the brief itself was built on a false premise. Investing in a web shop onboarding flow would have had no impact on email order volume, because email ordering wasn't a customer choice but a procurement system constraint.
That's an outcome worth defending. Avoiding wasted development effort on a solution with no chance of success is a UX contribution, even when it's not the one stakeholders expected.

The harder lesson was about timing and positioning. By the time we were brought in, the team had already aligned internally around a solution direction. Research that validates a direction is welcome; research that invalidates it creates resistance, regardless of its quality. The real opportunity for UX would have been earlier: at the point where the observation (email orders exist) was being translated into a goal (move customers off email) without yet understanding why the behaviour existed.

What I'd do differently next time: be explicit upfront with stakeholders that the brief is built on an observation, not yet an understanding of why that behaviour exists. And that our discovery research might reframe or invalidate the problem entirely.