Case Study · Product Design, Systems Design & Implementation
Role: Product & Systems Designer, Developer
Output: Interactive prototype, simulated async flows, exception handling, multi-currency balances
Impact: End-to-end journey transparency, seven functional exception paths, and a 67-assertion verification suite.
Modeling the money-movement journey
GigPay is a pseudonym for a real product inside the LiveXchange ecosystem. The prototype maps the full earnings journey for gig workers. It covers everything from completed work to money in the bank.
I mapped the operational domain and designed the state transitions. I also built a working prototype to simulate async behavior. This approach established design foundations ready for production.
The problem: disconnected visibility and dead-end exceptions
Marketplace workers face a confusing path from completed work to actual pay. Pending statuses lack context. Available balances feel detached from the original earnings.
When transfers fail or hit daily limits, workers see generic errors. The system rarely explains what went wrong. Workers also struggle to understand conversion rates and fees when dealing with multiple currencies.
Designing the operational model
The prototype relies on a strict data model and clear state transitions.
Reconcilable balances
The entry point shows Available and Pending totals per currency. These figures sum up specific seeded earnings. The balances automatically reconcile if the seed data changes. Status badges use text and color. They never rely on color alone.
Contextual exception handling
I transformed seven generic error states into actionable paths. Every blocked state explains what is known and what remains uncertain. It also provides the exact next step. An earning with an invoice issue explains the disputed lines. It offers a resubmit action that returns the earning to pending.
A failed transfer caused by a daily receiving limit returns the full amount to the available balance. The interface offers exactly what is possible today: a partial payout within the remaining limit.
Transparent payout setup
Destination selection and currency conversion happen in a single step. A live summary strip shows fees and arrival estimates. The review screen provides a complete fee breakdown. Every amount pairs with its currency. The screen also notes that exchange rates lock at confirmation.
Trackable async journeys
A growing timeline component separates confirmed events from estimates. The payout record becomes trackable once initiated. The timeline only moves forward.
Prototyping the system at realistic scale
I built a working front-end prototype to make interaction decisions tangible. The prototype uses a single state-driven object in vanilla JavaScript and CSS. It simulates async progression using timers. The timeline grows and balances update in real time.
This approach allowed me to evaluate complex flows against actual workflows. I could test a daily-limit partial payout or a failed bank transfer directly in the browser.
Design system foundations and verification
The prototype established reusable patterns for production handoff.
Semantic tokens
Color roles map directly to user intent. The default theme is light with a dark-mode option.
Responsive patterns
Tables degrade to card rows on smaller screens. Balance grids stack neatly on mobile.
Accessibility
The interface includes strict keyboard navigation and ARIA roles for dynamic summaries.
Headless verification
A 67-assertion test suite validates the happy path and all exception branches. It ensures the prototype behaves as a reliable specification.
Scale and impact
The outcome is an interactive model of a complex money-movement system.
- Seven fully functional exception flows with clear resolution paths.
- 67 headless assertions guaranteeing state consistency across the user journey.
- Zero dependencies and no build step, making the artifact permanently portable.
- Complete fund security logic, ensuring failed transfers automatically return all money to the available balance.
Reflection
This project highlighted the importance of relationships between states. Business rules directly affect interface behavior. Operational constraints shape user trust.
Working code makes these state transitions tangible. It exposes requirement gaps early. I realized a daily-limit partial payout needed a new field on the payout record. Resilient exception handling became a core feature of the product. Treating the working prototype as the specification unified design and implementation. The final result was evaluated against real operational needs.
