Bikemap Route Planner

Ideation and Design

AB Planner

Examining the old AB Planner reveals distinctive elements. Notably, a top navigation bar stands out for its visual clash with the content beneath, exuding a more modern aesthetic than the tool itself. Positioned on the left, a substantial block hosts two input fields for address entry, while the right showcases a map centered on Frankfurt am Main. Three buttons, labeled “Bike Paths,” “Heatmap,” and “Bikemap Basic ▾,” grace the top right corner of the map. The chevron on the last button hints at a menu with additional options, encompassing various map styles. Activating the "Heatmap" button generates a visualization of the most frequented roads by Bikemap users, with the "Bike Paths" button highlighting cycling paths in red.

The focus for the new web app centered on addressing specific issues:

1. The top navigation bar's excessive space usage without substantial utility required optimization.
2. The "Search for routes in…" input field's potential to cause confusion by diverting users away from the planner tool.
3. The dated UI colors demanded a refresh.
4. The lack of control over map styles, preventing customization or updates, needed attention.

The Legacy Route Editor

Now, shifting focus to the Route Editor – it's not as seasoned as the AB Planner, boasting a more modern UI. The map flaunts muted colors, lending a cleaner overall appearance. Positioned on the left is a vertical row of buttons, each serving multiple functions: a geolocate button to center the map on the device's location, toggles for generating routes along roads or drawing manually, an eraser, options to return to the origin, reverse the route, undo and redo actions, and a button for adding Points-of-Interest. Adjacent to these buttons, there's an input field facilitating movement of the map view to any global location. At the bottom left, zoom, rotate, and full-screen buttons wrap up the toolset.

The center of attention is the map. Crafting a route involves a simple click on map locations. This feature shines, especially when planning a trail ride in nature, far from the beaten path. Just zoom in, drop points manually, and you're good to go.

Now, let's dive into what we aimed to tweak with the new web app:

1. The input field – it's missing the magic of turning into a waypoint, just relocating the map to the entered spot.
2. Editor map styles – they're ours, and they're staying put.
3. Those vertical buttons – not as obvious as we'd like them to be.
4. Toggling between drawing mode and “follow streets” – easy for the experienced, but new users need a clearer grasp of the differences and use cases for each mode.

Initial Designs

Let's delve into the initial designs exploration. We were essentially testing the waters, considering the feasibility of merging all features into one tool. On the left, you'll find the address input fields borrowed from the AB Planner. Directly below, there's the reverse route and a "back to origin" button inherited from the Route Editor. Additionally, a plus button allows users to add more waypoints to the route. Now, the noteworthy addition – the routing profile, or as labeled, "Routing Options." This feature assists users in customizing their route generation based on preferences and constraints. For instance, road cyclists may want to steer clear of gravel, parents might prefer routes with minimal traffic, and commuters may opt for the fastest route.

Stats Section

The Stats section provides data about the route, including distance, ETAs, average speed, and elevation data. Essentially, it functions as a fitness tracker for biking adventures.

Interesting Places Along the Way

This section presents a list of Points of Interest near the planned route. Some users expressed difficulties in finding interesting spots between their starting point and destination. They had diverse needs, ranging from including supermarkets or water sources for hydration to seeking inspiration for scenic detours, food options, and accommodations.

Lastly, there's the "Search Place or Address" input – a minor typo slipped through. It was adopted from the Route Editor, but after realizing its limited utility, we decided to remove it. Users generally preferred using the waypoint input fields for place searches, anticipating the map to respond accordingly. Simple and efficient.

Testing and Validation

• We tested every design iteration with internal users
• Some designs were tested external users
• We used “Maze” to test our prototypes with others. The tool helped us to understand the paths our users would take, moments where they would get stuck and we would even see how long it would take them to complete a task.
• We had a beta phase in which users could use the old AB Planner and the new Web App in parallel before we would sunset the old route planner
• We found in our early prototypes that people really appreciated the idea of seeing points of interests along the route. We also found that it would be a bigger effort to implement. As a product manager, I had to remove it from the project scope since it was not essential to the core functionality of the tool and the original vision was to become independent from third party APIs.
• We found that users like to see the stats of their route but the would not open the accordion to see the data if it’s minimized on default.
• Some features like reordering the waypoints, deleting and changing the routing from “Follow Streets” to “Beeline” and back were only visible when users would hover over or click on certain elements on the interface. Users were able to intuitively discover those features when they were presented with the related task.

Implementation and Development Journey

Given the extensive scope of the overall project and commitments from both backend and frontend development teams, I strategically divided this initiative into several epics:

1. Initial Epic - Web App Setup:
   The first epic aimed to establish the development of the web app under a new domain (web.bikemap.net), incorporating a frontend component library and necessary technical groundwork. We iteratively collaborated between design and development for the component library, identifying, defining, and implementing components with thorough checks and approvals.
2. Legacy AB Planner Reconstruction:
   Another epic focused on rebuilding the legacy AB Planner without introducing new features. This was a vital step as the legacy AB Planner had significant dependencies on external services. To swiftly address this, we chose to eliminate these dependencies promptly. The initial web app iteration intentionally mirrored the existing AB Planner features.
3. Import Tool Transition:
   A task within an ongoing epic involved moving the import tool, already in development, to the new design and the new web app domain. With a pre-established component library and user flows, this transition was seamless.
4. AB Planner Replacement:
   An epic centered on replacing the legacy AB Planner with the new web app. This move was crucial, not only for introducing new editing capabilities but also for ensuring that newly created routes could be re-edited within the new tool. The transition also addressed the confusion caused by the previous system, where routes could only be re-edited using the Route Editor.
5. Routing Profiles Addition - A Quick Win:
   A "quick win" epic aimed at adding routing profiles to the new web app. This was strategically important for enticing users to opt for a premium subscription. We recognized the value of providing users with routing profiles tailored to their preferences and constraints, such as the road bike profile.
6. Route Detail Page Migration:
   An epic involved moving our "Route Detail" pages to the new web app. This streamlining process aimed to simplify user interactions, enabling them to edit metadata directly on the route detail view, eliminating the need to access a separate editor.
7. Capability Migration and Legacy Editor Shutdown:
   With the saving process streamlined, subsequent epics involved migrating capabilities, like drawing routes by hand, from the legacy Route Editor to the new web app. The ultimate goal was to phase out the old Editor.

The overarching vision for this initiative was to empower faster innovation without reliance on external providers.

Results and Impact

Web App Release and User Engagement

My tenure at Bikemap concluded with the successful launch of the initial version of the Web App. The legacy AB Planner remains operational, and you can explore the new web app firsthand at https://web.bikemap.net/plan. The user response was positive, underscoring the engagement of our user base with the route editor. Accidentally turning off the legacy editor and AB Planner revealed the depth of user involvement, reinforcing my commitment to rigorously test features transitioning to the new web app, ensuring a seamless experience for our dedicated users.

User Retention and Usage Patterns

Despite the significant changes, overall usage metrics remained consistent, aligning with our primary goal of retaining users throughout the transition. We successfully eliminated almost all dependencies on third-party providers, with only the route detail pages, including map previews, still utilizing them—a challenge addressed in the subsequent epic.

Enhanced User Insights through Data

Implementation of additional events will provide valuable insights into user behavior, enhancing Bikemap’s ability to comprehend general usage patterns. This newfound understanding enables Bikemap to track various aspects, including:

• User Engagement Metrics:
  • Daily and Monthly Active Users (DAU and MAU)
  • Session duration
  • Number of routes created
• Retention Metrics:
  • Churn rate
  • Retention rate
• Conversion Metrics:
  • Premium conversion
  • Sign-ups

In-Depth Feature Analysis

Furthermore, the implemented events facilitated detailed feature analysis, allowing Bikemap to track user interactions, such as the number of users planning routes without saving, identifying points of process abandonment, user authentication status, preferred routing profiles, and more.

This comprehensive data-driven approach empowered Bikemap to make informed decisions, address user needs proactively, and continuously enhance the web app to align with user expectations and preferences.

Lessons Learned

Navigating Resource Constraints

The rapid progress of our initiative faced hurdles due to a busy backend team. Navigating around this constraint, I strategically determined tasks that could proceed independently and judiciously timed their integration with the backend team. This adaptive approach ensured optimal resource utilization and allowed the backend team to focus on critical projects.

Qualitative Decision Making Amid Data Gaps

Lack of robust user behavior tracking posed a challenge in prioritizing features. Decisions were largely based on qualitative user insights and stakeholder discussions, demanding a careful allocation of time and effort. While the outcome was satisfactory, the process underscored the need for more data-driven insights. In hindsight, accelerating the project timeline to gather more data and refine insights earlier would have been beneficial.

Communicating Value Amidst Technical Focus

In planning and negotiations, emphasis centered on the primary objective: eliminating costs and dependencies on third-party service providers. While stakeholders acknowledged the importance of this endeavor, I observed a subdued enthusiasm to propel the initiative forward. This highlighted the necessity for a more compelling communication strategy, elucidating the advantages at each step and epic. Ensuring alignment between technical milestones and broader organizational goals is crucial for sustained momentum.

Unexplored Tracking Metrics

Capacity constraints limited the implementation of comprehensive tracking metrics throughout the initiative. Desired metrics included:

• User Satisfaction Metrics:
  • Net Promoter Score (NPS) and Customer Satisfaction (CSAT) for the web app or specific features.
• Route Planning Effectiveness Metrics:
  • Completion Rate: Percentage of planned routes successfully executed by users.
  • Route Customization Rate: Tracking user modifications to suggested routes.
• Conversion Funnel Analysis:
  • Understanding user journey from planning to conversion.
• Social Sharing Metrics:
  • Assessing the web app's social engagement and outreach.

The incorporation of these metrics would have provided a more comprehensive understanding of user satisfaction, route planning efficacy, and the overall impact of the initiative on user behavior.

Future Roadmap

I can’t speak as a Bikemap employee anymore but I’m really excited participated in paving the way for faster development and innovation of the Bikemap Web products. If I could decide what was next, my personal roadmap would look somewhat like this:

Finish the unification as fast as possible

The next important step is to get rid of the duplicate tool situation, so I would team up with a web developer and another designer to talk to our frequent Route Editor users. I’d expect to find that the most important feature they will need from the Editor is the manual drawing tool. I would then work on finding a way to include this tool into the new web app an a way that is easily discoverable and easy to understand for new users. We already have some design drafts and some vision designs for this so we could even directly test our vision with our super users.

Support Bikepackers

We had a strong signal in our user base to support multi day trips but we struggled to address this need because there were too many tools and our external providers were slowing us down. I personally see that addressing this user need could open up our user base for hardcore bikepackers. We already were able to generate longer routes (e.g. through the whole USA) than our competition, enabling users to make those routes more digestible and support their multi day trip planning could increase our user base and open up a lot of opportunities for monetization.

Route Generator

Me and Sebi, our lead Web Developer, always dreamt of utilizing the data we already have to figure out what kind of trips our users like to take. As a cyclist myself, I dream of a tool that takes my preferences and constraints and generate a route for me. I would love to create a route generator that takes data points like a preferred distance, general location, preferred duration, athletic intensity, scenic POIs and other factors and creates a route that users can navigate along. I would prefer that over scrolling through Komoot’s discovery for ages, trying to find a route that matches my needs.

Conclusion

The Bikemap Route Planner project successfully addressed user confusion, reduced external dependencies, and enhanced the overall user experience. Despite challenges in tracking certain metrics and navigating backend constraints, the initiative achieved its primary goals, setting the stage for Bikemap's continued innovation in the cycling app space.

I am very glad to have worked on this project with a wonderful team. Especially our Designer Dominic, who always had my back and helped me to think out of my box, when I was stuck designing some components. He always brought a new perspective and helped to make the whole thing visually appealing. Another key person is Sebi, our lead Web developer. We collaborated very closely on this project and I really appreciate every time he took over when I got swamped extinguishing fires as a Product Manager.