In addition to interest based parameters, functional variables such as total time available for the trip or start location would need to be provided by the user:

Assuming the user is brand new to the city, our feature should not require prior knowledge of geography, sights or neighborhoods. It should be straightforward to set up and use. The full end-to-end journey could be split into 3 stages: Setup → Pick a trip → Enroute.

With a preliminary user flow in place, I started sketching out low-level wireframes of each step.

Along with that, I started looking into Google Maps' existing UI to see what elements and patterns could be reused, and what would need to be built from scratch.

With initial parameters in place, I could start iterating on the UI of the Setup screen. The default state of the UI is optimized for the first time visitors, requiring minimum effort or prior knowledge about the city. However, it can be easily expanded by adding additional variables, such as granular interest tags (e.g. broad category of Arts & culture could be split into Museums, Galleries, Neighborhoods and etc.) giving the user more control over the outcome. 

The goal of the Routes screen is to get the user to pick one of the routes, generated based on their preferences. In a series of design iterations, I tried to establish a range of options, varying from a minimal overview of the route, to an explicit list of sights and their respective categories. Having a diverse range of options allows to identify the optimal ballance of information and its hierarchy through qualitative user research or a/b testing.

The biggest challenge when designing the navigation screen was to present the actions and trip information without detracting user's attention from the main goal — navigating the streets. Drawing on the existing UI of Google Maps and consistent with the rest of the flow, I incorporated route overview and quick actions as a series of cards, swipe-able from the bottom of the screen. 

The user flow bellow lays out the main touch points of the feature and could be used as a basis for prototyping and user validation. In addition, it opens up a series of  interesting considerations for the next iterations: 

1. How could the app facilitate user's experience when they reach the destinations on their route? 

2. Should the trips be algorithmically generated or crowdsourced from the users?

3. Will such feature increase the utility value of Google Maps or dilute it, and should be a standalone product?

4. What are opportunities for monetization (restaurant / ticket booking) and how could they be integrated into the flow? 

Thanks for reading!

In addition to interest based parameters, functional variables such as total time available for the trip or start location would need to be provided by the user:

Assuming the user is brand new to the city, our feature should not require prior knowledge of geography, sights or neighborhoods. It should be straightforward to set up and use. The full end-to-end journey could be split into 3 stages: Setup → Pick a trip → Enroute.

With a preliminary user flow in place, I started sketching out low-level wireframes of each step.

Along with that, I started looking into Google Maps' existing UI to see what elements and patterns could be reused, and what would need to be built from scratch.

With initial parameters in place, I could start iterating on the UI of the Setup screen. The default state of the UI is optimized for the first time visitors, requiring minimum effort or prior knowledge about the city. However, it can be easily expanded by adding additional variables, such as granular interest tags (e.g. broad category of Arts & culture could be split into Museums, Galleries, Neighborhoods and etc.) giving the user more control over the outcome. 

The goal of the Routes screen is to get the user to pick one of the routes, generated based on their preferences. In a series of design iterations, I tried to establish a range of options, varying from a minimal overview of the route, to an explicit list of sights and their respective categories. Having a diverse range of options allows to identify the optimal ballance of information and its hierarchy through qualitative user research or a/b testing.

The biggest challenge when designing the navigation screen was to present the actions and trip information without detracting user's attention from the main goal — navigating the streets. Drawing on the existing UI of Google Maps and consistent with the rest of the flow, I incorporated route overview and quick actions as a series of cards, swipe-able from the bottom of the screen. 

The user flow bellow lays out the main touch points of the feature and could be used as a basis for prototyping and user validation. In addition, it opens up a series of  interesting considerations for the next iterations: 

1. How could the app facilitate user's experience when they reach the destinations on their route? 

2. Should the trips be algorithmically generated or crowdsourced from the users?

3. Will such feature increase the utility value of Google Maps or dilute it, and should be a standalone product?

4. What are opportunities for monetization (restaurant / ticket booking) and how could they be integrated into the flow? 

Thanks for reading!

Home