Travel Preference

Quick improvements and future envisioning of geo-targeting tool


Intern Project


May - Aug 2017


Prachi Pundeer
Caleb Marshack
Joshua Sassoon


Product Design
Quick Fix


I worked as a product design intern at Thumbtack for 11 weeks. I was mainly involved in the Travel Preference project in the Pro Tools team. The original design only provided granular controls and was very painful to use. I redesigned a quick win version which was easy to implement but could dramatically improve the user experience by providing radius control. Meanwhile, I collaborated with another senior product designer to think of a ideal version without constraint from the current version. Besides, I also used modular design and shipped a new feature of travel fee to help Thumbtack pros quote more accurately as a side project. Because of NDA, I will only talk about details of the design that has been launched.

My role

I was the major designer for the quick win version and I collaborated with another senior designer for envisioning the future version.

My work was mainly to understand the problem based on the data collected by the UX researcher, then translate insights into several hi-fi design alternatives, gather feedbacks from other senior product designers, balance the feasibility with engineers' inputs, and discuss with the product manager.

Methods & tools

Whiteboarding, competitive audit, use cases, paper&pen, Sketch, Photoshop, inVision


How Thumbtack works

Thumbtack is a local marketplace to connect customers with the right professionals. The basic model is that a customer submits a request through Thumbtack website, then all of the matched pros will receive it and choose whether to send a quote. Customers will get up to 5 quotes and compare the pros by communicating with them and looking at their profiles to make a final decision on whom to hire.

Set travel preference

Thumbtack pros will only receive the requests from the areas they set in their travel preference. User's goal is to set it accurately in an easy way. However, at that time, the tool is hard to use. The product manager wants a quick win version that can be shipped in 2-4 weeks and a brand-new version that better suits user's needs but may require more engineering efforts. The new version should be shipped in 2-3 months.


Current journey

When pros sign up, they need to set up their travel areas using a radius tool. Then the radius will be translated into a batch of zip codes that are within that area. When pros want to adjust their travel areas later in the settings, they will only be able to interact with those zip code areas, which makes it hard to make a big change.


The original travel preference tool was unintuitive and slow. About 10% of quoting pros currently visit their geo preferences on a weekly basis. Customer support team estimates that about 10% of support volume stems from confusion over job and travel preferences. According to the interview data from user research team, the main problems are:

ZIP is too granular

ZIP as primary selection method makes editing a travel area incredibly tedious. There is no way to quickly select a batch of zip code areas. Also, some pros can't tell from the visuals whether the orange areas are selected or unselected.

Unhelpful list view

Secondary “list view” batches ZIPs by city. User needs to click inside a city to make changes. However, many of these cities contain only a few ZIPs, which means this list is similarly unnavigable.

Performance issues

When loading the selection map, every polyline for every ZIP in the current viewport is rendered - regardless of selection state. This leads to very slow load times in ZIP-dense geos like cities. (There are over 1,000 ZIP codes to render within 50 miles of Brooklyn.)

Confusing navigation

Switching between the default “map view” and secondary “list view” is unintuitive.

Inconsistency throughout user journey

Geo setup during new pro signup is radius-based, whereas ongoing geo maintenance is ZIP-based.

Quick Win

Project scope

This project is only about how pros adjust their travel preference settings after they have signed up an account. It won't affect the current experience of how pros set their travel areas in the onboarding process.


Redesign the tool to make it a MVP. Making most use of the resources that we already have, make a big improvement on the UX with minimum engineering efforts.


2-3 weeks

Redefine MVP

What we have

Radius - When pros sign up, they will be asked to select a radius as their travel area. This radius will translate into zip code areas in the backend and can't be changed later. Radius is a simple interaction so it facilitates a smooth signup experience. However, it's also too general and pros usually need to refine the area later.

ZIP - This is provided as the primary method for pros to edit their service areas in the travel preference setting. While zip code gives users very precise control, it could also be very tedious to use when the preselected area by radius is not close to their true service area.

Problem with current solution

The biggest problem that prevents the current solution to be a MVP is that the tool is inconsistent in the onboarding and maintenance process. There is no easy way to fix it if pros set the wrong radius in the onboarding process.


Adding radius control to the tool will solve the biggest problem. Uses can easily add or remove a bunch of areas by changing the radius then they can make more precise changes with zip codes. After I talked with PM, we quickly decided this is the MVP.

Design explorations

After MVP was defined, then I began to design the interface. Then the problem of unhelpful list view came to me.

While in map view, users can only make adjustments with zip code, they can interact with a higher-level of grouping, which is city, in the list view. But at that time, users need to go to click inside a city to make changes, which makes it very cumbersome to use. I thought it would a good opportunity to also improve the usability of the list view.

My basic idea is to show the map and list in a single view for Web, so that users can interact with the visualized zip code, then have a chance to adjust with cities, which complements the granularity of zip code. Also, make the list more transparent and easier to use.

# Design alternative 1

I added a radius tool on top of the map. Then I integrated the list view into map view and made the list more transparent with a table view.


- Easy for eyes to navigate.

- Similar layout with other pages on the website (less engineering efforts).


- Users may need to scroll up and down to see map and list.

- The list may be very long which makes the "Save" button get buried.

# Design alternative 2

I overlayed the input box of radius on map.


- Make it clear of the radius's effect on map

- Map is big


- Users may need to scroll up and down to see map and list.

- The radius input box blocks the view of map.

- Google asks for money for a bigger map.

# Design alternative 3

I used a split view so that the list and map can live side by side.


- Space is made most use of.

- List and map can be seen on one screen.


- Very different layouts. Need more engineering efforts.

- Google asks for money for a bigger map.

Feedback for my designs

I presented my design alternatives to the PM and engineers. They recognized me for the efforts in the exploration and gave me many constructive feedback in regard to the feasibility.

Keep the current layout

According to the PM, since we were going to launch the ideal version of travel preference tool in 2-3 months, the quick win version should either fit into the later version or keep as close to the current design as possible to minimize the engineering efforts. Since we haven't flesh out the ideal version, the major layout should be kept as the same.

Don't let users change their zip code randomly

According to the engineers, user's zip code is linked to the address in their profile so it should not be allowed to change randomly. If they do want to change, they need to do it in their profile.

The radius data cannot be saved

After pro selects radius in the onboarding process, it will be directly translated into zip codes. There is no data field in the backend to store the radius information. This means the radius tool can be only provided as a UI convenience. Every time the user enters the page again, the radius they selected last time can't be shown.

Final design

With these feedback, I began another round of design exploration. The map and list need to be kept in separate views. The radius tool will be a UI convenience rather than a primary selection tool. This time I focused on small design details that can improve user experience.

Radius tool

I redesign the radius tool to look more like a UI convenience. Show the zip code location of user, and take user to the profile setting to change it.

Toast notification

I suggested a small new feature of toast notification on the map view to help users be more confident in their actions. This received very positive feedback from the engineers and PM.


I used a tab to let users switch views which is a UI convention.


According to the interview data, some users are confused about whether the orange areas are selected or the other way round. Adding a legend to the map can help those users.

This is the design I finally shipped, I also designed for the iOS and Android app.

Ideal version

Besides the quick-win project, there is also a long-term project aimed to develop the ideal version of geo-targeting tool. It estimated to span 2-3 months. I collaborated with another senior product designer, Caleb, to think a new design from the ground up, without constraints from the current one. However, zip codes will be kept as the smallest unit because of the current matching model. Because of NDA, I will not disclose project details here. In general, our process is:


That summer in San Francisco is the coldest one I have ever had, but it was also the most fun and fruitful one working in the cutest design team. And here are what I've learned from my internship.

Design with constraints

The most important thing I learned in my internship is that design in industry is very different from design in school. In school, we usually have plenty of time to do user research and we don’t have to worry about the feasibility. However, when designing in a real company, we have much more constraints, like the timeline, project scope, required engineering efforts. We should learn to be comfortable with designing with constraints and fight to get the best result for our users.

Get a holistic view of the project we are doing

Another thing I learned is that we need to know what other teams are doing and what is happening in the company wide while we are working on our own projects, so that we can get a holistic view of what we are doing and why our work is important. Then we can communicate better with the product manager and develop a sense of ownership even when we are doing a relatively small project.

Communication is the key

Another thing is that communication is the key. Sometimes you think you have explained your idea well, but people may not fully understand it. And they don’t always tell you they haven’t understood it or they simply don’t know that they haven’t. As a designer, we need to continuously improve our skills in presenting and communicating our ideas in an efficient way.

Learning from the engineers

When I was working with engineers, I also found that sometime they would have interesting ideas and they were a great source to learn various extreme cases that we designers may overlook when we design. It’s super important for the whole team to work closely.