UI & UX DESIGN
SPARK-
RETURN FRICTION
Earn money with Spark Driver!
With the Spark Driver app, you can deliver orders, or shop and deliver orders, for Walmart and other businesses. All you need is a car, a smartphone, and insurance. After you’ve completed the enrollment process (including a background check), you will be notified when your local zone has availability. You’ll then receive details for accessing the Spark Driver™
https://drive4spark.walmart.com/
Duration
10 months
My Role
Product Designer
Team
Copywriter, UX researcher, UI designer, PM
My contribution
Information architecture, Ideation, Wireframing, Prototyping, and Iteration.
Problem Statement
Spark deliveries have a high return rate incurring additional return costs, and loss of revenue, and negatively impacting NPS.
What is the problem?
-
Spark driver returns are close to 1% for all the orders combined (Scheduled, Unscheduled, and Express) which is significantly higher when compared to some of the other players in this space.
-
Drivers are spending less time at the delivery location if in-case customer address/drop-off location is not easily found.
-
Drivers are attempting to contact customers even in case of no-contact delivery and returning back if the customer contact does not happen which is non-ideal for unscheduled GMD orders.
Business Impact
-
Spark driver returns are significantly high when compared with competitors
~1% of all orders(Scheduled, Unscheduled, and Express) combined are currently being returned by drivers
-
Spark driver wait time is significantly less
~84% of drivers spend less than 2 mins at the customer location if the address/customer is not easily found
-
Inaccurate return reason codes are selected
More than 90% of the time "no safe location found" reason code is selected which impacts our ability to identify the main root cause for the return
Current scenario
Start return
ℹ️ After the driver arrives at the location, they will start seeing the steps for dropping off the order, the first step is reviewing drop-off notes.
🙁 For no-contact deliveries, the existing copy instructions tell the driver to contact the customer even if it's a no-contact delivery. Failure to contact the customer, the driver initiates a return.
Return reason code
ℹ️ Driver can select the reason code if they have an issue delivering the order to the customer by swiping the bottom sheet on the above screen.
😕 Currently, drivers can easily select reasons such as "no safe location found" and get away
Information architecture - Current
Wireframes & UI - Current
To better address user needs, I iterated the second version of low-fi wireframe based on old flow and UI
Attended delivery
Unattended delivery
Information architecture - Proposed
Wireframes & UI - Proposed
Attended delivery
Unattended delivery
User Testing & Iteration
We decided to do field tests & user tests before we launched the app, we interview drivers to determine if the new friction can reduce the return rate and won't bother the whole experience.
Directed from drivers
-
Consider adding within the timer info, an explanation of what would happen if they can't reach the customer in the time given.
-
7/10 drivers feel the big timer gives them pressure if they'd like to contact customers or not and feel frustrated if they can't skip it.
-
Drivers suggested adding action if they solve the issue and can continue to deliver.
-
7/10 drivers are likely, or may still call driver support despite what the app says about no need to call.
The test shows drivers will do as much as possible before returning the order, what we can improve is adding friction in the returns experience which would enable drivers to put more effort into contacting customers.
Ideate & Solution
Replace the list of existing reason codes with the new reason code to capture accurate information
Adding a TimeStamp at the backend before drivers can initiate a return. We believe this makes drivers put in more effort in reaching out to customers before they initiate a return;
Copy brings more information to better suggest they try everything before returning;
Add a pop-up at the first stage of the return journey prompting the driver of an unscheduled delivery to be delivered without contacting the customer;
Add a pop-up at the final stage of the return journey to remind drivers what's the next step of the drop-off progress.
Final Design
Return Order
-
Able to configure the timer (time displayed until the order is eligible for return) for particular zones and order types;
-
Update the copy for unscheduled (GMT delivery) to notify the driver that the delivery can be completed without customer contact;
-
Including proactive pop-ups notifying drivers of no-contact delivery for unscheduled delivery can help us solve the problem of returns being initiated because customers are not available
Successful deliver
-
Replace the list of existing reason codes with the new ones to capture accurate information;
-
Add return steps at the end of the checklist including "Issue resolved" CTA in case drivers can deliver orders after they contact customers.
Launch Impact
-
Return rate (Before & after)
Spark Return rate down by 22 basis in week 34 compared to week 32.
-
No negative impact to Missing order
Historically we have seen an inverse relationship between returns and missing POs. We monitored missing POs as a metric to ensure it was not going up with the launch. No negative impacts.
-
Driver <> Customer contact rate for resolving delivery issues using the new experience
For resolving a delivery issue during drop-off, drivers are now taking proactive steps instead of directly returning back to the store. The driver<>customer contact rate increased from 173 to 23K+ for resolving an issue at drop-off.
