Thumbtack | Payments
Platform(s): Responsive Web and native mobile support
Where: Thumbtack.com, App Store, Google Play
Tools: Sketch, Invision, Wake, Zeplin
Thumbtack is a marketplace and platform for helping professionals and customers in need to get things done. A goal since the earliest parts of the company’s near decade long history has been payment — a system for customers to pay pros as well as resulting infrastructure and associated features.
I was lucky that when I joined one of my first major projects was to lead product design for Thumbtack’s first ever payment experience. Starting from scratch, I designed an entire peer to peer payments system with features and contexts across our product for various use cases for customers and pros.
Designing for this initiative required close collaboration between myself and our cross-functional team, thinking strategically about how payments could work in parallel with updates to our in-app messenger, scheduling, reviews, and project completion experiences, as well as being mindful of trust, security, customer needs, professional mindsets, category specific patterns, identity, legal requirements, systems level thinking, and requirements from Stripe.
Team and involvement
For this project, I was both the only product designer and user researcher.
I collaborated with a large cross functional team of product managers in our customer experience and marketplace integrity focus areas, several backend and front-end engineers, an engineering lead, a content strategist, analytics, and category managers.
In the Thumbtack world, before in-product payments, the experience of paying was quite limiting for customers and professionals:
- Professionals who worked on their projects would have inconvenient means of payments, such as check, money orders, or cash
- Without in-product payments, it’s harder to track project projects to provide our Thumbtack guarantee of quality
- Harder to provide consumer protections against fraud if payment is out of our platform.
- Professionals have to rely on customers marking them as hired so that their overall job completion rate increases
Why is in-product payments important for Thumbtack users?
Why does payments matter for Thumbtack as a company?
By having a payments feature, Thumbtack can:
- Drive adoption and retention between professionals and customers
- Improve the user journey of starting and completing a project
- Mitigate fraud
- Add market liquidity — get users to pay for more projects and services on our marketplace
- Explore a variety of revenue models, particularly by project category
- Get more accurate signals project completion and hire rates of professionals
- Let customers pay pros on Thumbtack in a few select categories
- Learn what incentives and product features might help drive adoption of payments
Before I had joined, the team had spent a few months on research via market assessments and interviews of customers and professionals to understand payment methods and tracking/invoicing as well as any issues or concerns in payment experiences in the project initiation to completion phases. This research specifically focused on customers and pros in single, non-recurring, payment categories on our platform, such as tv mounting, massage therapy, and portrait photography.
These findings provided early insights for the product team into some pain points for customers and pros, as well as some mvp base criteria of a payment feature.
For customers, the idea of having an additional option of payment methods (whether cash, check, or online payments) was appealing so long as at the core of the experience was trust, ease of use, and security.
For professionals, there was a heavy preference towards cash or check payments, but a willingness to use cards and electronic payments if need be, as well as concerns of fees (particularly vs. Paypal/Venmo), security, and timeliness of payout.
Since we never had payments before, we didn’t have much baseline metrics to work with. Measuring success meant being thoughtful about defining the sorts of data we’d rely on as the foundation for future analysis, in addition to marketplace metrics, insights on behavior, and funnel metrics.
Much of these were defined by the product manager and aligned on with leadership in a product review prior to my joining, but I did have the option of proposing other metrics or thinking about how we might redefine success.
The minimum spec needs and assumptions of the early team were:
A pro-initiated payment experience (to be launched first) and customer-initiated payment experience following
- Assumption that customer initiated payments would drive adoption more than the pro-initiated experience
- MVPs for both experiences would only use credit cards
- MVP launches first in single pay categories
- massage therapy, portrait photography, and tv mounting
- 2.5% transaction fee charged to the Pro
- Direct deposit via payout account for pros
- Identity verifications after a transaction threshold per Stripe fraud prevention requirements (> $10k)
- transaction receipt / record as emails
- high emphasis of collecting job date
The Design Process
Through my design process, I sought to get an understanding of our existing system, mindsets of our pros and customers, test the team’s assumptions, and form my own opinions of the problem space, how we might approach solutions, and whether our scoping is appropriate.
These learnings helped us to align on guiding principles and core areas of focus for this project, particularly:
- Ease of use
- Being explicit in messaging
- of fees
- of how Thumbtack Payments works
- of approximate payout dates
- Exuding trustworthiness
- the need for payout accounts
- Placing emphasis on Identity & fraud prevention
- Capturing job completion dates
- Gross Merchandise Volume ($$$ for services) captured via in-app payments by category, date/time, and platform
- Payment Requests by category, platform, and entry point
- Average median job value by category and date/time
- Transaction fees by category and date/time
- # of linked bank accounts for professionals by category
- Payouts (GMV - transaction fees) by category and time
Adoption and usage metrics:
- # Payments Completed/Hires
- Monthly active pros who’ve setup payout accounts by category and date/time
- Rate of payment (payments received per requests sent) by category and date/time
User behavior metrics:
- When are payment requests sent and how close to the date of the job?
- When do customers pay and how close to the date of the job?
- looking for any drop-offs in the flows for pros or customers
- # of payment transactions escalated for manual review
The early team also had some rough ideas of what such an experience could look like, with emphasis on collecting job dates and banking information.
- Taking a look at the existing user experience and for pros and customers with journey mapping
- UX audits
- Sketching and ideating, independently and in team brainstorms, to consider what payments could look like in our product
- Syncs with legal and ux writing
- Reviewing designs with project team and in design crit sessions
- Iterating on feedback
- Moderated user research
- Making recommendations for further exploration research.
In journey mapping, I saw avenues and opportunities where payments could be timely, as well as lead to paths of “marking professionals as hired” for project completion and a Thumbtack guarantee of protection.
Looking at the existing journey we can see that job completion, hiring, and payment are disjointed experiences – where we have this experience where the job is commissioned and starts ("informally hired") and the experience of our system recording the hire.
Because of this, after project completion, it is very common for dropoff to occur where professionals don't get listed as hired despite the project being complete. This is creating a gap between actual job hires and what our product was able to get signal on. Hence our motivation for payments and initiatives like the Thumbtack Guarantee and Top Pro to increase high rates and capture signal on hires.
An avenue that looked close to ideal for at least the pro-initiated experience was to consider payments as early as the quote receipt in the user journey, but also something that could occur later in the journey via the messenger.
The rationale being that pros, more-so than customers, could have preferences for payment before the project starts, upon project starting, or at project completion.
Examples of these cases could be:
- deposits for a project
- fees for calls or consulting associated with a project
- additional charges following the initiate work
In thinking about what the journey might look like for a customer some themes that came to mind were:
- When might we allow customers to initiate payments
- How might we think about pros having a say in when customers could initiate payment
- How might we prevent confusion between quotes and payment requests/initiation
- how might we think about timeliness and triggers
- How to mitigate fraud
- How smart our system is and could be
- How this affects our current and future worlds (paying to book v. paying for a job that's happened)
Thinking about entry points
In thinking about entry points in our messenger, and beyond, I had a look at the analytics of how customers enter Quotes Views / our messenger.
Because of the heavy skew towards email, it seemed that we should consider emails as a part of our scope and also think of how we might engage users to facilitate payments in our messenger or other surfaces.
I audited our existing system to understand what sort of limitations or opportunities exist through our existing design system and tools.
In ux auditing, I explored a variety of payment experiences, some peer-to-peer communication based (Venmo, Facebook Messenger), some purely transactional (Chase QuickPay, Square Cash), and others more as a timed leg of the user journey, such as AirBnb. This helped to get a sense of what sort of experience and standards would make sense for our system and the Thumbtack experience.
Looking at a variety of transaction emails, records, and receipts helped me to form opinions regarding information architecture standards and how those might differ from peer to peer payments and paying for services/goods.
- Noting the specific card / account used to pay noted and displayed with card type and last 4 digits
- Considering a transaction record and identifers
- The importance of payout dates
Early design recommendations
In initial sketching, I started imagining the experience as one where:
- A professional could request payment in the quotes they send to customers, triggering a pay button to appear to the customer.
- Payment can result in the pro being hired or hiring results in payment as the next step.
- Pay requests thought of as invoices w. structured messages
- Keyboard action bar entry point to payments in messenger
- First onboarding education in payments flow
- The customer has the ability to note that they'll pay in cash or other offline method instead of card.
V1 - Pro-Initiated Payments
Team Sketch Session
User Story 1 - As a professional I'd like to request payment
User Story 2 - As a customer I'd like to pay my pro
Explorations, decisions, and iterations
What if the pro could tie payments to their project at the quote experience?
This could be something where the pro toggles to enable payment with the quote they send.
The resulting quote would simply have the pay button instead of the hire button.
And then after sending the quote for the project, the pro could entering a flow to input banking information to accept payments.
- Pros with one-time payment services can save time
- The pro doesn't have to think about payment nor send a request
- Closing the gap between hired and paid
As a team, we decided against this directionecause we felt it would get too deep into changing our existing hiring and quoting models – areas that other teams and product areas were experimenting with or thinking about for the future.
What do entry points look like for sending a payment request?
Email sent to Pro on job date
Messenger Entry Points
Initially I explored adding a payment action to the pro's messenger field, much like how we have a paperclip action for uploading content. We could use color highlights to suggest the payment action when appropriate.
Since the messenger framework was undergoing a redesign effort, we couldn't add actions to the text input until that was completely, for the short term, we decided to use sticky system messages with actions until the new framework was ready, relying on job date and events as triggers.
System prompts also work as entry points to other payment related actions
In the newly redesigned messenger, pros use a messenger composer action to enter the request flow as well as links on structured messages to take further actions or see payment states.
Given that we had scheduling actions on the project inbox, it seemed appropriate that we'd have a request pay action.
What does sending a payment request for look like?
For the first time sees a modal with value props and educational points. We were striving to communicate ease, security, and the mechanics of how it works.
Clicking get started, will reveal the payment request form with the customer's name, service provided, and inputs for price, job date, and notes.
After sending the request, a success screen appears confirming the payment and legalese around release of funds.
How does a customer pay the payment request?
In the pro-initiated experience, a customer would pay the pro by entering from the email or message versions of the invoice.
The payment experience for the customer is one where the customer gets an invoice with an optional note from the professional, enters payment information, and performs the transaction.
How would a pro add banking information to receive the payments?
An early decision we had as a team was to allow professionals to request and accept payments without having setup a payout account.
Through account settings, a professional can add a bank account or debit card to receive payments.
If a pro hasn't set up a payout account, our system holds the payment for them, but a system message will appear as well as notes in transaction records.
How did we mitigate fraud?
For this first phase, there was monitoring of all transactions. In addition, suspicious activity or transactions over $10,000 required identity verification due to banking regulations and Stripe's needs.
How do pros and customers track transactions?
Initial thoughts and explorations were that we'd want to help pros and customers with record keeping or support cases through receipts and transaction history pages for both pro and customer.
Because we were still testing traction and had to be mindful of expense, we felt that priority for this first release would be a transaction history page for the pro and records in messenger.
User Research for Pro Initiated
For research I conducted a research plan as well as an interview guide and interviewed several active pros of varying demographics working in single pay categories, such as tv mounting.
- Zoom meetings with invision prototypes
- 2 subject groups of 3 each with an additional backup
What we sought to learn
- What barriers would keep a pro from using our payments system
- How our messaging resonates
- How our user experiences meet expectations and needs
- How our proposed flows resonates
V1 - Customer-initiated Payments
We saw this experience as the key to driving adoption. As far as design, much of the system was designed when we designed pro-initiated payments.
We decided early on to keep this experience in line with the pro experience.
The big decisions were around entry points (pay vs. hire) and to not have a transaction history dashboard in our v1 due to resources.
User Research & Testing
We wanted to validate some of our assumptions and also examine language and usability so I conducted a study. The findings confirmed that our system was viable, clear, and easy to use. It was interesting to see how fast users would finish the task of paying a pro. Outside of that, the big factors were adding additional non-credit card payment methods. A big item that had come up, which we opted for out of this scope, was pay vs. hire. Users were quicker to pay if the hire button was subdued.
Further Decisions and v1 Experience
Following research, we didn’t have much to refine in the experience. We looked into suppressing the hire button, but opted not to until more data comes from payment adoption as hire would have a big impact on our revenue model and system.
Results and Learnings
How might we have done things differently?
Coordination with other initiatives
Future Considerations & Opportunities
In the existing Thumbtack world:
1. A customer would send a request for a project
2. A number of professional in the area receive the request in their inbox of requests
3. Professionals selectively reply to requests with quotes and other information for the job
4. The customer then receives quotes; accepts one.
5. Customer and Professional would arrange for the job to happen.
6. The professional starts and completes the job
7. After the job is complete, the professional and customer sort out payment particulars offline.
8. After this point, a pro may be marked as hired either by the customer or themselves and may get reviews for the job completed.
Looking at potential MVP and blue sky user journeys for a customer starting a payment experience:
A deeper look at our existing ways of communicating and having contextual triggers shows:
- Contextual ui's triggered in messenger to set up calls or scheduled appointments
- How state is communicated across surface areas
- The prominence of reminders
Looking at how the projects cards update to reflect quotes and other activities had me thinking about how we might consider similar patterns for payment activities, such as pending pay requests.
Our system messages with links within the messenger, quote listings, and headers also seemed like means we could explore for prompting action or communicating the end price requested or other payment states.
Notifications also navigation also seemed like areas worth investigating.
The particular experiences I audited were how these platforms:
- Considered transaction history and receipts
- Entry into payment flows
- Make the payment flow feel secure, trustworthy, and not awkward
Some learnings from Facebook Messenger's payments experience were:
- thinking about having learning moments in the first time experience
- communicating trust and ease
- considering ways to show identity and notes for the payment
Chase QuickPay, a feature for peer to peer payments and transfers within Chase's mobile app, was interesting for thinking about navigation entry points.
For us, navigation focus is more something we'd think about deeper in the long term depending on traction.
Snapchat's SnapCash feature is an interesting case in terms of grabbing payment intent through user generated messages to then update the ui and send a payment.
My thoughts were that we should to make payments feel like a natural part of the process rather than just expect it to be something that either actor would remember to initiate in app:
We should give the Pros ease of access to controls, but try to make it a part of their job process conclusion.
Customers will lean towards notifications / state changes as well as experiences CTAs initiated by the Pro sending the request.
The most basic ideal flows would be:
- Pros manually triggering payment requests from their inbox, chat with customers, or some prompt from the system (sms or email at or after job date)
- Customers seeing state changes in their project or chat experience, or email prompts to pay by either the system event handling or triggers from the pro.
The team's assumptions were that:
- We could get good signal and have a phased roll out strategy without much resources by having the peer to peer experience of customer and pro-initiated experiences.
- Starting with the pro experience seemed like a good way to test our strategy and build out infrastructure needed to support the customer experience.
- We were predicting low adoption, but we actually found post-launch that many pros were creating payout accounts to afford digital payment to customers
To get a sense of how our team was thinking of solution space here, to better capture engineering nuances, and to include everyone in the design process, I organized a sketch session with the cross functional team.
In this timed sessions, we'd pen and paper sketch out how we'd imagine solutions through problem statements and sketching for the user stories of a professional requesting payment and a customer receiving and paying that request, and discuss our solutions as team.
- Requiring authentication/identity verification
- for making the payment request
- before entering banking information
- Ability to add bank account flow after sending payment request
Some themes that overlapped were:
- CTAs and links to payment flow through messenger, headers, and emails
- Confirmation modal / page
- Input form as part of flow to add credit card information
- Communicating when the funds would get to the pro
- Ability to check status of payment
- Ability to enter a review flow
- we'd potentially affect our quotes feature's impact (might create a bias against pros that don't enable payment at quote level)
- might be dependent on future features (instantly booking a pro)
We noticed two types of pro perspectives on payments
○ Payment as a personable point of sale experience between pro and customer onsite
■ Don’t want education or setup steps. Want to be as quick as possible and confident for
customer trust in payment.
■ Fee adverse
■ Holding period adverse
○ Payment as a tertiary thought -- payment is foreground / already set up or recurring .
Pros found our ui and language to be fairly straightforward, but some areas for improvements, such as shortening the first time education sequence, and leaving banking info as a separate experience.
Customer initiated payments rolled out to about 60% Thumbtack marketplace request volume and Pro-initiated had a smaller rollout of 17.5% request volume in top ten single payment categories.
We were predicting low adoption and didn't seem more than 1k payments weekly, but we found in post-pilot-launch that pros were creating payout accounts to afford in-app payments as a choice to customers.
One hypothesis for this is that the single payment categories, such as massage therapy and tv mounting, are services more likely to be paid for in cash. Another factor may be pro's leaning towards their own particular preferences of payment.
After launching the customer initiated portion, the focus shifted to incremental rollouts and consideration of in-app payments replacing "hiring" and tying closer to the quote experience.
It was really fun to work payments because I go to think about multiplayer scenarios, fraud prevention, trust, and systems level design. There was also a lot of content strategy and visual systems work to consider.
I think areas we could've approached differently are product strategy, marketing, and coordination with other initiatives.
Our approach was conservative, but worked for what we were trying to learn and our resources available at the time. There’s also room to explore these avenues in the future.
The alternative approaches required heavier investments in risks to our existing revenue models, in infrastructure, or limit the choices the pro has in how they’d like to run their business on Thumbtack.
For example, we might’ve seen some interesting results by rolling out a variant of payments that is triggered by the system rather than the pro or the customer — making payments a natural step in product, rather than at the discretion of the users. Hypothesis being that some pros may view making payment requests as tedious so they stick to their tried-and-true methods, but would prefer an automatically triggered request to the customer. Pros that are against electronic payments or have other preferences would be apprehensive.
We could’ve also had variants in the user populations where some pros would experience payments without the transaction fees or higher quote fees with no transaction fees for payments to gauge adoption and the role of existing fees in willingness to use in-app payments.
There were a lot of moving pieces to our payments project due to other overlapping initiatives in flux such as messenger redesign, scheduling, and reviews efforts. We’d use design reviews to keep on the same page. I think we could’ve coordinated better through design sprints to align and not need as much checkins or later changes.
For the pros and customers in our roll out categories, it would’ve been nice to have marketing or other coms about the feature.
Future efforts to further adoption and through incentives for the customer experience through incremental improvements and considering the following:
Thumbtack Active Payments v2 / payment keyboards
As our messenger evolves, we look to further optimize the experience for payments, potentially with contextual keyboards and machine learning to trigger payments and related actions.
Multiple payment support (deposits, recurring payments)
The idea being that we can drive adoption through supporting multiple payment behaviors.
Category specific payment features (invoicing for corporate categories, installments, etc.)
Some project categories on Thumbtack’s marketplace have particular nuances with payment, such as local movers that require deposits and installments for each leg of the job. Being considerate of these categories will aid in adoption.
Pay as hire/booking models and alternative revenue models
Moving away from having a separate button for hire and having pay or booking models as the only signals for hire would tighten our system. There’s also room for exploration of alternative revenue models, where instead of paying credits for contacts to customers, a pro could pay to be bookable and have automated payment requests, or pay for money management tools.
Increased Category Coverage and Roll outs
Our most clear next move is to increase feature roll out to more categories. Ideally we’d like to cover all single payment categories and then move on to categories with more complex payment behaviors.
Multiple payment types (PayPal, Apple Pay, Android Pay, Cash)
Adopting non-credit card payment support was a big demand from our customer research findings. More payment types and standards can afford us lower trust barriers as we all as provide more convenience to customers who have a very tried and true method of payment. Additionally, getting into mobile payment standards could help with adoption of Thumbtack on native apps as well as creative a more native experience on these platforms.
Smarter time and context based payment triggers
In an ideal scenario, payment requests and actions happen at the right time, whether it’s a deposit after a customer receives after a quote or triggering payment experiences in the job experience or immediately after.