Loading
Loading
case
case
study
study
2025
2 weeks
Product design
Context & Roles
Profi is built as a platform with workspaces representing business units (companies, departments, or independent providers). Each workspace is managed by Workspace admins, while Platform admin oversee multiple workspaces and control permissions and payment infrastructure.
Workspaces share a single platform-level Stripe account, managed by the platform admin
Problem
Signals about refund difficulties came from Platform admins, because Workspace admins (who interact directly with clients and services) could not process refunds themselves and requested the Platform admin to handle it. This caused:
High time spent on processing refunds
Occasional mistakes due to missing or fragmented information
Delayed or inaccurate client communication → Frustrated clients and reduced trust
Goal
Eliminate operational dependency and context loss in the refund process by enabling Workspace admins to handle refunds independently.
Success criteria
Workspace admins can issue full or partial refunds without involving platform admins
Workspace admins clearly understand the current refund status and history to confidently communicate with clients.
The solution reduces the risk of errors or double refunds.
My role
As a Product Designer, I owned the end-to-end user experience: analyzing existing workflows, designing a solution that is safe, reliable, and transparent for admins, collaborating with PM, CS, and devs to align with business and technical requirements, design review and gathering post-release usage feedback to refine the solution.
Discovery
Analyzed refunds in Stripe
I checked the refund lifecycle, statuses, time delays in fund visibility, partial refund rules, and common failure cases. This showed that refunds are not a single action but a stateful, delayed process with intermediate statuses.
Interviewed Customer success
Customer Success teams train Platform admins and handle daily feedback. What I learned:
Explaining refund status to a client. Admins are repeatedly asked whether a refund was issued and why money hasn’t arrived yet, which requires visibility into both the current state and the full status history.
Admins search payments by client or service name.
Job stories based on problem and discovery
Analyzed current Payment section
Found that it presents data as a list of transactions. Technically, each movement of funds is represented as a separate row.
🔴 Critical insight: Transaction-based model blocks refunds
Transactions are immutable, isolated events → Refunds become detached records, partial refunds are unclear, and there is no single source of truth for a deal. By moving to a unified payment entity, all related transactions are consolidated in one place, giving admins clear status, full history, and easier tracking.
Stripe provides this unified entity, called a Payment. After outlining the risks of the transaction-based model, I secured team approval to move to a Payments-based model.
Aligned with Devs → Front-end update
Switching to a payments-based model required changes to the database. The old table was legacy and incompatible, so rebuilding was unavoidable. Using new table components—already implemented in other sections—made development faster and ensured support for dynamic statuses.
Solution
Search & filtering → enables admins to quickly find payments to issue refund or check its current status.
Payments-based → each row provides a single source of truth for accurate client communication.
Built with actual components → reducing development effort, eliminating legacy complexity, and supporting dynamic status updates.
Full status history → provides a complete timeline of refund events, helping admins understand what happened and clearly explain it to clients.
In-platform refunds → support both full and partial refunds and significantly reduce admin time by eliminating the need to involve a platform admin:
Validation
Approach
Formal usability testing wasn’t feasible. Validation was done through Customer Success using real admin scenarios.
What was validated
Do workspace admins understand the payment-centric model?
Can they confidently explain pending, partial, and fully refunded states during client communication?
Can they clearly see how much was refunded?
Outcome
The solution gave workspace admins a clear, trustworthy payment state they could confidently communicate to clients.
Handoff
All refund states, flows, and error cases were documented and handed off to engineering.
Release & Impact
They later became responsible for supporting and educating workspace admins within their organizations.
Refunds are now processed much faster, with full visibility of status and history.
The shift from transaction-level auditing to a payment-centric model reduces errors and enables confident client communication.
The revamped payments section gives Platform admins confidence in managing client relationships and provides full transparency of refunds and payments, making the platform more trustworthy and attractive to potential customers during demos.