Overview
- The problem
- Users need to understand which account they are viewing, how it is performing, what its restrictions mean, and what is required before taking the next action.
- My contribution
- I redesigned the Client Portal experience and its supporting design system at Saphyte, including account, performance, challenge, verification, and payout workflows.
- The outcome
- A connected set of original interface designs, a reusable multi-brand design-system library, and a publicly accessible interactive Figma Sites demo.
A branded trading portal connects account management, challenge purchase, verification, and payouts. I focused on making the dependencies between these tasks understandable within a coherent self-service journey.
Problem
The original screens and interactive demo expose the dependencies between account switching, performance, challenge purchase, verification, and payout. I used these connected workflows to frame the redesign.
My Role
- Company / product context
- Saphyte · Client Portal redesign
- Users
- People managing funded and challenge trading accounts through a branded client portal.
- My role & scope
- I redesigned the Client Portal experience and its supporting design system at Saphyte, including account, performance, challenge, verification, and payout workflows.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
I owned the portal UX and UI redesign and its reusable multi-brand design library at Saphyte. My scope covered account hierarchy, overview and analysis, challenge comparison and checkout, verification states, payout readiness, and handoff-ready component patterns.
Process
I explored populated, empty, and cancelled accounts alongside the stages of verification and payout. Comparing these states helped define which context should remain stable as the available actions changed.
Design the account states
I designed the dashboard beyond the populated example. An empty state explains where future performance and trades will appear. A cancelled state names the account condition and changes the surrounding guidance, rather than silently removing information.
Original Figma state designs. The surrounding account context remains visible as the content changes.The demo lets a reviewer move between the account states and inspect how the surrounding context and available actions change.
Key Decisions
Account status, performance, eligibility, and payout readiness need distinct explanations. I kept the overview compact for quick checks and placed deeper analysis and action-specific requirements in dedicated views.
Key design decisions
Keep the selected account in view
A persistent account selector and local account identity connect balances, performance, and actions to their scope. The account overview provides a separate place to compare account states.
Inspect the account hierarchyExplain readiness before the action
Verification and payout designs pair status with required steps, submitted evidence, eligibility context, and a next action. A balance alone is not presented as permission to withdraw.
Explore payout contextTreat empty and cancelled states as product states
A dashboard without trading data and a cancelled account need distinct explanations. Reusing the surrounding structure helps preserve orientation when the normal populated experience is unavailable.
Compare the source states
Final Solution
The final design set connects account context to performance, challenge selection, verification progress, and payout eligibility. The following original screens and demo expose the surrounding states and interaction intent.
Keep account context visible
I organized the portal around Overview, Management, Finance, Compliance, and Resources. The selected trading account stays in the top navigation, while the account overview shows funded, challenge-phase, completed, and breached examples together.
The distinction is between looking across accounts and working within one. Account cards expose identity, platform, state, balance, equity, and profit context. The persistent selector then carries the selected account into performance and action-oriented destinations.
Account overview and empty-state designs.The Dashboard gives the user an overview: balance and daily results, performance charts, risk limits, open positions, and recent trades. Analysis Hub provides a separate reading depth for instrument breakdowns, drawdown, consistency, calendar patterns, and trade statistics.
This separation distinguishes the frequent question ‘what is my current position?’ from investigation into a pattern. The design intent is to make both reading speeds available without turning every dashboard visit into an analytics task.
A deeper analytical destination alongside the overview.Explain a challenge before checkout
Challenge selection connects the evaluation model, account size, platform, and its visible conditions before a payment step. The comparison design puts alternative models in the same view, giving the user a place to inspect differences before choosing.
Challenge selection and checkout, with illustrative prices and conditions.The design trade-off is density: the conditions needed to understand a challenge are numerous. Grouping them into a comparable structure preserves the detail while making the choice a visible step, rather than burying it inside checkout.
Make verification progress actionable
The verification designs distinguish required identity material from additional document groups. Requirements, accepted formats, uploaded files, and review status sit within the document sections, while the overall progression remains visible above them.
KYC document preparation and review states.I included an automated verification route alongside manual upload so that the interface could accommodate both entry paths.
The source iterations group requirements differently. Before implementation, profile notices, navigation counts, document sections, and payout eligibility need one agreed requirement model.
Make payout readiness inspectable
The Payouts overview separates historical status from the request itself. Summary values and a transaction table make approved, pending, processing, and rejected examples inspectable, while local tabs expose withdrawal and saved-method destinations.
Payout history and request actions share a navigation family.The withdrawal direction separates account selection, withdrawal details, and review. Available amount, minimum and maximum context, and method-dependent information remain beside the form in an account summary.
Two payout directions expose eligibility and account context before commitment. Thresholds are illustrative.The useful design question is not only whether a withdrawal control is enabled. It is whether a user can explain what is available, which account it belongs to, and what still needs to happen. Eligibility information and a staged request address those questions at different depths.
Connect the experience through a shared system
I redesigned the supporting library as well as the product screens. Primitive and semantic variables carry branded themes, while reusable navigation, inputs, buttons, state cards, and progress patterns provide a shared vocabulary across the portal.
The dashboard uses remote library instances for navigation and supporting elements. The companion system case study explains how those foundations connect to complete portal workflows.
Outcomes
I delivered a connected portal redesign, a supporting multi-brand design system, and an interactive Figma Sites demo.
Evidence & limitations
The evidence consists of original Figma designs, library instances, and an interactive Figma Sites demo. Balances, fees, thresholds, identities, and processing-time or security copy are sample design content, not current financial terms. The record does not establish a production launch, live trading connectivity, integrated payment or verification providers, measured impact, or a tested iteration timeline.
My ownership covers UX, UI, and the design library. Payment infrastructure, compliance policy, production engineering, and validation of user comprehension sit outside this design record.
What I would validate next
- Whether participants can identify the active account before explaining a balance or action.
- Comprehension of challenge differences before checkout.
- Understanding of required documents, submitted evidence, and review status.
- Whether users can explain payout readiness, restrictions, and the review step.
- Accessibility, responsive behavior, and consistency between source designs and implementation.
Learnings
- What worked in the design
- Account context stays connected to the action and its requirements.
- What I would change next
- Test account switching, eligibility explanations, and recovery with representative users before comparing task success against an implemented baseline.
Delivery and reflection
The documented delivery is a connected product redesign, a shared library, and an interactive demo. The source covers populated and exception states across account management, performance, selection, verification, and finance.
- Account scope should remain understandable across destinations.
- Readiness states need an explanation and a next action.
- Overview and investigation benefit from different information depths.
- A multi-brand system needs semantic roles as well as reusable visual parts.
