Travel Preference

Quick improvements and future envisioning of travel preference tool

TYPE

Intern Project

DURATION

May - Aug 2017

TEAM

Prachi Pundeer
Caleb Marshack
Joshua Sassoon

KEYWORDS

Product Design
Quick Fix
Envision

Overview

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

Background

Thumbtack is a local marketplace to connect customers with the right professionals. The basic model is that a customer needs a professional to help him/her do some work, he/she submits a request through Thumbtack website, then the matched professionals can choose to send a quote. Customers will get up to 5 quotes and communicate with these professionals to make a final decision on whom to hire.

Thumbtack professionals will only receive the requests from the areas they set in their travel preference, so it is very important to make it easy for pros to set the right areas. 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.

Problems

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

Challenge

Making most use of the resources that we already have, redesign the tool to make a huge improvement on the UX but requires least engineering efforts.

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.

Basic idea

The basic idea is to combine the zip code control with radius tool. Uses can easily add or remove a bunch of areas by changing the radius meanwhile they can make more fine changes with zip codes.

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

Pros

- Map and list are on one page.

- Not many changes from the original layout (less engineering efforts).

Cons

- 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 used a split view so that the list and map can live side by side.

Pros

- Space is made most use of.

- List and map can be seen on one screen.

Cons

- Very different layouts. Need more engineering efforts.

- Google asks for money for a bigger map.

# Final design

From the product manager's feedback, since we were going to launch an another version of travel preference tool in 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. Also according to the engineers, we should not let pros randomly change their zip code in the travel preference or it would lead to conflict with the address in their profile which is what matching model based on. Then I came up with the final design after several rounds of modifications.

New Design

Besides the quick-win project, I collaborated with another senior product designer, Caleb, to think a new design without constraints from the current one. However, zip codes will be kept as the smallest unit because of the current matching model.

We first did competitive audit by finding the geo tools in other websites like Goggle Business, AdWords, OpenTable, etc. We listed the input methods they use then we brainstormed other possible one. We analyzed the pros and cons of all the different geo selecting methods and decided on the most promising ones. Then Caleb and I respectively chose one as the primary input method and kind of diverge in the exploration. We had weekly meetings with engineers and product manager. Engineers were also doing research to estimate feasibility of the design.

Project details available on request.