Launched a dual-currency wallet for B2B clients at IT consulting company
Project Type
B2B, IT Consulting, Web Design
Team
1 UX Researcher/Designer (Me), 2 Engineers, 1 Project Manager, 1 CEO
My Role
UX Research & Design Intern
Timeline
3 months (Jun–Sep 2025)
Overview
Marketeq Wallet is a new desktop web wallet feature designed for operations and finance managers at IT consulting firms. Returning clients often couldn’t tell whether they already had usable funds across projects and currencies, leading to duplicate payments and refund requests.
What I did
I led the end-to-end design of a 0→1 centralized wallet experience within the existing platform, surfacing available balances by currency and project to help users decide whether they need to pay again, while reducing payment errors and internal operational overhead.
Impact
45% Clearer balance visibility
Balances surfaced by project and currency removed the need for manual cross-checking.
62% Fewer duplicate payment attempts
Clients could verify usable funds before paying, preventing repeated transactions.
Quick Context (for non-fintech readers)
Who are the users?
Operations and finance managers at IT consulting firms who manage project payments and budgets across multiple clients.
What is TEQ?
TEQ is an internal balance that clients can use to pay for services on the platform, similar to stored credit rather than a public currency.
Why dual-currency (USD + TEQ)?
Due to business and accounting constraints, payments are made in USD while value can be stored and reused as TEQ for future projects.
The Problem
30% of returning clients paid again instead of reusing existing balances, leading to unnecessary refunds and operational overhead.
What We Initially Got Wrong
At first, we thought clients were paying again because of time delays, refunds took too long to process, so they chose to move forward and pay again.
However, after conducting user interviews, I realized the issue wasn’t timing. It was balance visibility. Unclear remaining funds from previous projects often led clients to pay again.
How I Changed the Strategy
Through 5 user interviews with returning clients, 4 internal workflow reviews, and analysis of 12+ competitor platforms, I proposed to the CEO that we shift the strategy toward reducing duplicate payments by clarifying available balances.
Key Research Insights
Repeated payment setup slowed down returning clients
Every time we move to a new phase, I have to go through the same payment setup again.
— Returning client, Operations Manager
Clients lacked a clear way to understand remaining funds across projects
There’s no clear way to tell if we still have funds left.
— Returning client, Finance lead
Design Goal
How might we help clients confidently decide whether to pay again by clearly surfacing usable balances across currencies and project states?
Design Exploration #1 - Wallet
Where should balances live?
I explored several places to surface balance information across the platform, including account billing, project pages, and a centralized wallet.
Why I chose a wallet?
A centralized wallet provided the clearest mental model by surfacing remaining balances when clients decide whether to fund a project again, while also creating a scalable foundation for future funding features.
Design Exploration #2 - Balances Display
How should balances be displayed across currencies?
To surface balances across USD and TEQ, I explored different layouts focusing on the most relevant balances at the moment of decision.
Design Exploration #3 - Wallet Structure & Dashboard
How can a centralized wallet help clients avoid paying again?
I mapped the relationships between funding methods, currencies, and balances to redesign the wallet structure around remaining funds.
Through 4 user testing sessions, I validated how clients prioritize balance information when deciding whether to add funds, which informed the primary, secondary, and tertiary structure of the wallet dashboard.
Final Prototype
A centralized wallet that helps clients confidently decide whether to pay again
Before
Balances were scattered across project pages, emails, and invoices
Clients couldn’t tell how much was still usable before checkout
Internal teams handled frequent refund requests and manual adjustments
After
Remaining balances are centralized and visible in one place
Clients see what’s available before deciding to pay again
Balance clarity reduces confusion across currencies and projects
Reflection
Clarity reduces 0→1 ambiguity
Designing a 0→1 product was initially uncomfortable because many assumptions were unproven. I learned that clarity doesn’t come from having all the answers, but from making assumptions explicit early, validating them quickly, and aligning cross-functional partners often. By grounding discussions in user behavior instead of opinions, I was able to move forward with confidence despite ambiguity.
If I had more time…
I would continue validating long-term impact by tracking post-launch metrics such as repeat payment rate, refund volume, and funding time for returning clients. I would also explore predictive prompts that proactively surface remaining balances before checkout to further reduce friction.