Delivery Buddy

REDMART | 2016
The goal of the project was to design an app that compliments physical operations and lets drivers do their work quicker and more efficient. The new software resulted in fewer shortpicks throughout with more pick ups in an hour. The result is saving up to 3% GMV in costs, approximately 20K a month.

WHAT I DID: User research | Data analysis | UX design | Wireframes | Prototype | User testing

context
SUPPLY CHAIN AND BEYOND
RedMart is a Singapore based online grocery marketplace offering a wide range of groceries and household essentials. It used to operate under a direct supply chain. All the goods were stored in the company's warehouse. A year ago, in the summer of 2015, RedMart launched a new service - Marketplace. It is now possible for independent sellers to list and sell their products on RedMart platform. Thus far it has attracted 300 sellers, which equals to approximately 20K more products. Problem is, warehouse space is limited. Marketplace strategy requires for a robust logistics system in place. Support by technology is paramount, as well as a constant process analysis and improvements.

There is an established logistics process already. Seven full time drivers (a number of contractors based on demand) are out and about every day. The process for them is straightforward: picking up items from shops based on the list they are assigned in the morning. In the evening all of the drivers are back to the warehouse, where they drop off the orders. Next day orders are packed and shipped for the last mile delivery to the customers. Lather, rinse, repeat.

UNDERLYING BUSINESS ASSUMPTION
Based on the last mile delivery data, the team identified that 5% of total cost of items not delivered, are coming from returns and wrong pick ups. Another 3% are caused by not scanned barcodes of the items.

ROLE
As a research/ UX person on the team, I was briefed to research into the problem and come up with an improved design for the logistics app drivers are using. My personal goal of the project was to meet the needs of the drivers and to prove to them they are heard. Also, to find a way to translate what I saw on the ground, to the team of engineers in the office. wanted to set a stone in a human-centered approach in the team, as most of the team members were too focused on the business requirements.
research
TRYING THEIR SHOES OUT
The logistics app drivers are using is called Delivery Buddy. It was designed for the last mile deliveries, but when the Marketplace came into play, it was adapted for pick ups as well. Before operations scaled up, the solution was working fine. But with the growing numbers, team discovered there is in need for a better technology.
WHAT DO THEY DO?
Spending time with the drivers helped me to map what is going on on the ground on top of the business data. I now was able to draw correlations between what a driver was asked to do, what he did and why and what were the results. Looking at the overall process, I was able to distinguish 4 main problem areas: safety, cognitive load, process issue, time not utilised.
WHO ARE THEY?
It is not only important to understand what they do, it is equally important to understand who they are. I did not want to create a generic persona. My goal was to communicate the feelz&pains of real people doing the job. Thus I decided to craft two robust personas and use a narrative form of storytelling.
WHAT DO THEY NEED?
When i discovered what they do & who they are, I was set to write user stories. It is a humbling experience to claim that, say, Darren wants to keep track of his performance, to be honest. But studying the end user made me really understand what they feel, what they want, what they don't want (equally important!), etc. Moreover, by building a rapport with the end user, I knew I can come back to chat with him, be there a specific question I forgot to ask.
design
ON-BOARDING THE TEAM
Now that I gathered all of the materials, it was time to synthesise everything into design. Here I want to pause and come back to the art of storytelling. Narrating driver's experience to the team in the office was hard, but the Action Map made it so much easier. I used the same technique to translate the research into the app architecture and flow. So I created a visual flow of the actions a driver has to make in the app based on the process. And mapped it in a step by step hierarchy.
WIREFRAMES
Finally I can translate a week of research, and a few weeks of back and forth of on-boarding the team. Not only I had to create wireframes, I also had to test it. That's why I made a decisions to not focus on B/W frames, and move to a more realistic looking appearance sooner. Like that, drivers would not be confused, and would be more likely to buy in the new designs I am offering.
test
FEEDBACK LOOP
I showed the clickable prototype to 5 drivers. It was a bit tricky to explain to them that a) that's a prototype and it is changable b) they can, and they should, voice over any of the concerns they have with it. I tried not to impose "the right way" to allow for the interactive experience to flow naturally. Despite few minor accidents along the way, like my phone crashing, and clickable areas all of a sudden becoming un-clickable, the test was productive. The drivers approved on the general flow of actions I proposes. They said it will take time to unlearn the way they used the app before, but they know it is for better. Some of the drivers voiced over (Hallelujah!) their concerns too. In their opinion some information should be more visible on the screen, for example tote number and address. One of the drivers chuckled as he was revealing he is color blind – a great point to be taken into account in the next iterations.
outcomes
The new versions of DeliveryBuddy is in use for approximately 6 months now. Business data has distinctly improved since drivers are using new devices/ new software. There are fewer shortpicks throughout, resulting in less returns/ non deliverable items. The software saves up to 3% GMV in costs, approximately 20K a month. Another outcome is that a driver spends less time per a pick up. He can send an ETA to a seller, so once the driver arrives, he does not have to wait for a seller to prepare the order. Secondly, the scanner in the device + intuitive flow of the app, makes it quicker for a pick up to happen. That means more pick ups per day can be done. To be exact, we achieved 4 more pick ups per driver per day. Which is great given that the operations are scaling up.
lessons learned
The personal goal of translating the research to the team was somewhat achieved. It took some time for me to find the right words to articulate observations and my thoughts, the materials I prepared helped a lot. There was a major hiccup in the handover stage. I was not able to communicate the importance of keeping the flow as I designed it to the UI designer. In the end of the day it resulted in delay of production and some friction inside the team.

Next time around UX will be separated from UI, to include the UI person into the research more than the rest of the team. Perhaps talking using design terms might eliminate the problem as well. It is my responsibility nonetheless.
 
Made on
Tilda