Designing a system that guides behavior instead of policing it
Improving on-time arrival with a carrot, not a stick
Problem
On-time arrival was a trust and SLA issue; the app's flow and sequencing contributed to experts arriving outside the customer's window.
Solution
We redesigned the flow to make state changes unmistakable and harder to perform accidentally, and A/B tested a flow-based approach against a blocking timer.
Impact
On-time arrival improved from roughly 60% to 75%. The work gave the team confidence to investigate system-level constraints with evidence rather than intuition.
THE CHALLENGE
On-time arrival is an important metric for both the business and customers
In Asurion Field, "on-time arrival" means an expert arriving within the customer's selected two-hour window to deliver and set up a new phone for them. Arriving outside that window — early or late — breaks SLAs with client partners and erodes customer trust.
At the time of this work, we were contractually expected to stay above 80% on-time. We were hovering around 60%.
This wasn't a scheduling or routing problem alone. It was a behavior problem — shaped by how the Field app sequenced information, intent, and action at critical moments.
Experts didn't understand that the job window was chosen by customers, so didn't think it was important to stick to
The existing app flow made it easy to perform actions incorrectly
Experts often felt that the routes given to them were impossible to complete on time, so they were looking for other ways to make up time in the day
Data discrepancies meant we didn't have good visibility into what was really happening in the field in order to know what to improve
A tale of two nearly identical screens
The biggest breakdown occurred around two adjacent moments in the flow: "En route" and "I've arrived."
The two screens looked visually similar, used nearly identical interactions, and appeared back-to-back. Under time pressure, experts would sometimes swipe through both without realizing it.
Let's play "Spot the difference"
Additionally, Experts had to leave the app to use their navigation, creating a clunky experience. Even for experts who meant well and really wanted to do the right thing, the Field app made it difficult and cumbersome to do. The old flow required them to go from Field app, to Google Maps, back to Field app, BACK to Google Maps, just to complete 1 step "correctly".
App performance issues amplified this. When the app lagged, experts would attempt to swipe "En route" again — only for the "I've arrived" screen to load in that moment. One extra swipe, and both states were triggered back to back.
Even experts trying to do the right thing were set up to fail.
Before these changes, over 80% of "en route" and "arrived" events were logged within 2 minutes of each other, despite expected average drive times of around 30 minutes.
THE APPROACH
Fixing this meant changing behavior, not just screens
Experts often arrived outside the window the customer chose for understandable reasons. They were trying to work efficiently, get ahead of schedule, or recover time elsewhere in their day. But from a customer's perspective, arriving early could be just as frustrating as arriving late.
Customers choose appointment windows based on when they'll be home. Showing up outside that window — especially without notice — directly impacted NPS and trust.
The challenge wasn't convincing experts that on-time arrival mattered. It was designing an experience that made the right behavior the easiest one to perform.
The constraints were non-negotiable
We couldn't change the routing system, the two-hour appointment windows, or the client SLAs defining success. Backend logic and scheduling were off the table (for now).
What we could change was how the Field app guided behavior: how clearly it communicated state, when it revealed information, and how it sequenced actions under real-world conditions.
This became a small-surface, high-impact design problem.
When control feels like the obvious answer — but isn't
Early in the project, our some stakeholders came to us with a specific proposal: introduce a screen that would block experts from continuing a job if they arrived too early, outside the appointment window.
On the surface, this made sense. If early arrival was the problem, prevent it entirely.
From an experience perspective, this raised concerns. Blocking progress often just shifts consequences elsewhere in the system. If experts couldn't arrive early, many would inevitably arrive later in the day, compounding delays and frustration.
Rather than debate hypotheticals, we A/B tested two versions.
Test A: The hard-blocking timer experience our stakeholders proposed
Test B: A flow-based solution to guide behavior without forcing it
The results were clear: the blocking experience actually made the metric worse compared to the control by about 4%. Preventing early arrivals pushed experts further behind schedule, increasing late arrivals later in the day and leading to more jobs that had to be canceled entirely.
Evidence replaced assumption — and allowed us to move forward with confidence.
THE SOLUTION
Designing clarity into moments where ambiguity caused real damage
Rather than adding warnings or confirmations, we focused on making state changes unmistakable — and harder to perform accidentally.
We redesigned the flow so experts had to explicitly mark themselves "en route" before accessing navigation. The customer address was intentionally withheld until that moment, while a map-based view with drive time and ETA still gave experts what they needed to communicate with customers.
We also changed the primary action so launching navigation happened after marking "en route," keeping experts in Field long enough to trigger live tracking and customer notifications.
The goal wasn't to slow experts down. It was to remove ambiguity exactly where ambiguity caused the most harm.
THE RESULT
A few small changes unlocked a measurable shift
After launch, on-time arrival improved from roughly 60% to 75%. While still short of our SLA target, this was a significant directional improvement — and a clear signal that behavior and flow design were critical levers.
We also saw our data accuracy significantly improve as a result of the changes we made, giving us better insight into the experts' days and how the routing was actually holding up under real-life conditions, like traffic. We saw a huge jump in average drive times reported (from 17 minutes under expected to 23 minutes over), which gave the team confidence to investigate deeper system-level constraints with evidence rather than intuition.
REFLECTION
Pushing for better ideas — and proving them — changed how we worked
Alongside the blocking A/B test, I also explored a more holistic redesign of the flow. While initially considered too complex, sharing that work broadly helped leadership see a better long-term path.
With support from Product leadership, and through creative use of AI-assisted development and a Figma Make–powered handoff, engineering delivered the more ambitious solution two weeks ahead of the original MVP timeline.
This shifted how the team thought about design's role — not just executing requests, but driving strategy and shaping better outcomes.
This project reinforced that:
- →Blocking behavior rarely creates trust
- →Testing is a powerful way to resolve cross-functional tension
- →Designing for imperfect systems requires empathy and rigor
It's an approach I carry forward: push back thoughtfully, test honestly, and let evidence lead.