Designing 0-1 financial tools to help startup founders and freelancers collect, send, and manage money
ROLE
Lead Product Designer
TEAM
1 PM
2 Engineers
DURATION
12 weeks
METHODS
User research, rapid prototyping, feature prioritization, user flows, usability testing, branding, visual design, design systems
About Tribe.Money
Tribe.Money is a fintech SaaS platform that provides early-stage founders and freelancers with frictionless access to professional financial tools without the need to incorporate or deal with paperwork.
My Contribution
I led the 0-1 design of payment links and invoicing workflows, translating ambiguous business needs into a unified system for collecting and distributing money. I defined key use cases, built end-to-end flows, and collaborated cross-functionally to shape product direction.
PROBLEM
Early-stage founders and freelancers typically lack the administrative bandwidth for complex financial tools
Traditional platforms often require formal incorporation, generating high friction in essential cash-flow tasks like invoicing.
PROJECT GOAL
Reduce friction in early-stage cash flows by designing a unified payment system
Users need a way to collect, request, and manage money without heavy cognitive load or administrative overhead.
Summer Workshop 2025
Payment Link URL
https://tribe.money/pay/summer-workshop-2025
Copy link
Amount
Description
Summer Workshop 2025 Attendance Fee
Link status
Active
Name
*
Summer Workshop 2025
Created on
$100.14
Jan 16, 2025
Preview
Cancel
Save
ALIGNING ON SCOPE AND PRIORITIES
I worked closely with the PM and engineers to align on business requirements and to validate assumptions before starting
We prioritized payment links and invoices as core user flows, since they directly enable users to collect and request money. While there was initial interest in building out the full platform, I advocated for a more agile approach to deliver value quickly.
DESIGN PROCESS
Translating user behavior into design decisions
Operating in an early-stage environment with limited upfront research, I translated business requirements and initial assumptions into early user flows to establish a foundation for design iteration.
Founder
An early-stage builder managing a product or venture; may handle incoming and outgoing payments
Freelancer
Independent contractor delivering services; paid by per project or client
Hypothesis 1
Users may prioritize speed over exhaustive data entry
Hypothesis 2
Users may be unfamiliar with financial processes and large information sets
Hypothesis 3
Users may require flexibility across different payment contexts
↓
1
Guide users through inputs
A top-down guided flow with smart defaults helps users complete required inputs efficiently.
The user is guided vertically in the payment link creation process.
Smart defaults, such as auto-populated fields, reduces time on task billing a repeat client.
2
Make financial information easier to interpret
Digestible labels and simple hierarchies make unfamiliar information easier to understand and navigate.
Clear navigation, filters, and supportive labeling help users quickly locate information and take action.
3
Support flexible payment workflows
The platform accommodates both quick, open-ended requests and structured, client-specific transactions, depending on context. This led to the creation of payment links for the former, and invoices for the latter.
To create a payment link, a side drawer opens, allowing users to stay in the context of high-priority information and complete the flow quickly.
In contrast, creating an invoice opens a dedicated page, providing a focused, guided space to review and confirm key details while still maintaining an efficient workflow.
These assumptions were later validated and refined through feedback from alpha users, particularly around clarity of payment workflows and ease of use.
TAKEAWAYS & REFLECTION
Explore everything and collaborate often.
Getting feedback from stakeholders is key to iterating and justifying design decisions and tradeoffs. Oftentimes, pivots are made to encompass the many user journeys that goes beyond the happy path. As part of a broader product shift, this project introduced a new visual direction, including updated color systems, which continue to evolve alongside the product.
As this project is still being developed, please hold tight as this page will be updated later. For now, thank you for stopping by!
DESIGN CONSIDERATION
Ensuring clear distinction between payment flows
In earlier explorations, I created payment links and invoices with similar visual style, which made it difficult to distinguish between the two contexts. To reduce ambiguity and help users understand capabilities of each, it became important to establish clearer visual separation between these workflows.
TRADEOFFS & CONSTRAINTS #1
In-context action versus focused workflow
Thus, payment link creation was designed as a lightweight, in-context action using a side drawer to support speed and continuity. In contrast, invoice creation required a dedicated page to allow for a more focused review and confirmation of details.
TRADEOFFS & CONSTRAINTS #2
Reusability versus customization
Maintaining reusable patterns supported consistency and reduced engineering work, though some elements needed to diverge based on user context. Filters and graph-related components were adapted to each workflow.
TRADEOFFS & CONSTRAINTS #3
Scope versus complexity
We intentionally did not support tax configurations in v1, and instead prioritized faster payment creation and a simpler experience for early-stage users. Furthermore, this reduced implementation complexity while keeping the initial workflow lightweight.
Payment Links
Invoices
Early layout designs lacked clear visual distinction, making it difficult for users to differentiate between payment contexts.
This led to a shift in direction, where visual differentiation became a key focus in collaboration with tradeoffs and constraints.
In-context action
To create a payment link...
The drawer slides in to reveal quick in-context action to keep users in their current flow without losing context.
For developers, a side drawer added additional complexity, but this approach was prioritized to maintain context and speed while differentiating from the invoices workflow.
Focused workflow
To create an invoice...
The user is taken to a dedicated full-page for review and confirmation since accuracy is more important than speed in this workflow.
