Capital One
Enterprise Account Servicing Experience for Android
Scope
Native Android servicing app spanning multiple account types and back-end systems, with high-stakes transactional flows and third-party payment constraints (including Zelle).
Role
Design lead for Android money movement. Owned end-to-end UX for transfers and payments, including edge cases and error recovery, in close partnership with product and engineering.
Overview
Capital One was shifting from a slow, web-wrapped servicing app to a fully native Android experience. The hardest problem was not visuals. It was designing a unified servicing model for customers with multiple Capital One products, including high-stakes money movement.
Destination
Enable one login and a consistent, trustworthy servicing experience across account types, while honoring Android platform patterns and product-specific rules.
What success looks like
My focus was designing a consistent servicing experience where customers could move between account types without friction, while still feeling distinctly Android and unmistakably Capital One.
Key objectives:
- Single login across products
- Consistent model across account types
- Native Android patterns that feel intuitive and trustworthy
Role & Scope
Design lead for Android money movement and key servicing surfaces. Owned bill pay (bank and card), transfers, payees, and person-to-person payments, and designed adjacent experiences like Branch/ATM Finder, profile updates, notifications, and first-time login to keep the servicing model consistent end to end.
Constraints that shaped the work
- Multiple back-end systems and account types with different rules
- Complex, regulated flows with dynamic states and error recovery
- Third-party payment integration constraints (Zelle) that did not match Capital One UX patterns
Outcomes
Shipped within Capital One’s native Android app, reaching ~6.5M users and contributing to broader digital servicing adoption. The experience was later recognized through industry awards, including J.D. Power and Webby recognition.
Research & Discovery
Research and discovery were largely completed before I joined, and that work set a strong foundation for product direction (TAM, personas, competitor analysis, and early concepts with accessibility and regulatory requirements in mind).
Those findings pointed to a hub-and-spoke servicing model, which tested best and became the backbone of the experience.
When I joined, I built on that foundation and drove research and design decisions specific to money movement, focusing on:
- how customers expected transfers and payments to be organized across account types
- clarity around timing, status, edge cases, and recovery
- platform-appropriate patterns for iOS and Android so the experience felt native, not adapted
We validated organization and clarity through iterative usability testing (moderated in-person and unmoderated), starting with wireframe concepts and moving into working prototypes as flows matured.
Gorilla research at Tysons Corner
Before Capital One had formal research labs, we got scrappy. Our office sat next to Tysons Corner, which made it easy to pressure-test ideas with real people fast.
We worked in pairs. One person recruited participants (usually with a Starbucks or Amazon gift card) while the other ran the session. Depending on fidelity, I brought a test device or simple black-and-white printouts.
This approach helped us validate flows, spot friction early, and get perspective outside the design bubble. When I started refining money movement patterns, it became a reliable way to test clarity, timing expectations, and edge-case comprehension without slowing delivery.
As the research function matured, I transitioned to lab-based usability testing for deeper studies. But those early mall sessions set the tone. Move quickly, test what matters, and let real users keep you honest.
One early finding: users expected transfer timing and status to be explicit, so we standardized confirmation and pending states across flows.
Applying Patterns at Scale
The core servicing model was established before I joined this area of the work. My role was applying it consistently across money movement flows and extending it to supporting surfaces like Menu, Settings, and ATM Finder.
Rather than designing one-off screens, I focused on making the model hold up under real constraints:
- multiple account types with different rules and states
- regulated transactional behavior (timing, status, confirmations)
- predictable handling of edge cases and recovery paths
- third-party dependencies that introduced failure modes
I used wireframes and working prototypes to map end-to-end flows, pressure-test states and error handling, and keep the experience coherent as customers moved through tasks across the app.
Even within an established model, the complexity was making it consistent, scalable, and resilient across surfaces and edge cases.
MVP Branch/ATM Finder (cross-surface pattern example)
Applied the same task-based servicing pattern beyond money movement
so navigation and actions stayed consistent.
Pay Bill (errors, edge cases, recovery and cross-surface pattern example)
Bill Pay within the shared servicing model, showing how we handled errors
and recovery without breaking the flow.
Visual Design & User Experience
Visual design choices were in service of clarity and trust. Money movement is high-stakes, so the interface needed to communicate what’s happening, what’s next, and what to do if something goes wrong.
Principles I designed to
- Clarity over density: prioritize the primary action and reduce scanning
- Trust through status: make timing, confirmation, and pending states explicit
- Predictable recovery: errors should explain what happened and offer a next step
- Platform-appropriate patterns: follow Android conventions while staying on brand
What I applied across the experience
- Consistent hierarchy and spacing for task pages and forms
- Standardized components and interaction patterns across money movement and supporting surfaces (Menu, Settings, ATM Finder)
- Clear status language and state visuals for pending, completed, and failed outcomes
Error handling overview
Standardized error patterns and recovery actions so failures were understandable and fixable.
Notifications (happy path)
Consistent notification patterns to confirm outcomes and reduce anxiety around money movement status.
A Layered Model
To manage complexity and give customers a clear mental model, I implemented and applied an Action Layer that sits above the product-branded Explore Layer. The Action Layer used a distinct cyan app bar to signal, “You’re in a task,” and kept task flows account-agnostic.
This allowed us to support cross-account actions like transferring funds, paying bills, or finding an ATM without disrupting the underlying account experience. It also became the foundational pattern for money movement because it stayed consistent regardless of which product the customer started from.
Why it mattered
- reduced context switching for multi-product customers
- kept task flows consistent across account types
- created a predictable place for status, confirmation, and recovery
App layers model.
The Action Layer sits above product-branded Explore to support account-agnostic tasks like money movement.
Add payee
Progressive disclosure and review moments to support compliance-heavy inputs without overwhelming customers.
Internal transfers
Clear timing, status, and confirmation patterns so transfers felt trustworthy across account types.
Complex Flows
Guiding users through heavy lifts
Not every money movement task is quick. Flows like adding a payee or moving larger amounts triggered multiple backend calls, dynamic field states, and compliance requirements. The risk was losing user confidence when the UI changed state or required extra verification.
The hub-and-spoke model helped keep customers anchored, while the Action Layer provided a consistent frame for step-by-step progression.
To keep complexity from feeling chaotic, I relied on a few repeatable UX moves:
- progressive disclosure for dense inputs and legal content
- clear status and timing cues so users knew what was happening
- summary and review moments to confirm intent before submission
- inline edits and recovery paths so users could correct issues without restarting
My goal was to make complex tasks feel predictable and controlled, even when the system behind the scenes was doing a lot of work.
Motion
Material 1.0 shipped with clear motion principles, but relatively few baked-in components. That created space to design motion intentionally, not as decoration, but as UX.
I partnered directly with engineers to design custom transitions and microinteractions that:
- communicated progress during multi-step tasks
- reinforced hierarchy when switching contexts
- made destructive actions feel deliberate and reversible
Working side-by-side with developers mattered here. We tuned pacing, weight, and easing together until interactions felt natural, consistent, and unmistakably Android.
Cancel payment
Makes reversal feel safe and explicit.
Microinteractions
- Canceling a payment
- Switching profiles
- Deleting a profile
Motion was a tool for clarity and confidence, with just enough delight to make the experience feel polished.
Delete profile
Adds intentional friction and clear confirmation for a destructive action.
Switch profile
Reinforces context change.
Balancing Brand Integrity with Partner Integration
Capital One already had a working person-to-person payment experience, and we were exploring improvements, including letting customers choose a preferred payment app. Then Zelle® entered the picture with non-negotiable constraints:
- Zelle had to be embedded in our app
- users would be auto-authenticated
- the flow followed a rigid, serial structure
- their UI patterns and visual language did not match Capital One’s
I reviewed Zelle’s prototype and brand guidance and documented gaps across usability, visual consistency, and edge cases (including missing states and recovery paths). I shared a detailed findings doc with design and product leadership to align on risks and negotiation points.
The direction was simple: integrate Zelle without breaking the servicing model.
From there, I designed an approach that preserved Capital One’s standards while meeting Zelle’s requirements, adapting their linear flow into a structure that felt integrated, predictable, and Capital One-authentic.
1. Baseline: original P2P flow (what existed)
2. Concepts: options for implementing Zelle (diverge)
3. Model: hub-and-spoke concept for P2P/Zelle (converge)
4. Final: serial Zelle flow (what shipped / final direction)
Development
Scaling Craft and Collaboration
I partnered closely with Wilmington-based product and engineering teams to bring the Android experience to life, working day-to-day with tech leads and developers to ship high-stakes servicing flows with quality and consistency.
We launched the Capital One Android app to ~6.5M users in November 2015. As adoption grew, the team scaled quickly:
- Designers: 2 → 5
- Development teams: 4 → 10
- Locations: Richmond and McLean, Virginia, Wilmington, Delaware, and San Francisco, California
Across multiple teams and time zones, I helped keep the experience cohesive by:
- ensuring design consistency across flows and surfaces
- enabling reuse through shared components and patterns
- sharing platform guidance and decisions so teams could move faster without fragmenting the UX
Design-to-build handoff (spec + states)
To keep patterns consistent across account types and backend constraints, I produced detailed handoff specs covering states, validations, and recovery paths. These redlines helped engineering build confidently without fragmenting the experience, especially around transfer timing, pending status, and failure handling.
Branch/ATM Finder Redlines
Design-to-build redlines documenting layout, type scale, spacing,
and key states to support consistent implementation.
Damaged Card Greenlines (Accessibility notations)
TalkBack/screen reader annotations defining reading order, labels,
and spoken prompts to meet accessibility requirements.
Outcomes & Results
Product impact
By mid-2017, the Capital One Android app had earned strong Play Store reviews and received its first of several J.D. Power awards. The app contributed meaningfully to digital servicing growth by improving customer satisfaction and engagement.Mobile servicing became a meaningful contributor to broader digital revenue growth."
Scaling native capability
As impact scaled, the org model shifted. In 2019, the flagship mobile team federated and native design responsibilities moved to line-of-business designers who had primarily worked on web. That created a knowledge gap around native patterns and platform conventions.
To bridge that gap, I reworked and expanded the Android Design System Library to make native-first design easier to execute:
- consolidated edge cases and product-specific variations
- restructured the library for usability and faster onboarding
- strengthened guidance so designers could ship platform-appropriate patterns with confidence
When Friction Teaches Us Something
Goal: Reduce call volume by enabling in-app reporting of suspicious transactions.
What we saw: Reporting felt too easy before customers had enough context to verify the transaction, which increased false fraud reports.
Decision: We toggled the feature off and reverted to reporting by phone to protect customers and limit fraud exposure.
Learning: High-stakes actions need the right guardrails and context before “easy” becomes risky.
What it informed: If reintroduced, the flow would require verification cues, clearer transaction context, and a deliberate confirmation step.
Report a Problem flow.
Designed for speed—then rolled back when we learned “too easy” increased false fraud reports.
Retrospective
Capital One was formative for me. I grew craft, collaboration, leadership, and resilience while helping shift a major financial product from web-wrapped to fully native Android.
I joined early in the native journey and left after helping scale patterns across high-stakes servicing and money movement, supporting distributed teams, and strengthening shared foundations like reusable components and platform-consistent behaviors.
The biggest takeaway: complex, regulated experiences only feel “simple” when the system underneath is coherent. I learned to design for states, recovery, and trust, and to partner closely with engineering to make the details real.
Capital One gave me room to experiment and the support to get better.
Performance Feedback
“Kim is such a unique driving force in the work across XD I can't imagine our work without her. Her skill and craft as a designer is on it's own level, as well as her knowledge and expertise. On top of all that, Kim's not only willingness to share, but her skill at sharing and imparting her great skills and knowledge on others is amazing. She seems to always be seeking out ways to help others grow, and then exceeds even our own expectations of learning. Anytime I get to work with or learn from Kim is one of my most valued work experiences and I will always seek out ways to do more of it.”
~ Anonymous team member
