Order status
A crucial part of using a delivery service is the waiting and tracking of your order. During some time at PedidosYa I was part of the team entrusted with improving this experience for our customers through comms and updates on their orders progress and whereabouts.
This journey, in some how, is a story we need to tell our users step by step while they wait anxiously for their order. And all of this happens on a single screen we call Order Status.
📱 The OS screen
The main goal of the Order Status screen is to inform our clients about three aspects of their order: what is going on with it?, where is it? and when is it arriving? In the course of 20–25 minutes (our average delivery time) we must always be able to answer these three questions in order to calm the anxiety of our users and meet their expectations.
When things go south and we fail doing so, users try to get answers by reaching the Help button and chat with an agent. We track the usage of this button (Contact Rate) in order to measure the effectiveness of the OS screen.
Focusing on its UI, the key elements on this scree are:
- ETA: the estimated time of arrival of the order.
- Progress bar: the steps needed to deliver the order.
- Map: GPS tracking of the rider.
- State: the current situation of the order.
🧱 Rebuilding the screen
One of the first task we had on the team was to rebuild this screen from scratch, which was inherit from the start-up days.
It had several hierarchy issues on how it displayed the information and put focus on its elements, clearly reflected on the high Contact Rate of the orders even though they didn’t had any significant delivery issue that could cause it.
The main pain points we detected were:
- Everything was almost at the same level of hierarchy. For instance, it didn’t put any focus on the ETA or the Map (accessed by a text link View map), which are the main pieces of info that answers the where and when questions.
- There were two “time lines”, one horizontal and the other vertical. Talking with some users we learned that it was not clear if both were showing the same progress or if they were separate things.
- The Help button was not always reachable, depending on the height of device. At the same time, the Order Details button had more presence on the screen while having less value to the user through this process.
Beyond any doubt the screen was failing on telling the story to our users, leaving them uncertain about the state of their orders. We needed to redefine how our story and UI was structure so our users could understand what was going on with a simple glance on the screen.
Getting the user POV
In order to carry on this “reboot” of the experience, we needed to understand how our users lived this waiting: what are their concerns? how do they imagine this process is like? what stages they identify?…
First we interview some users to identify behaviors and patterns on them. Doing so we discovered the three main steps they recognized on the process: confirmation, preparation and delivery.
The first concern of customers after placing the order was to get the confirmation by the shop. Due to some past bad experience they had, getting this confirmation was some kind of relief and assurance that the order was on track. During this stage they were mostly anxious about receiving the push notification informing so.
After being confirmed, users understood that the order was on the hands of the shop and that there was little on what we could inform about. They percibe this stage as some kind of “blind stage”, leaving them focused on the time of arrival (ETA) in case it changed.
When the rider picked up the order the focus of our users shifted entirely to the map. They kept following rider to assure they were heading in the right direction, and get ready when it was arriving. Even though the ETA on screen now was seen as more reliable than later, it was not as important as the map.
Telling the story right
After gathering all insights and learnings we rebuild the story told and the UI of the screen, focusing on the main events and elements they needed in order to follow through this wait. The new flow now was structured like this:
- Processing your order — the first step is to handle the confirmation issue sending a push notification as soon the shop confirms the order.
- The shop is preparing your order — in order to solve the blind stage we split this step in two: first we assure the order is being prepared by the shop, and later we create a new state (next step)
- The rider arrived and is waiting for your order — we take advantage of this information that we have at our disposal in order to give our users a reliable update on their order and show progress on it.
- The rider is on its way — knowing that the main focus is the map, we focus on it at full view, sending a push notification when the rider is nearby as a friendly reminder for them to get ready.
- Order delivered — after the rider confirms the order as delivered, we take the story to an end.
Beyond the new additions, the two majors changes were in this deleted states:
- A Searching for a rider state was deleted, as it left users anxious about why it was taking so long to get a rider. This process still happens but on a backend ground during the Processing your order.
- A The rider is about to arrive state was deleted too as users understood that this was already part of the The rider is on its way, it was not seen as a different step. With the push notification was enough to give this update.
Setting the focus
We needed to redefine not only the story told but the UI as well, and now we knew exactly where to put the focus on. The majors changes on the UI were on these elements, in order of hierarchy:
Map: As a delivery service location and tracking are at the base of the experience, therefore, we knew the map should be our canvas where the whole story was told — answering the where question — . All other information was floating above on a bottom sheet.
Also, as we learned with users, the map is not where they focused through all the process, and for this reason we decided to hide it and expand it as needed depending on the stage of the delivery process.
ETA & Status: These two elements are the ones that answer the what and when questions, and users relay on them most of the time regardless the stage they are. Knowing this, now we display them big and clear and are at the top of hierarchy next to the map.
Progress bar: Right below to the status, we simplified the two time lines issue on just one progress bar that marks the progress already taken.
As on how we display these elements, we tested different formats for the ETA and the Progress Bar. Regarding the ETA we learned that the existing one was the most accurate through most of the process, but it was also favorable for users to see it as a countdown at the end when the rider was about to arrive at their door. So at that last part of the process we change from time-range to time-countdown format.
On the other hand, the Progress Bar, we tried stepped lines and continuos progress bar. The continuos bar was the least preferred as users didn’t see any reference to how many steps had happened already or has to come yet. The stepped line was chosen in most cases, but the one with longer steps left users uncertain about why was this steps taking longer than others. The winner was the bar with 4 even steps, reflecting the steps needed in the delivery but not leaving users anxious or preoccupied.
Results
When we had our proposal for the new OS screen, we first tested it with users in deep dive interviews where we simulate an order delivery and went step by step of this process. Users had a positive response for the new design finding it easy to read and follow through, changing only small details on the copy.
Latter when AB-testing this new screen on live, the quantitive results were also favorable leading to a drop on the contact rate, specially in moments where we were not giving any new information but just displaying it different. This made it clear that the big issue here was how we were displaying all this information, rather than the information itself.
💬 Final thoughts
The OS screen was failing at a UX level by not helping our users to follow through this process. Even though there were no issues, we were not being clear and they couldn’t understand us. The two main tools that helped us solve this were the use of hierarchy and getting the user’s POV of the process:
- Hierarchy is the invisible force that articulates and binds all elements towards one goal. In this study case, big part of our problem was due to the lack of it on the UI and not knowing where to put the focus on.
- In order to tell a story you need to know your audience: know how they talk so you can chose the best words; empathize with them so you can tell them what they need to hear; and make it reliable so they engage with it.
