RIDER DEMAND HEATMAP
Role: Lead Product Designer
My first few months at Deliveroo were spent working on what we've called the 'Rider Intelligence Demand Heatmap'. Essentially, this heatmap helps riders make informed decisions about when and where to work in order to maximise their earnings while on the road. Without this, they'd have very little information about where they should go to find orders to deliver, and if it's even worth their time to go online right now.
Our goal is to support riders in finding the best places to work, helping them hit their earnings targets while delivering food to our customers on time (maximise rider earnings whilst reducing late deliveries). This piece of work was part of a holistic review of our operating model, and you can read about this in my design doc.
TLDR; Globally, 68% of riders were either satisfied or very satisfied with our new demand heatmap, and virtually all primary metrics saw a directional improvement, including rider earnings, late deliveries (down 1.6%), and delivery time (down 5.9%) ?
What problem are we trying to solve? ?️♂️
Riders are an incredibly important part of our 3 sided marketplace, ensuring food arrives to our customers on time, every time, and often being the face of the business. It’s our job to ensure we offer a compelling proposition to our riders, allowing them to meet their earning goals, and to work flexibly, whenever and wherever they want.
Flexibility is the main reason riders decide to work with us, so it's important that we allow them to work whenever they want. However, operating a 'Free-Login' model has its challenges. Firstly, we run the risk of having too few riders on the road, resulting in late deliveries and increased compensation claims from customers. On the other hand, we can have too many riders on the road which will reduce average rider earnings.
It was our job to find a way of moderating the fleet size so that we have just the right amount of riders online, at the right times and in the right places.
We gathered data to analyse the problem
This was a big project, spanning many different teams and with many stakeholders involved, from design and engineering to operations, comms, policy, legal, logistics and network algorithms. Our first step was to get all of these folks into a room to review the data we already had available, from data scientists presenting readily available reports about rider behaviour, and researchers presenting quant and qual insights from recent rider interviews and focus groups.
We analysed competitors
Our researchers analysed many of our competitors around the world, testing their products and speaking to riders to get their thoughts, both good and bad. This helped us identify areas of strength and weakness relative to our product, and also ways that we could differentiate our offering.
We prioritised problems to solve
Once we had reviewed all of the data and insights from riders, as a cross-disciplinary group we prioritised problems on a 2x2 matrix, so that everyone was aligned and agreed on the problems we should focus on first. We prioritised based on those that had the biggest impact on rider efficiency, and improving service for our customers.
Created a value prop canvas and rider persona
After gathering all of the insights we had, we generated a rider canvas (which became part of our value prop canvas for the rider product), and an experience map. This listed all of our rider needs, goals, jobs and pains, allowing the team to see which of these we would be able to impact.
Turning problems into HMW statements
With our prioritised problems, we created HMW statements for the workshop I ran the following day. We followed a LDJ (Lightening Decision Jam) framework for this workshop, allowing everyone to come up with ideas of how we could solve each HMW statement, before voting on the ideas we think have the best chance of winning.
Picking the ideas we should explore first
Now that we had a range of ideas for each of our prioritised problems, we needed to select the ideas we as a group think have the best chance of delivering against our goals. For this, we used another 2x2 matrix to map each idea in terms of effort to implement (both technically and operationally), and value to a rider.
Creating a Lean Canvas
Our prioritised ideas all had one thing in common; they rely on us having an accurate signal for current demand on the road. Without this, how could we confidently tell riders where the busiest areas are, provide estimated orders per hour, compare where they are to somewhere else, or working on a Monday evening to a Tuesday evening? Therefore, our first step was to create a brand new signal giving us reliable information about current order demand.
Helping riders decide where to work
Whilst working with the logistics team to establish a new signal that could be used to better predict demand, we started creating concepts for how we could surface this information in the rider app. I used weather apps as inspiration, seeing how they display upcoming rainfall and weather conditions on a map.
However, there were other constraints that had to be considered. At what granularity would we display demand? Over what geographical area? How do riders want to know about demand? Is it the same for all rider types (cyclists vs scooters vs cars)? How does demand differ in different towns and cities across the world?
Our early exploration explored different ways of displaying this information on the map, from heatmap overlays, to charts and graphs.
Validating concepts with riders
Our next step was to validate these ideas with riders. We ran multiple rider interviews in the UK, Australia, and Singapore, speaking to riders about how useful accurate demand information would be, how they want demand to be displayed on the map, how they want us to talk about demand (high vs low, quiet vs busy, good vs bad etc), and what else they'd need in order to work in a different place or at a different time.
Through this research, we found that we really needed to rebuild riders' trust in our demand information. A new signal alone wouldn't be enough to change their behaviour, so we'd need to do a good job of communicating this new and improved feature when we launch (I'll touch on this later). We also found that riders wanted to know average wait times between orders as an indication of demand (rather than orders per hour for example), so this is something we continue to explore.
Using hexagons to represent demand
After various rounds of testing and many, many iterations, we settled on a hexagon based spacial index to display demand on our map. I worked extremely closely with engineers to validate this concept and built prototypes to see how these hexagons would render on the map (and how low-end devices would render many hexagons across a city).
Building a heatmap out of many hexagons allows us to start with a broader view of demand (i.e average demand over a smallish area), and in the future have a more granular view of demand where each hexagon would have it's own demand level.
One of the many challenges we had was deciding how these hexagons would differ based on the demand level. Using colour to differentiate between low, medium and high demand seemed logical, as riders already understood this concept, and changing between purple and teal to represent areas with additional 'fee boosts' (areas where we're paying 1.2x fees for each order, for example). We had to ensure these colours were legible in many situations, such as in broad daylight, while cycling, in dark mode, and for riders with visual impairments such as colourblindness.
Demand at a glance
We also updated our 'area picker' so that riders could see demand of surrounding areas at a glance, helping them decide if they should travel to a new area for work.
Following a lean approach, our focus was learning something valuable as quickly as possible. We wanted to know how riders would react to our new demand signal and if this would change their behaviour in any way. Therefore, we scaled back our more visionary designs to deliver something compelling for our MVP. For example, our MVP would show demand at a 'zone' level, rather than at a restaurant level for now. We'd also only be showing live demand, rather than predicting future demand. And finally, we'd only show demand for your current area (although you can change your area using our 'area picker') as low-end devices couldn't render more than 500 hexagons on the map at any one time.
Here's a short video of our MVP, which is now live to a subset of riders so that we can see if it achieves our success metrics. We'll be analysing the data and getting ongoing rider feedback throughout this experiment phase.
Communicating the new feature to riders
It was super important that we effectively communicated this new feature with riders, for a few reasons. Firstly, they use this app all day every day to make their living, so any changes need to be clear and obvious to them, ensuring they understand why we've made these changes and how they can use them to better their time on the road, and secondly, to help rebuild their trust in our demand predictions so that they begin working in areas with high demand.
Here's the email I designed alongside a content strategist, which was sent to riders the day before the feature was released.
Our research unearthed a load of other ideas that we plan to explore after the results of our MVP have been analysed. Some of these I've mentioned above, such as restaurant-level demand and showing demand for surrounding areas on the map, but riders need additional information when deciding to travel to new areas. For example, learning about the roads and restaurants in that area, knowing if there's adequate parking, getting tips from local riders in this area, or perhaps being rewarded for working in new areas. These are all concepts that we've explored with riders and plan to develop further over the coming months.
We also plan to continually improve the accuracy of our demand signal based on our experiment deep dive, which showed that including rider vehicle type could provide clearer information to riders.