Google Bike Maps

Mobile Cycling Navigation UX Case Study, 2/2

Existing Functionality

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

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.

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
Fig 3. Worth the ride

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.

  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.
Fig 4. Route tailoring is an important feature of the product

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.

  • 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.


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).



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

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

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