Expanding Functionality for Drivers at EatStreet
Optimizing the driver experience is one of the most important jobs of the design team at EatStreet. When the company decided to expand into grocery delivery, a new experience within the driver app was needed. This project covers my process as the lead UI designer from start to finish.
Previous Experience
Scoping the Problem
EatStreet drivers were not equipped with an interface that allowed them to efficiently pick groceries for a customer. The previous grocery delivery experience for drivers consisted of a quick-fix solution that was shoehorned into the restaurant delivery experience. This did not take into account tasks like finding items in a store, dealing with out-of-stock items, and paying for an order.
Digging into UX Deliverables
I worked with a designer who focused on initial UX work on this project. After defining the problem with them, they put together a happy path user journey and explained it to me to better paint the picture for the UI phase of the project.
Defining Scope and Determining UI Needs
From the user journey, I realized that the only stage of the driver journey that needed to change for grocery orders was the Gather stage. In the eyes of a driver, the Go, Arrive, Deliver, and Drop Off stages are the same regardless of the order type, so I knew that my focus for UI work needed to lie in the Gather stage.
After figuring out what I would be working on, I put together a user flow so that I would have a defined scope for the project.
Additionally, I listed out each component that would be needed based on the user flow.
Improved Experience
Wireframing
I started by building some initial wireframes to slightly increase the fidelity from the list of components. At this stage I was able to conceptualize the functionality of the componentry. The main task flow for drivers while in the Gather phase for grocery shopping is reading which items are needed, finding the item in the store, and adding the item to their basket. The interface needed to reflect this flow, so I knew I needed a pattern that allowed drivers to move items between different buckets: items yet to be found, items that had been found, cancelled items (due to being out-of-stock), and found items.
To achieve this pattern, I built a system where an item in the list could be selected and moved to a different tab with a sticky control panel.
Beyond the functionality of the interface, the most important part was the design of the cards in the item list. There is a lot of information to squeeze into a small footprint, so efficiency is the name of the game.
Another flow that had to be designed was the Get Started flow. Before starting the shopping process, drivers must set a Shop Time. This is the amount of minutes that they anticipate the shopping segment to take. Additionally, they have the option of sending an introductory text to the customer so that the customer is aware that the driver is shopping and may have questions for them.
The last piece in this phase was the payment flow. Because the driver is doing the shopping, the interface needs to give them the ability to check out like a regular shopper. Once all items had either been moved to Added or Cancelled, the control panel would show a button that allowed the driver to continue to the payment. On a new screen, the driver would see a summary of all of the items, the expected price, and instructions for how to use their company card to pay.
Moving into High Fidelity
The driver app had an existing-but-sparse style guide before I started this project, so color and typography were inherited from that as I moved into higher-fidelity versions of the components. When it comes to designing new UI in high fidelity, I use the atomic methodology. For this project, that meant that each screen (organism) needed to be broken into components (molecules), each component needed to be broken into individual pieces (atoms). Generally, this allows for a more streamlined and controlled approach to design, and it makes applying design system standards much easier.
At this point, all that was left was to put the atoms together to form molecules, put the molecules together to form organisms, and make any necessary adjustments.
Final Flows and Handoff
Now that all of the organisms had been made, I needed to put them together into flows for shipment to the engineering team and product management.
First, the Get Started flow: the first set of actions a driver must take when starting the Gather phase of a grocery order.
Next, the Shopping flow: drivers use this flow to work the order. As they find (or don't find) items, they use the control panel to move them into their respective tabs. They can also adjust the shop time as they go if their initial estimate proves to be inaccurate.
Finally, the Payment flow: after collecting the items, drivers use this flow while they pay for the order.
Special thanks to my teammate on this project, Abdul Jarallah.