The stay-at-home order for COVID-19 across the nation has caused many to order in bulk for their grocery deliveries.
With a partnership with 3rd party delivery services, this has led to orders being too large to fit inside a driver’s vehicle.
I co-designed with my peer, Yangyang, on a new feature that enabled associates to split large orders by requesting a new driver.
Launching at the end of Q3.
What do I do if an entire order won't fit inside the vehicle?
Currently, for large orders that don’t fit inside the driver’s vehicle, some associates partially load them and manually call a new driver to come pick up the remaining items.
This wastes a lot of the associates' time and leads to customers wondering where the rest of their order is.
How might we provide a seamless experience for an associate to handle orders too large to fit inside a driver’s vehicle?
I first aimed to gather more insight into this particular problem and scenario. I conducted user interviews with our associates to learn more about what they usually do in these situations.
I worked with my PM, Santhosh, to summarize the different use cases we found and documented them on our Confluence page.
This page helped our team better understand how the issue is currently handled and enabled us to think of a more systematic approach to solving the problem.
Yangyang and I did a whiteboarding session using Mural. We noted key associate and customer pain points as well as possible ways of addressing them.
The possible solutions we noted were intentionally forward-thinking and didn’t take into account development effort. We would later scope this out with engineering.
What if we could predict the likelihood of an order being too large in the beginning and prompt for the associate to take the action of splitting it.
Having synced with our engineers early, we found that this approach wouldn't be feasible at this time because we would need a deeper integration with our third-party services (DoorDash, Postmates, etc).
ITERATIONS AND TESTING
The next 2 weeks were used for iterating on designs and conducting virtual usability tests. We held daily check-ins with our engineering and PM partners as well as weekly design crits.
Summary of learnings:
After 4 more design iterations with reviews and tests, we landed on the final flow for single orders.
The associate splits one order into two trips at the time of Dispense.
The associate splits a batched order into multiple trips at the time of Dispense.
By the time we started crafting our final prototype, I worked with our PM and Data Scientist to come up with key metrics to track in order to determine the success of this new feature.
The release of this feature got pushed to the end of Q3 because of a new strategy roll out plan from the company.
When this launches, our team will pay close attention to the metrics listed above.
If you try to uncover all the use cases, you'll never ship. If you never ship, you'll never uncover all the use cases.
I read this somewhere online and it really resonated with me. For this project, we were spending a lot of time trying to think of every possible scenario that might happen.
While these are very important, it's better to not dig too deep or you'll waste time and design for cases that never happen.
It's critical to launch and learn once it's live.