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.
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
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.
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.
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.)
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.
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.
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
- Map and list are on one page.
- Not many changes from the original layout (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 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.
# 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.
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.