Reducing customer anxiety around live orders & lowering help centre contacts
The Setup
My Role
Lead Product Designer - Ordering Team: Led discovery workshops, shaped problem framing, and owned UX direction for various tracking improvements and fixes.
Picking up multiple existing projects and threads, helping define and prioritise them for the 2025 roadmap, and then get the work completed by a demotivated team who had lost trust in the product and design processes.
Working Constraints
Product Designer and Manager had both recently left the team so progress had halted
Trust and relationship with engineers had broken down with team building their own fixes and solutions
Stakeholders coming with solutions and pushing them through based on their priorities
Collaboration
Cross-functional team spanning Product, iOS, Android, Web, and Backend.
Stakeholder sponsors was VP of Operations with heavy collaboration with the Customer Support and Operations teams.
The Context
Early on, while shaping the 2025 roadmap, we ran a set of workshops looking at delivery clarity, tracking, and reordering. I co-led one of these with the Order Experience PM and our Head of Design, breaking the experience down to understand where our delivery communication was letting people down - and beginning to gather ideas for roadmap consideration.
A lot of issues surfaced, but they all pointed to the same underlying problem: people didn’t have a clear, reliable sense of what was happening with their order. The stand out issue being if they left the app or it refreshed, tracking disappeared, and delivery status became something customers had to go hunting for in Profile.
We treated this as the starting point: making tracking a clear, reliable place to return to, delivery status stays easy to find, uncertainty drops in the moment, and it gives us the solid foundation to improve the overall order tracking experience.
On day one, stakeholders from across the company shared what they’d learned about ordering and delivery, with a clear focus on how these moments affect reordering.
I put that together a view of the customer journey, using Flink data, customer feedback, and industry research to map how people actually think and behave as they move through an order.
On day two, I co-moderated the ideation and prioritisation sessions, eventually turning those insights into concrete bets that fed directly into the Ordering team’s 2025 roadmap.
Digging Deeper
The OKR workshops gave us an overview, but they didn’t explain WHY tracking felt unreliable day to day. To understand that, we reviewed support tickets, looked at behaviour in Looker, and ran user tests on how people got back to an active order.
We then broke the tracking experience down and examined three areas in detail:
How time was shown — and whether people understood what was promised versus estimated
The language used to communicate progress
The model used to represent delivery steps
We same the same each time. People weren’t struggling with the tracking information itself - they were struggling with the logic and architecture around accessing it and maintaining that access. The journey back to an active order was unclear, inconsistent, and often invisible.
That pointed us directly to the problems we needed to solve next.
P
We saw consistent patterns across support contacts pointing to the fact that tracking orders was more of an issue than it should be. The tracking view itself could be improved but it wasn't a critical weak link. The pressing issue was locating the delivery info.
Mapping The Experience
We found the flow contained gaps in logic and inconsistencies which we suspected could result in poor order tracking experiences and ultimately customer support contacts. These included:
Back-button behaviour in order tracking was inconsistent. Data + testing showed many users hit Back on autopilot right after checkout, expecting to land on the homepage - even though tracking was already the most useful “next step” screen for that moment.
Once out of the Order Tracking experience, users struggled to rediscover the tracking as it was buried away in the Profile section of the app.
I did a quick sweep of competitor and adjacent apps to see how they display tracking, especially when the data isn’t perfect.
I looked not just at grocery delivery but at anything built around waiting - ood, parcels, rideshare, support. I focused on the basics: how they structure the tracking view, how they present time (promised vs estimated), how they show progress step-by-step, and how much detail they give without overloading people.
We pulled out a few patterns we could reuse in our setup.
Top placement for visibility
Link directly to dedicated tracking view
Crystallising The Issues
When the problem was put into focus I began putting together an Opportunity Solution tree, initially collecting ideas already on the table and then opening up the exercise to the team. The combined results went on to inform our immediate solutions and to populate the team backlog.
Our Focus
Check progress at a glance
Return to tracking after leaving the screen
Know when delivery was likely
Understand available actions
(Future) Add or edit items after the order was placed
Tracking was hidden in Profile
Session refreshes dumped users on Home
Back-navigation led to irrelevant screens
Messaging required effort to interpret
No consistent “hub” screen to host post-order actions
Developing Ideas
With the focus set with the team and stakeholders, I began to develop specific ideas to address the issues we'd identified.
Input From The Team
The order flow was simplified so navigation behaves predictably, including corrected back-button behaviour and the removal of dead ends that caused users to lose their place.
Outcome: A couple of ideas came out that the PM and I hadn't considered and scope was realistic from the start as we could rule out technical solutions that were not possible for our timeframe.
Fixing Flow Logic
The order flow was simplified so navigation behaves predictably, including corrected back-button behaviour and the removal of dead ends that caused users to lose their place.
Outcome: A more logical interaction to match customer expectations over the technical implementation that is currently in place.
Mapping Potential Scenarios
I wireframed all of the UI and flow changes that had been discussed as the first step on identifying and narrowing down the available options.
Outcome: Established the boundaries for V1 of the project with focus being on a simple delivery time element that links to Order Tracking as well as enabling editing a live order.
Access To Delivery Info
Taking our initial discovery I experimented with models for showing delivery status and allow customers to quickly jump to the Order Tracking view.
Outcome: We decided against adopting a floating element for V1 as the interaction of a the rest of the app content was unclear and posed interaction risks without further research.
With some exploration done we had a clearer plan for the final work that we'd take forward into production…
Principles & Approach
A handful of key points were agreed upon that would guide any solution we produced:
Results Snapshot
More Visible Order Tracking
Final Entry Point
An early version featured a floating element accessible during active orders on all views, but it was dropped due to conflicts with too many app elements and experiences.
Modular Functions
I had experimented with dozens of visual variations for the entry points which combined brand and UI patterns to find the right balance to communicate the right level of importance while not taking away from the rest of the app experience.
Active order state showing the live delivery time and tracking access.
Module added when the customer is able to add items to a live order that hasn't left a Flink Hub.
Scheduled state that is shown when an order is placed but will delivered at a time in the future and not right away.
Changes had to work in German, Dutch, and English. So concise verbiage was selected, relying mostly on familiar tech terminology rather than more traditional phrasing which tends to run long in both German and Dutch.
Alternative versions
Some of the dozens of visual and content iterations we cycled through looking for the right balance of brand and function.
Customer taps Add items
A lightweight shopping view opens, with category browsing and search
Selected items are added and confirmed via a simplified standalone checkout, using delayed payment capture to attach them to the existing order.
Outcomes
~23% fewer support contacts
for tracking issues
Same order types pre/post — tickets tagged “Where is my order?” + tracking access
~7 mins faster handling
per tracking support ticket
Customers arrived with clearer context, so less clarification / back-and-forth
↑ ~15% CSAT uplift
for users who used tracking
Compared to baseline CSAT for orders with no tracking interaction (same period)
