Google Bike Maps

Mobile Cycling Navigation UX Case Study, 2/2

This case study is the second in a series exploring cycling navigation in a mobile app environment.

In my first case study, we explored a public route browse and search feature in the popular fitness tracker app, Strava. The features I discussed there would be primarily useful to cyclists who want to find new ways to enjoy cycling recreationally.

That said, there is a sizeable majority of cyclists who use their bike foremost as a means of transportation, whether it be to/from work, school, the grocery store or the light-rail.

For those cyclists, Google Maps already provides one of the best tools around for navigating from Point A to Point B, but there have been very few changes or updates to the tool since its initial release. I believe it is a useful enough product to deserve its own standalone app. This case study explores what a dedicated Google Bike Maps product might look like, and how it can improve over the existing functionality, paying particular attention to the needs and wants of urban cyclists.

šThe app provides more options for customizability on-the-fly, as well as providing more detailed route information. The product would be built off ša community of users to continually improve the quality and relevance of information.

Existing Functionality

As I mentioned, šGoogle Maps provides one of the best on-the-fly cycling directions functionality currently available

When the user inputs their origin and destination, the app responds with three options for the user to choose from, but only provides elevation and time data. But there are some notable pieces missing.

For one, information on traffic levels or speed limit are not provided. It only takes a cyclist a half a mile on a busy 45mph road (with or without bike lanes) to see why that is good knowledge to have. Therefore, the user must rely on personal area knowledge to select the right route for themselves from the selection given.

šAlso, unfortunately, while there are handy green road markings denoting which roads have bike lanes, or painted “sharrows”, the blue route highlighting obscures this vital bike lane information.

While it’s nice that Google Maps offers three potential routes, we don’t know what kinds of parameters are privileged by the šalgorithm behind the scenes, and the user has šno ability to change these parameters (ši.e. “Avoid busy roads” or “Avoid steep hills”); the sole route parameter given to the user is “avoid ferries”.

Needless to say, there remains a lot of functionality that could be unlocked to provide a much more robust tool for cyclists on the go.

Fig 1. Google Maps provides options, but not many

User Persona and Use Case Scenario

Before starting to develop my improved Google Bike Maps product, it’s important to consider the needs of the eventual user of the product. For this case study, I created one user persona, synthesized from real people I know that would get a lot of value from Google Bike Maps.

Evie, urban cyclist, age 26

a woman rides a bike over a metal bridge. the sun is shining brightly
Fig 2. User Persona, Evie
  • šYoung, female, progressive and active
  • Comfortable on the bike
  • Recent transplant to Seattle
  • šUnfamiliar with traversing the city’s confusing, hilly streets
  • šIntelligent, comfortable with technology
  • šDoes not own a car, commutes across the lake to work at Microsoft
  • Prioritizes experience and safety over efficiency
  • šShe is tired of getting lost and being glued to her phone on a ride
  • šEnjoys a feeling of being “disconnected” while on the bike

A Quick Ride to the Bakery

I then conceived of a possible use case scenario for the hypothetical product from the perspective of our persona, Evie.

Fig 3. Worth the ride

šEvie wants to visit a brand new bakery that has opened in South Seattle, roughly 6 miles away.

šShe pulls up her Google Bike Maps app to determine the best route for her to take.

šShe wants to get to the bakery ASAP before they close.

šShe wants to take it easy on the way back.

šThere is a need to find a safe route from Evie’s home to her desired destination. Safety is a priority in every circumstance.

šFeeling unsafe or stressed from car traffic leads to an extremely negative experience.

šEvie also expresses a preference for efficiency/speed (though with safety as a given), avoiding circuitous or “scenic” routes, or including steeper hills

She values robust, audible and succinct turn-by-turn directions that are designed with bike riding in mind.

Wireframe + Clickable Prototype

I used this scenario to generate some vital features and incorporated those into low fidelity wireframes and a clickable prototype. These are meant to demonstrate how a user might proceed from input to navigation, while focusing on the expanded customization aspects of the product.

The degree of customization promised in the product brief posed two main challenges:

  1. Demonstrating the drag and drop map functionality using clickable static wireframes would be difficult; this functionality follows a proven method used in the Desktop version of Google Maps for web. I decided that demonstrating a proven pattern would be more time consuming than its worth.
  2. Demonstrating the high degree of slider-based customization afforded the user would require numerous static wireframe states. So I decided on a compromise between labor time and prototype fidelity. By providing several in-between states that are less than accurate at every iteration, I could still offer a sense of feedback in the direction of the user’s customization, albeit with narrow final outcome states. Consider Robert Frost — “The Road Not Taken”. The user is less likely to see or compare as many outcomes, so it’s only necessary to give the user a taste of customization that would be present in the final product. Their imagination can fill in the rest.

Static Wireframes

Fig 4. Route tailoring is an important feature of the product

Clickable Prototype

Lessons Learned + Further Considerations

Start with lower fidelity prototypes, but with clickable prototyping software it makes sense to incorporate aesthetic considerations at the clickable phase.

The next aspect of the product UX to consider is the display of information on the map:

  • How to capture hill gradients, and less tangible aspects such as “bike-friendliness”
  • How to display bike route markings on the map without the highlighted route obscuring them
  • Differentiate between bike paths, sidewalks, golf-cart tracks and stairs, while also allowing their integration into the route upon request.

Conclusion

Though Google Maps already offers a baseline useful navigation tool for cyclists traversing the city, it’s not difficult to conceive of several crucial features that would elevate the app to an imminently improved experience. Furthermore, I think they are sufficiently specific to the cycling context such that it makes sense to spin the whole service off into it’s own dedicated app package, as part of a larger Google Maps product suite (imagine Google Earth and USGS TOPO map viewing as additional services).

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jonathan McCurdy

Jonathan McCurdy

Seeing and tasting the world via bicycle. Designing fun and usable products and currently open to new work opportunities! www.jonamcc.com