Homecoming Payments
Building a payments feature into an all-in-one, mobile & web platform for mental health and wellness practitioners.
0 to 1
UX/UI
UXR
Contributions
Product Design Lead — UX/UI, Interaction Design, Rapid Prototyping, User Research, Design Systems, Visual Design
Team
Eli Goodman, Product Lead
Samir Uppaluru, Engineering Lead
Habib Rehman, Full-Stack Engineer
Timeline
2 months, Jul – Aug 2023
Overview
Homecoming is a startup building an all-in-one toolkit for mental health and wellness professionals. The company pivoted in Q3 2022, requiring the team to build a new web dashboard and mobile app for practitioners and a mobile app for clients from zero to one.
This case study showcases the Homecoming Payments feature, which serves as an example of how we built the entire product.
Impact
The Payments feature was one of several features that contributed to the growth of our customer base from 0 to 250.
Context
Solo coaches, therapists, and other wellness practitioners need help
After pivoting markets in Q3 2022, we conducted market research and interviews with therapists, coaches, and other wellness practitioners for 2 months. One near-unanimous objective emerged: practitioners want to focus on supporting their clients, and to do that they needed help managing other aspects of their business.
To address this objective, we built dozens of features that consolidated all aspects of their business into a single product. Payments was one of these features.
💡 Optimizing for velocity
Homecoming’s main objective was to find product/market fit. We designed and shipped quickly, and let customer feedback guide subsequent steps.
User Research
We learned about the goals and pain points of practitioners in getting paid
I shared a survey with practitioners in our network to learn how they got paid today and what pain points they experienced.
Limited customizability (33%)
Late payments (25%)
Disjointed process (25%)
Transaction fees (17%)
User Insights
A comprehensive payments solution needs to address many pain points
We learned from the survey that there were a variety of needs, none of which dominated above others. We realized we'd probably have to start small and continue to build on top of the initial solution to ensure that all needs would be met.
Competitive Research
We looked at industry-leading payment products
We researched the UX/UI of Stripe, Square, Acuity, SimplyBook, and other top payment solutions to learn what problems they were able to solve. We learned that these tools offered users some combination of selling, billing, and tracking of their products and services, along with features like scheduling and website-building as bonuses.
Engineering Spike
Engineers spiked on the technical bits of launching a payments tool
Concurrent to the customer survey and competitive research, the engineers on this project began spiking on what it would take to host our own payments platform. They looked at the API of Stripe, Paypal, and other products that would integrate well with ours.
Opportunity
We decided to build a lean payments tool that leverages our access to client data
When we merged the insights from the user research, competitive research, and engineering spike, we saw that Homecoming's main competitive advantage in building a payments feature was its capacity to integrate with existing client data and client management tools.
Furthermore, because there were already cheap payment API and repeated UX patterns we could use, the design and technical investment could be minimal.
Design
The team brainstormed and mocked up the ideas
The team synced to get aligned on the research insights and user needs. We brainstormed solutions, and after the meeting, I proceeded to mock up the ideas for us to consider.
💡 We skipped lo-fi designs. Why?
Velocity: This was our priority. Our team would use existing components for v1 and was always willing to rebuild if any issues were to arise.
Pattern recognition: There were many repeated patterns across the competitors I researched. For something as risky as financial transactions, repeating familiar patterns seemed like a better move than innovating new ones.
Prioritization
We trimmed down the scope
Elements that wouldn't be included in the MVP would either be kept in our backlog for an engineer to pick up in the future. Here were the principles governing how we prioritized:
📈 High-value
We reviewed practitioners’ current processes and pain points to determine which solutions would bring most value.
📉 Low-cost
We discussed the technical cost of each solution and prioritized solutions that were quick to ship.
↔️ Breadth Over Depth
How might we support a simple version of selling, billing, and tracking?
🤝 Synergy
We prioritized solutions that could be synergetic with existing or planned solutions.
Testing
We interviewed current customers to validate the scope of our MVP
We interviewed 5 current customers. We showed them a prototype that reflected the MVP to learn whether this was enough or if the feature would need more.
Outcome (1/3)
Connect your Stripe account and see invoices in your Payments tab
Creating a Stripe account was free, and once connected, Stripe would handle all the data security and transactions between the practitioner and the clients.
💡 Why invoicing?
67% of survey respondents sent invoices to get paid, followed by 50% using Venmo. Building an invoicing system had an additional benefit: we’d have control over payment data, which would sync well with our scheduling and follow-up features.
Outcome (2/3)
A simple invoice builder that leverages your client list and auto-fills past services and prices
The simplest version of an invoice builder would only need an invoice ID, invoice recipient, and invoicing items and prices. We wanted to do better, so we added a due date (to handle past-due invoice notifications), a client-facing note (to add a human touch), and an auto-fill that remembered your past services and prices.
Outcome (3/3)
One step closer to becoming the all-in-one toolkit for practitioners
Payments was one of dozens of projects that constituted the web dashboard experience for our practitioners. I was the lead designer in building other capabilities, such as following-up with clients, connecting with Calendly to enable on-platform scheduling, and building a custom resource library.
Jules X.
Integration Coach
Impact
Paying customers from 0 to 250
In the past 6 months, we've grown our customer base to 250 practitioners. To learn more about the specific impact of this project, please reach out.