Home / Work / Optym · RouteMAX
Case Study 02 — Behavioral Trust & Feature Adoption

When Nobody Uses the Button That Does Everything

They built a single-click automation. 18% tried it. Most never came back. This wasn't a training problem — it was a mental model problem nobody had named yet.

18% → 52%
Feature adoption in 2 months
5000+
Users across 3 clients
5 weeks
Study duration
Sole
Researcher & designer
Act I The Problem Nobody Named

A button that could do all your work. Nobody used it.

18% of users tried the Optymize button. Most never came back. The algorithm was correct. The automation worked. The engineering team had spent months getting it right. And yet.

The initial hypothesis was awareness. Demo sessions. Clinic walkthroughs. Explicit tutorials showing exactly what the button could do. Still 18%. The organization couldn't explain it. The product manager wanted more training. The engineering team wanted attribution data.

I pitched UX research as the path to an answer — not because I knew what the answer was, but because I knew the current hypotheses were downstream of the wrong question.

"The question was never 'why won't they use it?' The question was 'why are we asking people to abandon the mental model that makes them feel competent at their job?'"

Planners in the P&D industry had spent years building expertise in a specific cognitive process: grouping shipments geographically, applying constraints from memory, drawing on pattern recognition built over years of operations. The Optymize button asked them to invert that entirely — to input constraints and wait for the algorithm to produce routes. Not a small change. A complete behavioral inversion.

The interface never explained this trade. It never named what it was replacing or why the replacement was trustworthy. It asked people to delegate expertise to a system without first building a relationship with that system.

Mental Model Inversion Old workflow planner groups shipments → routes planner in control New workflow planner inputs constraints → wait algorithm in control vs The gap between these = the mental model mismatch Not a design problem. A transition problem. Nobody designed the bridge.
▶
Drop your Optym research presentation video here.
<iframe src="https://player.vimeo.com/video/YOUR_ID">
Act II The Research Design
Defining Trust for this context 01. Reliance Do they accept the solution without heavy modification? 02. Transparency Does the experience explain how the algorithm thinks? 03. Comprehension Are labels and terms meaningful in their world? defined before any interviews
Why a Diary Study?
Running a usability test was impossible — the algorithm needs real operational data in real time. Dummy data produces a test environment. Test environments produce test behavior. Test behavior doesn't tell you why real users stop coming back.

Two user types.
One structural failure mode.

The data surfaced two distinct patterns before the research even started. Non-users who had never tried the feature. And bounce users who tried it once or twice, then stopped.

I designed a three-phase study to capture both attitudinal and behavioral data: a cognitive walkthrough to surface mental model assumptions, a 1-week diary study using the feature with real operational data, and a post-discussion to clarify diary entries with the user and engineering team together.

The diary study was unusual. Most researchers avoid real production data in studies. Here, it was essential — the algorithm's output depends on the complexity of live route conditions. Simplified data produces simplified reactions. We needed to see what happened when the algorithm encountered the actual messiness of the user's workday.

The cognitive walkthrough revealed something immediate: the popup that launched the feature didn't name what it was replacing. It didn't explain the concept of dynamic routing. Users were being handed a key to a door nobody had introduced them to.

Act III The Finding

The real reason wasn't awareness. It was change management.

Non-users couldn't parse what the feature was even for. The interface never named what it was replacing. It showed inputs and a button without situating the button in the planner's existing workflow.

Bounce users had a different failure: the algorithm sometimes produced "extra routes" — a technical artifact of shipments that didn't fit clean geometric groupings. Users who encountered one extra route concluded the algorithm was unreliable and stopped using it permanently. Trust, once broken by a single unexplained output, requires twice the effort to rebuild.

The priority model shifted everything. At the end of the study, I asked users to rank the reasons they'd stopped using the feature. "Lack of awareness" — the organization's primary hypothesis — ranked near the bottom. Confusing interface and unexplained outputs ranked at the top.

Impact
18% → 52% adoption in 2 months post-redesign — north star metric achieved; led to industry press release and client expansion
Mental model migration framework became standard for all subsequent automation features in the product — applied to 3+ future modules
Client-led data correction initiative — findings surfaced a data quality issue outside our scope; client launched an internal initiative to fix it, enabling better algorithm outputs
"The software is intuitive and most planners were able to understand the majority of features with limited training." — Patrick Sugar, VP Linehaul & Engineering, Saia
Adoption over time 18% redesign 52% +2 months 0% 50% north star ✓
Biggest learning
When introducing new behaviors, focus on how the transition phase looks — not just the destination. Priming users to migrate their mental model is more important than proving the new system is correct.

Next Study

Learning to read the spaces between what people say

Hologic · University of Florida →