Midpoint
A new Google Maps feature that calculates a central meeting location
OVERVIEW
Problem & Solution
Google Maps is a robust platform that launched its app for Android and iOS in 2008. As of 2020, over 1 billion people were using Google Maps on a monthly basis. Currently, Google Maps lacks a feature to determine where the halfway point is between 2 or more locations. When groups are planning a get together, they have to "guesstimate" where a good central meeting location is. This results in unfair travel times/distances for some group members and is stressful for the person(s) planning the event.
Midpoint is a feature that calculates the midpoint between 2 or more locations, taking into account mode of transportation and traffic conditions, allowing users to find a meeting location that is equitable for all group members.
Role
End-to-end UX / UI Designer
Product
Mobile app
Duration
80 hours - October 2022
Tools
Figma/Figjam, Whimsical, Google Slides
RESEARCH
Research Plan
I created a research plan to learn more about the logistics of meeting up with people and peoples' current usage of Google Maps.
I used the following research methodologies:
Competitive Analysis
A quick competitive analysis determined that none of Google Maps main competitors, Apple Maps, Waze, or MapQuest, have a midpoint feature. I did find a couple stand alone apps, Meet Between and GeoMidpoint, that can calculate the midpoint between 2 locations.
User Interviews
I conducted 2 user interviews to collect qualitative data and learn more about the processes people go through when picking a location to meet up with their friends. These interviews gave me insights into peoples' processes that weren't revealed through my user survey and were valuable when creating my user personas and feature set.
User Survey
I began with a brief user survey to collect quantitative data to use when determining the viability of this feature and which features would need to be included as part of my MVP. I referenced this data numerous times as I was brainstorming ideas, creating personas, and building my feature set.
As I got deeper into this project, I had a couple of instances where I thought "Man, I wish I would have asked that on my survey so that I'd have some data to back up this decision."
Some questions I wished I would have asked include:
-
Do you typically access Google Maps through your desktop or mobile app?
-
Do you have use an Android or Apple device when accessing Google Maps?
-
How long do you typically spend searching for a location to meet up at?
Even though I didn't ask these questions on my survey, I was able to find data online to help me make informed decisions.
DEFINE
Determining the User
Using my survey and interview data, I created 3 personas to reference as I began brainstorming ideas and determining my feature set. When creating my personas, I wanted to highlight 3 important differences amongst my users:
-
Mode of transportation
-
Typical group size when meeting up with friends
-
Location (urban vs. suburban)
.jpg)
Prioritizing Features
Utilizing the features that Google Maps already offers and referring back to my user survey, interviews, and personas, I generated a list of product features and organized them into four categories: must-have, nice-to-have, can come later, and surprising and delightful.
DESIGN
Developing Flows
I developed a user flow and 4 task flows to show how the Midpoint feature would work when:
-
creating a group midpoint
-
manually finding the midpoint between 3 locations
-
updating a starting address for an upcoming midpoint
-
searching for a coffee shop near the midpoint
These flows determined what screens I needed to include in my wireframes and prototype.
Wireframes
Before I started sketching out ideas, I spent quite a bit of time studying Google Map's UI and common patterns so that I could stay consistent with the brand.
From there I spent some time brainstorming ideas and making annotations on my sketches. I'd later use this sketches when developing my mid-fidelity wireframes.
If you're wondering, yes, I used white out on my sketches. Please don't judge me.
Component Library
Before beginning my high-fidelity wireframes and prototype, I created a component library following Google's brand guidelines and utilizing Material Design icons. Creating the components sped up my process of creating my high-fidelity wireframes and allowed me to make changes across multiple screens by updating the master component. This saved me a lot of time when it was all said and done.
Final Product
Introducing Google Midpoint
Stop wasting time trying to find a central location for your next get together and let Google Midpoint do the calculations for you. Calculate the Midpoint based on the time it would take people to get there or the distance they'd have to travel. Search the area around the Midpoint for the perfect meeting spot.
Don't know everyone's address or have a large group of people? No worries. You can send a Midpoint invite to people and let them input in their own address information.
In a rush or just need to find a quick meeting spot between a couple of places? We've got you covered there too. You can input addresses or use your phone's contact list.
TESTING
Mid-fidelity User Testing
Knowing that I was going to be adhering to Google's brand, my user tests were mostly going to be focused on the flow of my designs, not branding and visual design, which is why I decided it would be best to conduct a round usability testing at the mid-fidelity stage. Instead of creating a prototype in Figma using my mid-fidelity frames, I decided to create a Google Slides presentation. There were pros and cons to this decision, which I discuss further in the reflection section.
I analyzed my user feedback by categorizing feedback into 4 categories:
-
What worked
-
What needed changed
-
What questions users had
-
User ideas
From there, I prioritized changes based on their frequency and severity. This helped me focus in on the most dire changes that needed to occur before moving on to the high-fidelity stage.
User testing and analysis revealed that there were two critical changes that needed to occur before moving on to the high-fidelity phase:
100% of users struggled with adding another starting location. Originally, I had utilized the same mobile pattern that Google Maps has when adding a stop to a set of directions, which requires users to click "..." next to an existing address. This was highly confusing to users, so I decided instead to use the pattern that exists on Google Map's desktop version, which has "add a staring location" under the current addresses.
100% of users were concerned that they would not know or forget to input in their own starting address information when inviting friends to a Midpoint. They felt that sending the Midpoint to friends was the end of the task and didn't notice the "Enter your starting point" button that had appeared.
2.
1.
Prototyping
For my final round of usability testing I created my prototype in Figma to test if the changes I made after the mid-fidelity testing were successful and to get users overall impression of the new feature.
High-fidelity User Testing
I conducted 3 live usability tests on my final design. 100% of users were able to complete all 4 tasks, with minimal errors, showing the changes I made after the mid-fidelity tests were successful.
I made one additional change after this round of testing based on user feedback. Some users were reported confusion on how to update their starting address when viewing a Midpoint. Even though they were able to complete the task, I updated the screens so that the "Update location" button is disabled until a change is made to the address text field. Before, the button was active, even if a change hadn't been made to the address.
REFLECTION
Next Steps
While this project was about adding a feature to an existing product, I could see Google Midpoint becoming an entirely new Google app. Many users I talked to during my interviews were already asking questions such as if they could vote on locations near the Midpoint or if there were some sort of in app communication that would allow them to select a location to meet at. The addition of these social features, like being able to chat with your friends about spots near the Midpoint or voting on/suggesting locations seem like natural next steps, but also do not fit within Google Maps current structure.
I could also Google integrating this feature across its platform. For example, if a user creates a Midpoint it could easily populate into their Google Calendar or if users are planning an event through Gmail, then a notification could populate asking the user if they'd like to plan the event through Google Midpoint.
Takeaways
I came out of this project with three major takeaways.
There are pros and cons of what format you choose for your usability tests. I chose to run my mid-fidelity user tests using images on Google Slides rather than creating a prototype in Figma. I went with this option to save time so I could complete a round of rapid iterations. While keeping it low-fidelity did save me time, it also had some repercussions. For instance, even though I stated numerous times that nothing on the slide was clickable, every user tried to click on a text field to input in information which caused the slide to progress forward. The slide progressing caused confusion for the user, often resulting in them feeling lost in the task.
There were limitations to my prototype, which could have impacted results. Many of the natural interactions users have with Google Maps, such as pinching the screen to zoom in or out, weren't possible in my prototype. When users would view the Midpoint map, they'd ask why they couldn't see everyone's starting location. If the prototype were fully functional, users should have been able to zoom out from the Midpoint to see everyone's location. However, that just wasn't possible since I was working off of static map screens.
I really enjoyed working within a brand and utilizing their existing components. Since time was a huge constraint in this project, it was nice to be able to focus all of my time on designing a great feature that solves users problem without having to set aside time for branding.
1.
2.
3.