AboutBackgroundProblemChallengeSolution StatementObjectivesApproachKnowledge gathering and research App AnalysisInformation Architecture AnalysisSketching & TestingDeliverablesFinal Interactive Prototype
Timeline: 4 months
Roles: Design Ops, UX research, Interaction and Visual design
Worked with: Product manager, Software developer
Tools: Framer, Netlify
- One of the challenges that the driver operations team faces is ETA predictability. Routing service produces a priority list that drivers should follow. However, drivers are able to choose what to pick up first and can prioritize their own route. To many drivers this is a flexibility matter. To EatStreet, this is causing bad deliveries and fluctuations in ETAs which is leading to making less money per order.
- When drivers pick and choose their own routing plan it causes delays and ETA fluctuations and leads to upset customers where EatStreet loses money
- How to maintain the driver flexibility of choosing their orders priority while making sure customers are happy and EatStreet does not lose money
- Create an app experience that takes the guess work of finding best order priority and enforce the routing plan recommended by the system to restrict drivers' ability to pick their own routes
- Increase ETA reliability by removing the drivers' ability to go out of order, and have them follow the Routing directions instead
- Reduce the number of tasks that a driver can see in the app, ultimately reducing the number of decisions a driver need to make at a given moment
- Give drivers sight of their predicted future task
- Improve the visual hierarchy and information architecture of the app, and move towards consistent UI and colors
- After being briefed about the project, I started learning about the driver experience and workflow. There was no product manager at this point. I ended up talking to dispatchers, operations, data analyst, and developers to understand how things work.
- I shadowed a few drivers to observe their in-the-road and app experience. I took note of information architecture and visual hierarchy issues in the app
- I created a driver journey map detailing some of driver's daily experience. I shared it with the team. I added to it some feedback I gathered from driver research
Driver Journey Map v.0.1
Journey Map Before Sart Shift,Start Shift,Assigned an order(s),Drive to Restaurant,Arrive at restaurant,Pick up order from restaurant,Drive to diner address,Arrive at diner address Actions,Phone got internet (data). Charge phone battery. Locate card. Fill gas. Thermal bag. EatStreet gear. Has Ph...
I did a brief analysis of the existing app in light of user research. My observations were:
- Drivers had access to all of their assigned tasks, and their expectation was to pick and choose when to do a drop-off or pickup
- Drivers had two tabs between pickup and drop-off, which created the issue of missing an upcoming pickup task because the driver was only looking at the drop-off tab or vice versa
- The user interface was busy with many options to choose from, which made it hard to make a decision
- The user interface was not consistent and had a broad usage of colors (colors file in codebase has numerous color choices)
- I used the OOUX approach to break down different parts of the driver app. The approach helped me in analyzing the information structure of the UI. It also helped me with team alignment, as I used it to collaborate with developers and other stakeholders.
- I started sketching and wire-framing while in the knowledge gathering stage
- I went through few iterations, showing them to the operations and development team to learn if it is possible to build and if I had the right understanding of workflows
- I put together an interactive prototype in Framer and tested it with drivers to get feedback on information architecture and flow
- I refined the prototypes based on drivers' feedback and moved to building deliverables
- I created a design system consisting of all components used in the UI
- I gradually designed the main screens: Tasks, pickup and drop-off screens
- I defined the userflows as I was designing the UI
- I handed off the design system along with userflows. I coded (in React) main userflows as part of a guided prototype to let developers know the different use cases. I also showed developers the hand-off features in Framer. I used Netlify to share links with developers