This is the 2nd part of this case study, you can find the first part here. where we talked about how we came to the problem and defined it. in this part, we are diving deeper into Design Thinking and Ideation.
As you know from the previous part of this case study we have found several problems, and though-out our prioritization matrix we have decided to investigate furthermore some tickets before jumping to any conclusions. Before we dive into the problem we really need to define it, in the discovery phase we have identified that we have a problem with the departure address since we had multiple research techniques are pointing to the same aspect of the product but, it still vague. Now we need to answer the following questions to accurately identify them:
- Who is the most affected by the problem?
- What is the effect on the users?
- What are the effects on the business?
- and, What are the opportunities if we fixed this problem?
Who is the most affected by the Problem?
Pip Pip Yalah has multiple personas but, our major persona is called the employee persona. It’s self-explanatory, the majority of our users are employees who work in the big city and they usually use the app to help them to get from home and to work thus, it’s important for them that the rides are on time so, they can make sure everything is working perfectly.
But, what’s more, interesting than most of our drivers and passengers as we have learned from the previous research, they’re motivated by 2 factors, the financial benefits, and the transportation benefit. Those two factors help our users to travel faster and cheap while making extra money or even saving some money. When the passengers start booking multiple offers it will eventually block the offer for the other passengers since the ride is full. which will limit the other passenger’s reach. Besides that, most of the passengers tend to forget to cancel the rides which they have booked trying to discuss the departure address with the drivers which, causes the drivers to lose money and passengers since their ride is full and it’s not reaching other passengers neither the passengers are coming to the ride.
How does it affect the users?
From the previous research, we have been noticing this problem with departure address and how it’s not clear for our passengers but, we wanted to dive deeper to understand why this is a big pain point for our users. So we sent surveys for both the passengers and the drivers asking them about the product and the booking progress. Then, we picked the most interesting participants and set an interview with them. our goal was to understand the user mental model by asking them more questions about how they book their rides?
Based on the Survey answers we have chosen some users to interview and ask them more questions. for example here is a dialogue from one of the interviews:
Facilitator: What do you look for in a ride before booking it?
User: The first thing I look for when booking a ride is the departure address, Casablanca is a big city. I always face the same problem, if the address isn’t clear, the moment I book and get accepted by the driver I immediately discuss the address with the driver, If doesn’t work for me, then I cancel the ride.
Facilitator: What happens when you forgot to cancel the ride?
User: Once I get accepted I call the driver, why? because of this timer, I try to validate those points quickly, to be able to cancel. if we don’t agree on something before the timer runs out, I will cancel the ride, so I don’t get charged.
Facilitator: But, lets assume that the timer run out and you didn’t agree with the driver, what would you do then?
User: In that case, I will let the drive know that I’m not coming and he can cancel my ride from his side.
What was really interesting is we found out that the majority of the Passengers we interviewed didn’t understand how did the system work but, even though that doesn’t justify why they aren’t understanding the address’s even when we asked them if they know what is the departure address. on the other hand this resulted into getting lots of the passenger banned or blocked from the app because; they kept booking and not canceling the rides since they thought that simply by telling the drivers that they are not coming as if they have canceled the ride. This creates more pressure on the CS (Customer Support) team and limits the driver’s offers reach since their rides are full.
What are the Effects on the Business?
The question is, what are the effects of those multiple bookings on the business, to know the answer we started looking at some charts such as LTV, Churn Rates, and the cash flow statements, What’s interesting is all of those multiple bookings are inflating our numbers but when it comes to the Ride completion rate you can see the problem. It’s causing the business to lose so much money since lots of people are not even reaching where they want and that’s because the rides are full and the passengers didn’t cancel their bookings correctly which leads to fewer bookings for the drivers, of course, this causes us to have less available cars which result in unhappy passengers leaving the app.
We have noticed that when we started this discovery phase the stakeholders were complaining about how the booking ride rate is high while the ride completion ratio is lower than excepted which caused some concerns.
What are the Opportunities if we Fix this Problem?
There is a great opportunity here when this problem is fixed, creating a better booking process and fixing the departure address will not only kill the multiple bookings but what’s important it will increase the completion ratio which in return will increase the business revenue, and most importantly helps us to resurrect our old users.
As you can see from the User statement from the usability testing you can tell that the user sometimes has to book multiple rides so he can make sure that the address works for him, which causes the ride offers to get full by the same passenger taking seats from other passengers, whom sometimes don’t cancel the ride causing the company and the drivers to lose money in the process.
Now after, we have a clear problem statement it’s time to start diving deeper to understand what’s causing this vague departure address to be produced and, if this problem is being generated by our users? or is it because of a failure of technology?
What’s Behind the Tech?
So, the first thing we wanted to investigate is how do the drivers select their address therefore, we did some usability testing with 5 drivers to see how they select their address and, how accurate they can select the address. Shockingly what we have found out that there is no problem with generating any address. In fact, they could select really accurate places down to the street.
So we thought maybe it’s a problem with the API and it’s not working correctly, after I have contacted the technical team to do some testing on the Google Maps API he made sure that there are no problems as well. So at this point it was time for us to understand how did google generate those addresses and are they even readable or to be more accurate are they even relatable to our users? So, what’s the best way to understand an API and how does it work more than their documentation itself.
The Google Maps API
The first question that come to our mind was how does google find us on the map and to understand how we have to dive deeper into those 2 concepts Geo-Location and Geo-Coding.
Geo-Location
In the beginning, we need to understand how does google finds us? Google uses an API called Geo-location. The Geolocation API returns a location and accuracy radius based on information about cell towers and WiFi nodes that the mobile client can detect.
From the definition of the API, we would understand that google would calculate my location using Tower-cells, Mobile radio waves, wifi access points and, mobile clients. after they have selected the closest point to my mobile they will determine my location using Triangulation measurement method to generate my coordinates.
A successful geolocation request will return a JSON-formatted response defining a location and radius.
- Location: The user’s estimated latitude and longitude, in degrees.
- Accuracy: The accuracy of the estimated location, in meters. This represents the radius of a circle around the given location.
But, how does google translate those latitude and longitude coordinates into human-readable address’s? Well to understand this concept we need to dive deeper into the Geo-Coding API.
Geo-Coding
Geocoding is the process of converting addresses (like “1600 Amphitheatre Parkway, Mountain View, CA”) into geographic coordinates (like latitude 37.423021 and longitude -122.083739), which you can use to place markers on a map, or position the map.
Reverse Geo-Coding is the process of converting geographic coordinates into a human-readable address.
So far, we figured out how google finds out your location, and how does google turn those coordinates into readable human address. But, we still have one question how did google know what is the name of those addresses?
Google Map Makers
The way google did it, was by out-sourcing data for most developed countries from various organizations, including national governments and governmental agencies. A list can be found here: Legal Notices for Google Maps/Google Earth and Google Maps/Google Earth APIs and For the rest of the countries, they relied on local users who would map out road and place features on the base satellite imagery through an online tool called Google Map Maker. P.S: this program has 2017, and many of its features are being integrated into Google Maps.
Problem Framing
At this stage of the research, we started to hypothesize that maybe the users can’t relate or understand the departure address simply because they don’t know them. so we have decided to validate this hypothesis by doing feature user testing.
User Testing Insights
We started by asking our users to perform a few sample tasks, and we used our old usability testing data as a benchmark to measure the performance. We told our participants to perform the following tasks:
- The Moderator provides the users with a randomly generated address from google maps API and asked them to find it on google maps without typing it.
- The Moderator provides the users with a random location on the map and is asked to describe the location to find it on google maps only using the user instructions as in Words.
What shocked us the most was that our user mental model for reading the maps was completely different than Google Maps API. As we have learned from the API documentation google maps uses the address names generated by the government or the address’s acquired by the google maps maker program. The problem with those two is that they are not popular among our users which has created this HUGE conceptual debt where users can’t read the address.
What we have realized is that most of our users tend to describe addresses in a specific way. Users would start from big names such as well-known places or, locations then; they start narrowing down to neighborhoods names but, after that, they would start giving directions instead of using the names of streets since it’s not really popular or wildly used.
Ideation
As the problem started to become more obvious to us it was time to start ideating a solution, we began our ideation session with the crazy 8’s, our goal was to generate ideas as much as we can and create those Lo-Fi wireframes to demonstrate those ideas. Then we started voting the ideas that we thought would be the best fit, after that, we companied the most voted ideas together. we kept in mind that not only do we have to design the method the drivers select the departure address’s but, we had to think about how can we make it more relatable to the passengers as well.
The question was how can we change the way we present data from the Google Maps API to make it easier for people to understand the departure addresses. what’s interesting is how people describe address’s or, read them as we have noticed throughout the research. For example:
Starting from City then, Neighborhood then, a well-known area in a Neighborhood could be a street or, Circle. but in our case, the name of the streets are not known to people since nobody uses them because; of the lack of infrastructure (in my opinion), which has created this huge confusion and friction for the users.
Lo-Fi Wireframes
Note: in this section, I am going to be showing the final results for the ideation.
While we were working on a solution what we have noticed from the User research was that the users don’t care about an exact address. Instead, they are looking for something close to them since they will communicate with the driver later on to decide the meeting point that works best for them but, they need to find the closest departure point to them to save time and effort.
The Driver Side
So we started by redesigning how would the drivers select the departure address’s as we have learned from our research users can recognize neighborhoods easier and faster than street names so we designed our departure address selecting method is based on 3 steps. you choose the city, then the neighborhood, then you have the freedom to drop the pin anywhere inside that area. we realize that would constrain the user freedom and control but, this way we can unify the produced departure address where everyone knows them.
Passenger Side
The first thing we wanted to do was to understand what’s important for the user through his user flow and we have found out through our usability testing that the information which the user is seeking keeps changing from a phase into another, which will help us to prioritize data more. Also, we have been working on how can we present those addresses in a more relatable way to our users to make it easier for them to read while creating a clear button that helps users to switch to google maps App. as we have learned from the usability testing and how users priority shifts though out the stages we wanted to shift the focus on the data by design as you can see from the images below.
We Prioritized the name of the city on the search results page But, as soon as you choose a ride we have changed the size of the prioritization from the city into the neighborhood which helps the user to estimate the departure address easier even if he didn’t know the name of the street. This will help our users to make their decisions easier without booking multiple rides, at this stage, it was time to start testing this Hypothesis to find out if it works.
Validating the Hypothesis
Now, after we have designed our solution it was time to build the HI-Fi wireframes and prototype them for quick testing before moving into development. We have created an unmoderated test providing our users with 5 tasks to see how our users will perform, our benchmark is the results from the previous tests we did for the old version. in our case we cared about Error rate, finding the correct address, and time spent on the task.
After we have sent out our test to the sample size, we have got our results back, it was promising since we have got a success rate for finding the right address above 88% and the time spent on tasks was lower than the benchmark also, we have noticed few problems here and there. Definitely, we went back and fixed them and tested them again.
Conclusion
Sometimes people report the symptoms of a problem, instead of the root cause. this means we can’t only rely on what people tell us. I take this statement to heart because if you don’t dig deep enough into a problem you will only be solving the symptoms of the problem costing you more money. but, what scares me the most is that unsolved problems with time start to reshape the users mental model and at the end of it, it might end up as a conceptual debt that could kill the entire company, if you are not careful enough UX Debt is worst than Technical Debt.