Citi Balance Transfer Module Case Study
Redesign the balancetransfer module
My role | 2012
- UX design
- Prototypes
Team
- Kurt Pennypacker, Design
- Adrienne Birney, Business Analyst
- Adam Zeiner, Design
- Erin Poole, Content Strategy
The Balance Transfer redesign was part of the larger Fusion project. Fusion was a complete front-end overall for a white label credit card servicing platform. Our solution is a responsive single-page web application with a modular design system. The new system would be fast and functional and provide users with a linear experience no matter which device they are using. Our accessibility team helped ensure that each component and module and the app itself were accessible. Modular components and modules maintain design consistency and provide the user with recognizable UI patterns throughout the app. On this project, I worked on:
- Creating Prototypes
- Wireframes
THE PROBLEM
Customers have difficulty completing online balance transfers resulting in too many costly help center calls.
USER RESEARCH
We surveyed people about their credit card use to create a credit card customer journey map.
The journey contains a series of subprocesses:
- Marketing
- Pre-activation
- Customer service website
- Customer service call center
- Payments
- Collections
- Quality / Operations
- Retention
The Fusion project would touch each subprocess (except for the call center), and in each area, the Fusion-based product would make meaningful improvements.
THE OPPORTUNITY (for Balance Transfers)
The Fusion modular design system provided us with components that we could re-use to keep each look and feel and functionality consistent. I re-used buttons and navigation components for the Balance Transfer Module, but I also designed new components to complete the design.
The challenge of redesigning the balance transfer module was to make the experience usable while still conforming to the requirements of the existing back-end system that would support the feature. The new module would need:
- An add payee step that would trigger validation on the back-end
- A remove payee option
- Terms and conditions
- A risk call
- Change offer flow
- Confirmation
Exploration and Iteration
I sketched out the initial flow on a whiteboard.
I sketched out the initial design for the balance transfer module based on the required flow and using existing modular components where they made sense.
We taped up wireframes on the board alongside the flow and marked them to explore the edge cases. Some of the edge cases we discovered:
- How do you edit a previously entered transfer?
- Do we show a link without a promotional tie to it?
- Do only promotional offers go to Promo Balance Page?
Whiteboarding helped us develop a consensus about our direction. It also helped us define questions we had for the client concerning their business and technology capabilities.
Technical discovery
In a waterfall process, the technical discovery comes before design. Using agile, we ideate and use the questions that those initial ideas raise to gather more information from the technical constraints (the back-end system).
While whiteboarding, we decided that a big goal was to reduce the number of required fields; the client agreed that some of the existing text inputs were unnecessary. Still, it was not easy to figure out which inputs were obligatory. Some of our questions:
- All of the text inputs are required and generate error messages on submission. Does the system need all of them to validate a creditor name?
- Account type is required. Is it required to validate the creditor, or can it be removed?
- Does the database have address information for all significant creditors? If the system validates an account at a noteworthy creditor in the database, can we supply the address information as a radio button and hide/suppress the address fields?
User Flow
We optimized the happy path (above) by building three main screens: entering creditor information, verify (and add more), and submit.
The change offer flow (above) allows users to change their offer without losing their progress.
Sample Wireframes
I added a "Before you Begin" screen (shown above) to remind users to be sure they had the documents they needed before they started.
We added an autocomplete search box (above) to help users populate creditor fields with the information acceptable to the back-end system on the first try.
I created 36 pages of detailed wireframes to design and document the appearance and behavior of the balance transfer module. I also maintained and updated the entire 1,200-page specification document [PDF] that includes the balance transfer module.
Prototypes
In addition to working on the balance transfer module, I collaborated closely with our developers and other designers to refine the design of an accordion component by building a prototype.
I started with Axure, but as the complexity of the component grew, it was easier to edit the JavaScript that Axure had created manually.
I created a landing page prototype for the Diamond Preferred card (above) to demonstrate sticky headers.
Hi-fidelity designs
Adam Zeiner took my wireframes and created the final mockups shown above.
OUTCOME
Results and what I learned:
- Our team delivered a responsive white label solution customized for multiple retail partners.
- The acquisition portion of the Fusion project resulted in a 30% increase in application completions.
- The improvements to the servicing component lead to increased card usage as well.
- I learned how to adapt to changing requirements.
- I learned attention to detail and developed my problem-solving and analytical skills.
Wireframes:
White Label Experience Specification: Wireframes [PDF]
Best Buy Appendix: Wireframes [PDF]
Sears Appendix: Wireframes [PDF]
Brooks Brothers Appendix: Wireframes [PDF]
Prototypes:
Accordion Prototype: HTML / JavaScript
Diamond Preferred Prototype: Axure
Live Web app: Best Buy Credit Card Sign on.
#ui #interaction #web_app #accessibility