Better order management for cashiers
How redesigning the orders dashboard for our cashiers led to a decrease in delayed orders.
SUMMARY
Period:
Q1 2021.
Shipped in April
Team:
Sole product designer and researcher on the team along with a product manager, business owner, data scientist and software developers.
Tools:
Figma, Protopie, Tableau
Impact:
12% decrease in delayed orders
BACKGROUND
Toward the end of 2020, GrabFood saw a spike in delayed orders which was a red flag for the team. Delay in orders meant a poor customer experience which further meant a sharp decline in retention.
Only 4% of customers who faced more than one delayed order would place another order with GrabFood.
A big reason for delays in order was not being able to accurately predict when an order was ready to be picked up at the restaurant.
Not knowing when an order was ready to be picked up meant either
Rider arrives early: Waists time waiting to cause a shortage of riders and leads to delay in other orders
Rider arrives late: Causes delays in the overall order and customers receive cold food.
An initial hypothesis which the working team came up with:
As cashiers mark orders ready, we will be able to train our data science model to allocate riders so that they reach the restaurant just as the food is prepared and packed.
That sounds great, but what is the cashier we are solving here? Multiple stakeholders on the team felt this way after hearing the hypothesis and were on the fence to build this feature if it was not solving a real user problem.
PROBLEM
With my past research experience, I knew that cashiers found it hard to locate specific orders in a long list as it does not differentiate between the status of the orders.
Here is how I rephrased the hypothesis from a cashier lens:
Cashiers will be able to manage their restaurant operations better if they can differentiate between orders which are in the kitchen and ready to be picked up.
Rephrasing the problem from a cashier lens switched the team's sentiment from "Not sure if we should be building this" to "Why have we not done this already?!". This was a significant contribution I had early on in the project to make sure the project moves forward.
DESIGN GOAL
An orders dashboard that provides crystal clear restaurant & order status even when viewed from a distance.
I wanted to treat this project as an opportunity to also design for the highly distracted and chaotic environment in which the cashiers worked. They would keep the device on a counter and would hardly ever hold it, hence distanced viewing was imperative.
Defining the user stories:
- As a cashier, I want to mark orders as “ready” so that the restaurant status on the app matches the actual store status.
- As a cashier, I want to know which orders are in the kitchen and which have been prepared so that I can quickly inform the delivery riders and other staff about them.
EXPLORATIONS
After exploring several low fidelity mock-ups, I decided to pursue the top three contenders based on stakeholder feedback and how well they solved the user problem:
Option 1: Individual orders as ready + filters
The idea behind this option was to keep the behaviour of the orders list same as how it was.
Pros
- Maintains the same list so no learning curve for the users.
Cons
- Having different orders statuses within the same list can confuse in finding orders.
Option 2: Batched orders as ready + filters
Pros
- Separate lists for different order statuses.
- Batch selection of orders would help in quickly marking multiple orders as ready.
Cons
- More education on what the checkbox does through online and offline communication.
Option 3: Individual orders as ready + tabs
Taking the best parts from the first two explorations we decided to separate the order statuses in different lists and have a Ready button on each order so that it is clear what the button would do.
VISUAL DESIGNS
Based on the goal I had set I redesigned the order card to be legible from a distance and share more information on the rider.
INITIAL ROLL-OUT
We launched with 10% of merchants in Singapore and saw that the results were promising but we could have done better.
~15% of orders that tapped "Ready" did not tap "Confirm".
Based on this insight I tried to hypothesise the reasons behind this:
- Accidental taps? But 15% seemed too high to be accidental
- Maybe cashiers were afraid to tap "Confirm" as they don't understand what it does. But then why do taps on "Ready" remains high.
- The most plausible reason could be that cashiers are busy and two steps for each order is a lengthy process.
We need to optimise for the cashiers time and not for accidents.
FINAL LAUNCH
Based on insights from the initial roll-out we patched the design to be one tap mark ready. We allowed the users to undo their actions through a toast message as well.
Also introduced an in-app onboarding to introduce the feature and educate them about it.
IMPACT
The feature was rolled out to all merchants in April and since then we have seen promising results.
46% of restaurants marks >80% of their order as "Ready"
This data was enough to suggest the value of the new orders dashboard for our users.
As cashiers marked the orders as "Ready" our data science team was able to make the driver allocation algorithm more accurate.
12% decline in the number of delayed orders was attributed to this feature.
We went over our target of an 8% decline in delayed orders.
FUTURE
Since this feature has been crucial for reducing delayed orders we are now trying to drive higher adoption. The second biggest bucket by usage is 0-20%. We are not trying to understand why some cashiers don't use this feature. Why is the behaviour like this and how can we augment the feature to suit them better. This will be done through cashier interviews and in-person observations.
LEARNINGS
Empathise with not just your users but also the working team: Had I not switched my mindset from "This does not solve a user problem" to "This might solve a user problem" I wouldn't have rephrased the problem from a cashier's lens and the project would have come to a standstill.
Disagreements within the team are not always a bad thing. It means all decisions are critiqued from multiple perspectives. However, disagreements that can lead to decisions that are not user-centric or can bring the project to a halt need to be dealt with immediately.
