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. Consequently, designing an experience to support that transition would not address the underlying constraint.

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

Meta

This project left me with mixed feelings. On the one hand, UX research successfully uncovered the root cause behind the observation and reframed the problem. On the other hand, I felt that this project left everyone dissatisfied. Stakeholders did not receive what they expected from us. Instead of a concept to increase web adoption, they were presented with evidence that their key objective and initial solution did not match customer reality. And I felt less like supporting a team and more like challenging their direction without being asked to do so.

This experience once again highlighted how important it is to involve UX early on. While we can deliver an experience around a predefined solution, true value emerges during Discovery.
Observing behavior (email orders) isn't sufficient. We must understand the underlying cause (procurement compliance on the customer side and integration gaps on ours) before defining goals and envisioning solutions around that.

The open question this project left me with is: How should UX act when invited into a process where the solution has already been decided? How can we navigate differing expectations?