The Problem + Audience
No UI existed for "Terms" (invoiced) customers to resolve inaccurate invoices. Changes could take weeks to rectify. Both the customers and the company were frustrated; the customers had no visibility into the process and the company was losing revenue. Often, account suspension was threatened in order to collect payment, lowering customer satisfaction scores.
The Payments Center solution–a self-service enterprise experience, designed as the model for all future payments projects.
Below is the final flow for the invoice change request project I designed.
The MVP called for one change per invoice based on this user criteria:
• A portal to manage and track payment information in one place.
• A self-service method to update an incorrect invoice.
• Transparency about where they are in the process.
User Interface Overview
The FORM page does the heavy-lifting in this experience. It communicates invoice details and is the customer catalyst to specify what is wrong with their invoice. The results from the combination of pull-down menus and input fields provided insights to the internal team, enabling them to expedite the customer's request, reducing churn, and improving turn around time.
The experience commences in Payments Center / Documents, and once an invoice is located by the user, a selection is made from the Actions menu (upper right corner) that delivers the appropriate form.
Evolution of the FORM page
1. The FLYOUT over the Documents page sets up the user to request their invoice changes. Status summary and associated documents can be view by choosing a tab.
2. The CARD pattern, the standard for Material and backbone of this experience, replaced the flyout and created containers for each data set: dispute, invoice, and status.
3. Invoice data moves to its own card. Continual combing through all thirteen flows "to prove" that this base flow, the type of pulldown menus, and verbiage was consistent across the platform-wide scope.
4. Material Design is applied. Lots of visual design negotiations regarding visual impact, alignment, and pattern.
When I joined the team the user experience was lengthy and confusing, lacking a consistent UI approach across the 13+ flows. I developed a framework that gave structure to page types and user activity, and reduced the flow from fourteen to four main pages: Documents, Form, Email, and Summary. Below are a few examples of project changes.
The Card Pattern
We tested this flow with customers who loved the ability to treat their invoice request as a simple, self-service task. They said this UI would eliminate a lot of time and hassle involved in searching for someone who could help them. We also learned that the "Actions" menu was not obvious, which we rectified during future iterations.
The Form and Card Pattern Continue to Evolve
The cascading menu was eventually eliminated and the content of this menu was pushed to the form page.
One card became two and then, three cards: the largest card continues to act as a net catching all the incorrect invoice details. The invoice summary moves off the main card onto its own. The stand-alone status summary (last image) adds a third card which holds the change request details such as, case number, date, and submitter.
This invoice change request flow became the self-service model for future Payments enterprise user experiences. The project came to fruition through tight team collaboration, which included UX, Content, Visual Design, PMs, and Engineers.