B2B Fintech · Payments Platform · Product Design
iPay Client Portal
A modern B2B payments platform helping client administrators manage cardholders, funding, payment activity, exceptions, reporting, and account operations.
Insert a clean, redacted screenshot or recreation of the Client Portal dashboard (hero shot, 16:10 or wider).
/images/client-portal-dashboard.jpgOverview
Project overview
- Product
- iPay Client Portal
- Platform
- Responsive web application (B2B)
- Role
- UX/UI Designer (2022–2024) → Product Manager (2024–Present)
- Timeline
- 2022 — Present
- Team
- Product, design, and engineering, with business and operations stakeholders
Responsibilities
- Product discovery
- User research
- UX strategy
- Journey mapping
- Interaction design
- Information architecture
- Prototyping
- Visual design
- Usability testing
- Design systems
- Engineering collaboration
- Stakeholder alignment
- Roadmap prioritization & UAT (as Product Manager)
Context
The context
The Client Portal serves business and client administrators who manage cardholder and payment operations on behalf of their organizations. These are high-stakes financial tasks — funding accounts, resolving payment exceptions, reviewing deposit activity — performed by users who need to move quickly without sacrificing accuracy.
The experience has to balance several forces at once: speed for high-frequency operational work, accuracy and clarity for financial decision-making, security for sensitive account and cardholder data, and technical feasibility within an evolving platform.
The Problem
Client administrators were managing complex cardholder and payment operations across fragmented, legacy-feeling workflows. The challenge was to design a modern experience that made high-frequency operational tasks faster, while making payment states, exceptions, and account information easier to understand at a glance — without asking administrators to hold institutional knowledge in their heads.
My Role
What I contributed
I led UX/UI design across key Client Portal workflows — cardholder management, funding, deposit history, ACH rejects and returns, and reporting — working closely with business stakeholders, product leadership, engineers, and end users. My work spanned research, journey mapping, interaction design, prototyping, usability testing, visual design, and collaboration through implementation.
I later transitioned into Product Management, which expanded my responsibilities into roadmap prioritization, requirements definition, UAT, and delivery. I see this as an extension of the same work rather than a departure from it: the product decisions I now make are informed by the UX foundation I built, and the UX decisions I continue to influence are sharpened by a clearer view of business and technical tradeoffs.
Research & Discovery
Research methods
Understanding administrator workflows meant combining direct research with the operational and support signal already flowing through the business.
User Interviews
Conversations with client administrators to understand day-to-day funding, cardholder, and reporting workflows.
Stakeholder Interviews
Sessions with business, operations, and support teams to surface recurring friction and constraints.
Workflow & Support Analysis
Review of support feedback, QA findings, and existing task flows to identify where operational friction was concentrated.
Competitive Review
Evaluation of comparable B2B payments and financial platforms to understand established patterns for dense operational data.
Usability Testing
Structured testing of key flows — cardholder search, funding, and exception handling — to validate direction before build.
Synthesis & Prioritization
Translating findings into design themes and, later, into a prioritized roadmap of improvements.
Research scope: [Add participant count]
User Needs & Insights
What administrators and users needed
Faster access to critical information
Administrators need to quickly locate cardholders, understand account status, and identify what requires action — without digging through multiple screens.
Clear financial states
Funding, deposits, rejects, returns, and account statuses need to be understandable without requiring institutional knowledge of internal processes.
Efficient repetitive workflows
High-frequency administrative tasks should require minimal navigation and as few unnecessary interactions as possible.
Confidence in completed actions
Financial products need to make it unambiguous when an action — funding, an export, a profile update — has been completed successfully.
Visibility into exceptions
Errors and payment exceptions, like ACH rejects, need to be surfaced early and explained in plain language, not buried in a status code.
Information Architecture
Organizing complex functionality
Client administrators move between account-level and cardholder-level context constantly. The information architecture was organized to keep that movement predictable, so the same mental model applies whether an administrator is checking a balance or resolving an exception.
- 01Dashboard
- 02Cardholders
- 03Cardholder Profile
- 04Funding
- 05Deposit History
- 06ACH Rejects / Returns
- 07Reports / Export
- 08Profile / Security
Design Challenges
What made this hard
Designing for information density without overwhelming users
B2B financial tables carry a lot of necessary detail — statuses, amounts, dates, actions — across cardholders, funding, and deposit records. The work was to establish a visual hierarchy, filtering model, and progressive disclosure pattern that kept the data usable at scale, rather than simplifying it away.
Making payment states understandable
Funding, deposits, rejects, and returns each carry their own states and edge cases. Getting this right meant establishing consistent language, color, and iconography for status, and making exception states (like ACH rejects) explain themselves instead of requiring a support call.
Balancing usability and security
Account and cardholder data is sensitive. Flows involving authentication, card details, and account access needed to stay secure — appropriate masking, verification, and permissioning — without adding friction to routine, low-risk tasks.
Designing scalable patterns
With multiple workflows (funding, cardholders, reporting) evolving in parallel, reusable components and interaction patterns were essential so new features could be built consistently rather than each becoming a one-off design.
Design Process
Problem → Exploration → Validation → Refinement → Delivery
Each major workflow moved through the same arc: understand the problem, explore options, validate direction with users and stakeholders, refine, and hand off for delivery.
Problem framing & early exploration
Low-fidelity wireframes and alternative concepts to explore how cardholder and funding information could be organized and prioritized on screen.
Insert early low-fidelity wireframes for the dashboard or cardholder workflow.
/images/client-portal-wireframes.jpgFlows & interaction design
Mapping the end-to-end cardholder and funding flows, including edge cases like exceptions and permission-restricted actions.
Insert a user flow diagram for the cardholder or funding workflow.
/images/client-portal-flow.jpgValidation
Usability testing and stakeholder review of interactive prototypes to confirm direction before high-fidelity design and build.
Insert a prototype screen or annotated flow used in usability testing.
/images/client-portal-prototype.jpgRefinement & high-fidelity design
Refining visual design, states, and edge cases in partnership with engineering ahead of implementation.
Insert a high-fidelity design of the finished dashboard or cardholder profile screen.
/images/client-portal-hifi.jpgDelivery
Supporting engineering through implementation, reviewing build accuracy, and participating in QA/UAT before release.
Insert a final delivered screen with design annotations, or a before/after comparison.
/images/client-portal-delivery.jpgDesign System
Reusable patterns across the iPay ecosystem
I contributed to and helped evolve a set of reusable design patterns and UI standards used across iPay products — established and evolved rather than built from a blank slate, and shared across the Client Portal and Cardholder App where the experiences overlapped.
Tables & data grids
Patterns for dense, sortable financial data with consistent row states.
Filters & search
Reusable filtering patterns for cardholder, funding, and transaction views.
Status indicators
A consistent visual and language system for account, funding, and exception states.
Forms
Standardized input, validation, and error patterns for operational tasks.
Modals & overlays
Consistent patterns for confirmations, detail views, and multi-step actions.
Navigation
Shared primary and contextual navigation patterns across portal sections.
Buttons & actions
A consistent hierarchy of primary, secondary, and destructive actions.
Feedback states
Loading, empty, success, and error states applied consistently across flows.
Authentication patterns
Reusable login, verification, and permission-aware UI patterns.
Insert a component/pattern grid (tables, filters, statuses, buttons).
/images/client-portal-design-system-1.jpgInsert a second design system reference sheet if available.
/images/client-portal-design-system-2.jpgEngineering Collaboration
Designing with technical constraints
Fintech products live within real technical constraints — legacy systems, data limitations, and security requirements. Designing well meant designing with those constraints, not around them.
Worked closely with engineers to understand system and data limitations before finalizing designs.
Clarified edge cases together — partial funding, failed transactions, permission conflicts — so the design accounted for real system behavior.
Reviewed technical feasibility early, and adjusted interaction patterns when a technically simpler approach delivered equivalent user value.
Reviewed implementation against design intent, and supported QA and UAT to catch gaps before release.
As Product Manager, translated product requirements in terms engineering could estimate and sequence, and evaluated tradeoffs between ideal UX and delivery constraints directly with the team.
Payment Domain Expertise
Areas of applied fintech knowledge
- ACH rejects & returns
- Instant funding
- Cardholder management
- Account states
- Payment reporting
- Authentication
- Secure financial information
- Payment exceptions
- Data export
- Client administration
AI-Augmented Product Design
How I use AI in research, design, and product work
AI is part of how I work day to day — it helps me move faster through research, exploration, and early product thinking, while every decision about what actually ships still goes through my own product judgment.
Research synthesis
Using ChatGPT and Claude to organize qualitative feedback from interviews and support notes, identify recurring themes, and generate sharper follow-up questions.
UX exploration
Using AI to quickly generate alternative approaches, edge cases, and content structures to react to and refine, rather than starting exploration from a blank page.
Product requirements
Using AI to help structure requirements, user stories, and acceptance criteria as a first draft, followed by my own review and edits with engineering and stakeholders.
Competitive research
Using AI to accelerate synthesis of how comparable fintech and payments products approach similar problems, as an input to — not a substitute for — my own analysis.
“AI helps me explore faster. Product judgment determines what ships.”
Selected Screens
A closer look
Insert a recreated or redacted screenshot of the cardholder list/search view.
/images/client-portal-cardholders.jpgInsert a recreated or redacted screenshot of the funding workflow.
/images/client-portal-funding.jpgInsert a recreated or redacted screenshot of the reporting/export view.
/images/client-portal-reports.jpgOutcomes
Where this landed
The Client Portal work contributed to a more modern, unified administrator experience and a stronger foundation for continued product iteration.
A more unified experience across cardholder, funding, and reporting workflows.
Improved workflow clarity around payment states and exceptions.
More scalable, reusable design patterns supporting faster delivery of future features.
A continued, iterative migration toward a more modern digital experience.
Ongoing product iteration based on customer and business feedback.
Quantitative results (add if available)
- [Add adoption metric]
- [Add task completion improvement if available]
- [Add usability result if available]
Note: Certain details and visuals on this page have been modified, simplified, or omitted to protect confidential business and customer information.