Thumbtack | Payments

2017

Platform(s):  Responsive Web with 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 a product designer and a 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?

 
 

Goals

 

 

 

Early Research

 

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.

 

 

Guiding Principles

 

Measuring Success

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.

 

 

 

Initial Scoping

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, the team’s assumptions, and to form my 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: 

  1. Ease of use
  2. Being explicit in messaging 
    1. of fees
    2. of how Thumbtack Payments works
    3. of approximate payout dates
  3. Exuding trustworthiness
  4. the need for payout accounts
  5. Placing emphasis on Identity & fraud prevention
  6. Capturing job completion dates
 

 

Monetary metrics: 

  • 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?

 

Funnel metrics:

  • looking for any drop-offs in the flows for pros or customers

 

Fraud metrics: 

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

 

     

     

    This involved:

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

    Pro-initiated Payments Experience (mvp)

    Early Decisions

    User Research & Testing

     

    dfdfdfdkfdfkdfdfd

    dfdfdfdkfdfkdfdfd

    dfdfdfdkfdfkdfdfd