Billing Overview

Billing is a feature in an eCommerce platform named PartnerView. Owned by DMSi, it’s our current CMS solution for our customers and is being overhauled and replaced. 

Ten years old now, the platform never performed as hoped. 

PartnerView is, sadly overwhelming with pain-points. As one example of its apparent failures, no matter where the user is in their journey, the browser’s back button logs users out of their session rather than returning them to the previous screen.

This study focuses on the Billing feature of PartnerView, its current pain points and issues, our team’s process, challenges, and our new solution.

Objective
  • Design a functional parody of PartnerView’s Invoicing and Billing feature
  • Design a flexible solution that accommodates multiple business billing and payment strategies
  • Improve overall experience
  • Decrease customer support inquiries
Team Structure
  • Product Owner
  • UX Designer (Skip to my UX artifacts)
  • UI Designer
  • BA
  • QA
  • Technology Manager
  • Technology BA
  • Technology QA
  • API Developer
  • Architects (3)
  • Middleware (1)
  • Digi Commerce – Front end & CMS Development
Methods & Tools
  • Mural Information gathering
  • Zoom User feedback session recordings, and all team correspondence
  • Dovetail Research repository and company insight sharing
  • Figma UI designs, prototypes, and annotations
  • Jira Project/task management
  • Goodnotes notes Task flows, and wireframes
Current design issues
  • An inverted payment decision hierarchy causes user confusion
  • Unclear how to apply account credits towards invoice payments
  • No post-submission validation or confirmation screen/messaging 
  • High customer support log volume

Current PartnerView Billing screen

Payment methods hierarchy is inverted. Users often expected payment methods to come further in the payment experience.

Aging Buckets interaction functionality was regularly misunderstood and underutilized.

The process to apply cash on account (CA) or credit memo (CM) records to a payment was a constant support case issue:

  1. Select a CA/CM record
  2. Select an invoice to pay
  3. Edit the amount to pay so it’s EXACTLY EQUAL to the CA/CM record amount.
  4. Click to pay
  5. Fill in payment information
What we did
  • UX/UI-specific responsive design
    • Desktop
    • Tablet – Portrait, landscape
    • Smartphone – Portrait
  • Broke the old single-screen solution into two tasks (2-3 screens depending on device)
    • Billing Screen:
      • Selecting and viewing invoices; taking in data
      • Paying on selected invoices; acting on data
      • Payment on an account; acting without data
    • Payment Screens:
      • Pay selected invoices
        • Pay the total or partial amount
        • Methods; Credit/Debit and ACH
        • Using account credits
        • Submit payment
      • Form & Payment validation
      • Pay on an account
        • Enter an amount to pay
        • Methods; Credit/Debit and ACH
        • Submit payment
        • Form & Payment validation
Process
  • PO collaboration for initial needs and dissecting the current solution
  • Interview billing users and understand their needs
  • Reference previously compiled competitor billing pattern examples
  • Task flows & wireframes exploration
  • Collaboration with PO on task flow and wireframe solutions
  • Collaboration with tech, architecture, API team
  • Low-fidelity testing
    • Stakeholders
    • Customers, Customers customer
  • UI development
  • Hi-fidelity testing
    • Stakeholders
    • Customers, Customers customer
  • Annotations
  • Hand-off to Digi Commerce for preliminary stories
Visual Results

Desktop

Tablet – Portrait & Landscape

Smartphone – Portrait only

Our challenges
  • Accommodate the nuanced needs of small- to large-sized businesses
  • Display enormous amounts of data on small screens
  • Technical limitations communicating with Agility ERP
  • Limited design process time
  • Customer availability for feedback
Overcoming challenges
  • Rely on everyone
  • Study our end-users thoroughly
  • Interviewed internal accountants for an accountants perspective
My UX artifacts