GuyBarSinai

Home

About

LinkedIn
Resume

GuyBarSinai

GuyBarSinai

Home

About

LinkedIn
Resume
Case Study
Case Study
Case Study

Pool | Collaborative & Personal Savings

Collaborative savings platform enabling structured group financial goals and transparent contribution tracking.

View App prototype
View App prototype

Role: Product Design

Deliverables: App prototype + marketing website

Focus: Transparency & trust

Problem Context

Saving toward a shared goal breaks down fast. Without one place to track who contributed what, groups fall back on messages and mental math. Pool gives everyone a shared view that updates automatically, no check-ins needed.

No clear view of who contributed what.

No clear view of who contributed what.

No clear view of who contributed what.

Progress feels abstract and unmotivating.

Progress feels abstract and unmotivating.

Progress feels abstract and unmotivating.

Asking about money creates tension.

Asking about money creates tension.

Asking about money creates tension.

Designed in dialogue with Figma Make

Key screens and component variants were explored using Figma Make as an active design partner. Generating layout alternatives, testing edge cases, and stress-testing the contribution flow before committing to final decisions.

Saving goals screen options

Option 1- Grid

Option 2- Carousel

Option 3- List

Option 4- Segments

Option 5- Split

Connect Bank screen options

Option 1- List

Option 1- List

Option 2- Grid

Option 2- Grid

Option 3- Cards

Option 3- Cards

Option 4- Modal

Option 5- Split

Option 5- Split

Design Decisions & Trade-off

Key screens and component variants were explored using Figma Make as an active design partner. Generating layout alternatives, testing edge cases, and stress-testing the contribution flow before committing to final decisions.

Decision

Spectrum, not binary

The same Pool structure works for personal goals (1 contributor) and shared goals (2+ contributors). Reality has a single underlying need: track progress toward something specific. Splitting this into separate experiences would force users to learn two interfaces for the same mental task. By keeping the structure identical, a user learns Pool once and reuses it across every saving context. The trade-off: features that only make sense in shared mode (invitations, member visibility, contribution attribution) had to feel optional in personal mode, never as separate UI.

Decision

Spectrum, not binary

The same Pool structure works for personal goals (1 contributor) and shared goals (2+ contributors). Reality has a single underlying need: track progress toward something specific. Splitting this into separate experiences would force users to learn two interfaces for the same mental task. By keeping the structure identical, a user learns Pool once and reuses it across every saving context. The trade-off: features that only make sense in shared mode (invitations, member visibility, contribution attribution) had to feel optional in personal mode, never as separate UI.

Decision

Spectrum, not binary

The same Pool structure works for personal goals (1 contributor) and shared goals (2+ contributors). Reality has a single underlying need: track progress toward something specific. Splitting this into separate experiences would force users to learn two interfaces for the same mental task. By keeping the structure identical, a user learns Pool once and reuses it across every saving context. The trade-off: features that only make sense in shared mode (invitations, member visibility, contribution attribution) had to feel optional in personal mode, never as separate UI.

Trade-off

Transparency Vs. Comparison Anxiety

Showing each contributor's individual amount in shared pools removes the need for awkward questions and hidden assumptions. But the same transparency also creates visible comparison: "Dan saved 32%, I saved 17%". The risk is shame or social pressure. The mitigation: Pool shows progress, not performance. No leaderboards, no penalties, no nudging notifications. Members see contributions but the UI never frames them as competition or ranks them by amount. The trade-off was conscious: full transparency requires careful copy and visual treatment to stay supportive, not judgmental.

Trade-off

Transparency Vs. Comparison Anxiety

Showing each contributor's individual amount in shared pools removes the need for awkward questions and hidden assumptions. But the same transparency also creates visible comparison: "Dan saved 32%, I saved 17%". The risk is shame or social pressure. The mitigation: Pool shows progress, not performance. No leaderboards, no penalties, no nudging notifications. Members see contributions but the UI never frames them as competition or ranks them by amount. The trade-off was conscious: full transparency requires careful copy and visual treatment to stay supportive, not judgmental.

Trade-off

Transparency Vs. Comparison Anxiety

Showing each contributor's individual amount in shared pools removes the need for awkward questions and hidden assumptions. But the same transparency also creates visible comparison: "Dan saved 32%, I saved 17%". The risk is shame or social pressure. The mitigation: Pool shows progress, not performance. No leaderboards, no penalties, no nudging notifications. Members see contributions but the UI never frames them as competition or ranks them by amount. The trade-off was conscious: full transparency requires careful copy and visual treatment to stay supportive, not judgmental.

Trade-off

Bank Connection Vs. Onboarding Friction

Connecting to a bank account makes contributions accurate and automatic - the gold standard for fintech UX. But asking for bank credentials is the highest-friction step in any onboarding flow. Many users drop off here. The decision: offer bank connection as the primary path through a trusted intermediary, but always provide a secondary "continue without bank" exit, framed as a legitimate choice rather than a fallback. The trade-off: less accurate data for manual-entry users, but no onboarding cliff that loses people before they create their first pool.

Trade-off

Bank Connection Vs. Onboarding Friction

Connecting to a bank account makes contributions accurate and automatic - the gold standard for fintech UX. But asking for bank credentials is the highest-friction step in any onboarding flow. Many users drop off here. The decision: offer bank connection as the primary path through a trusted intermediary, but always provide a secondary "continue without bank" exit, framed as a legitimate choice rather than a fallback. The trade-off: less accurate data for manual-entry users, but no onboarding cliff that loses people before they create their first pool.

Trade-off

Bank Connection Vs. Onboarding Friction

Connecting to a bank account makes contributions accurate and automatic - the gold standard for fintech UX. But asking for bank credentials is the highest-friction step in any onboarding flow. Many users drop off here. The decision: offer bank connection as the primary path through a trusted intermediary, but always provide a secondary "continue without bank" exit, framed as a legitimate choice rather than a fallback. The trade-off: less accurate data for manual-entry users, but no onboarding cliff that loses people before they create their first pool.

If the work made sense to you,

let's talk.

guybsn@gmail.com

LinkedIn
Resume

One Mental Model

Pool is built around one idea: define a target, track contributions, see where things stand. Whether saving alone or with a group, the structure is identical — one goal, one pool, one shared view of progress. This single mental model drives every screen in the product.

System Design

The system is built around a single contribution model, transparent, role-based, and immutable. Four layers govern how money moves, who sees what, and how the interface responds automatically.

1 - Contribution rules

Each pool defines its own input method and split logic, manual or bank-synced.

2 - Goal tracking

Progress is calculated automatically from validated transactions, no manual updates needed.

3 - Member roles

Visibility and permission rules are set at pool creation, no one can move money without an explicit action.

4 - Transparency layer

Every member sees a shared live view of progress and individual inputs, updated on every validated transaction.

The diagram below maps how these four layers translate into the token architecture. Foundation tokens define the grid and spacing rules. Surface and action tokens govern how contribution states appear. Status tokens trigger automatic responses when a payment is late or a goal is reached. Real-time goal tracking sits at the top, always visible, always current.

Token: surface/card

Token: surface/card

Token: surface/card

Scalable semantic architecture

Scalable semantic architecture

Scalable semantic architecture

Token: status/warning

Token: status/warning

Token: status/warning

Automated state response

Automated state response

Automated state response

Foundation: Radius-md

Foundation: Radius-md

Foundation: Radius-md

Modular system rule

Modular system rule

Modular system rule

Token: action/primary/bg

Token: action/primary/bg

Token: action/primary/bg

Predictable financial pattern

Predictable financial pattern

Predictable financial pattern

Token: surface/stack

Token: surface/stack

Token: surface/stack

Data-driven member display

Data-driven member display

Data-driven member display

Token: text/secondary

Token: text/secondary

Token: text/secondary

Real-time goal tracking

Real-time goal tracking

Real-time goal tracking

Token: text/primary

Token: text/primary

Token: text/primary

Predictable visual rhythm

Predictable visual rhythm

Predictable visual rhythm

Foundation: Spacing-md

Foundation: Spacing-md

Foundation: Spacing-md

Strict grid for visual trust

Strict grid for visual trust

Strict grid for visual trust

Key Screens

Core user flows demonstrating contribution clarity and shared visibility.

Shared Progress

Shared Progress

What this solves: group members can see who contributed and who hasn't, without anyone needing to ask.

What this solves: group members can see who contributed and who hasn't, without anyone needing to ask.

Transparency

Group accountability

Passive visibility

Contribution status is visible at a glance (Contributed / Not yet)

Contribution status is visible at a glance (Contributed / Not yet)

One shared view keeps accountability calm and consistent

One shared view keeps accountability calm and consistent

Contribution Flow

What this enables: flexible inputs that feed the same shared model, whether you log manually or sync a bank.

What this enables: flexible inputs that feed the same shared model, whether you log manually or sync a bank.

What this enables: flexible inputs that feed the same shared model, whether you log manually or sync a bank.

Flexible input

Read-only bank sync

Trust by design

Start manual, connect later, read-only bank sync is optional

Progress is calculated the same way regardless of input method

Log expense & settle up

Log expense & settle up

What this supports: logging shared costs and settling up without turning money into a social tension point.

What this supports: logging shared costs and settling up without turning money into a social tension point.

Expense logging

Settle up

No social friction

Quick logging with smart defaults for common shared costs

Quick logging with smart defaults for common shared costs

Clear settlements when it’s time to balance

Clear settlements when it’s time to balance

The App Needed a Front Door

The App Needed a Front Door

People don't download financial apps on impulse. Before committing, they need to understand the model, trust the product with their bank, and feel confident it won't create friction with their group. The app can't answer those questions on its own — so I designed a companion marketing website as a deliberate part of the product experience, sharing the same tokens, voice, and color system.

People don't download financial apps on impulse. Before committing, they need to understand the model, trust the product with their bank, and feel confident it won't create friction with their group. The app can't answer those questions on its own — so I designed a companion marketing website as a deliberate part of the product experience, sharing the same tokens, voice, and color system.

The Trust & Transparency page was designed to answer the question every potential user is silently asking before they hit download.

Outcome

Outcome

Pool demonstrates that shared saving can work when the system removes the social friction. The single mental model for solo and group goals, contribution status visible at a glance, and explicit read-only boundaries point toward a way to save together without the awkwardness of asking where the money went.

Pool demonstrates that shared saving can work when the system removes the social friction. The single mental model for solo and group goals, contribution status visible at a glance, and explicit read-only boundaries point toward a way to save together without the awkwardness of asking where the money went.

What I'd measure

Goal Completion Rate

Did the group reach its savings target? This is the core promise of Pool. Low completion signals either unrealistic goals or contribution drop-off along the way.

Goal Completion Rate

Did the group reach its savings target? This is the core promise of Pool. Low completion signals either unrealistic goals or contribution drop-off along the way.

Active Participation Rate

How many group members contribute consistently over time? One active member in a group of four is a UX failure, not a user failure.

Active Participation Rate

How many group members contribute consistently over time? One active member in a group of four is a UX failure, not a user failure.

Bank Connect Completion

What share of users who start the bank sync flow complete it? Drop-off here signals a trust or clarity problem in the permissions screen.

Bank Connect Completion

What share of users who start the bank sync flow complete it? Drop-off here signals a trust or clarity problem in the permissions screen.

What This Proves

What This Proves

Pool demonstrates that the same design system can serve solo savers and group savers without forcing users to learn two products. The key insight: people don't save in fundamentally different ways when alone or with others. They save toward a target, see progress, and adjust pace. By treating "shared" as a configuration of "personal" rather than as a separate product, Pool reduces cognitive overhead while opening the door to multi-user dynamics when they're useful. The transparency, the trust controls, and the manual escape hatches all serve a single thesis: design that respects users' agency over their money.

Pool demonstrates that the same design system can serve solo savers and group savers without forcing users to learn two products. The key insight: people don't save in fundamentally different ways when alone or with others. They save toward a target, see progress, and adjust pace. By treating "shared" as a configuration of "personal" rather than as a separate product, Pool reduces cognitive overhead while opening the door to multi-user dynamics when they're useful. The transparency, the trust controls, and the manual escape hatches all serve a single thesis: design that respects users' agency over their money.

If the work made sense to you,

let's talk.

guybsn@gmail.com

LinkedIn
Resume

© 2026 Guy Bar-Sinai