Bill and Payment History
Project Type
WIP
Team
3 UX Designers
2 Leads
Tools
Figma
Duration
4 months
Overview| Ideation| Prototype
OVERVIEW
Clarity in Every Transaction: A Smarter Take on Payment History
Problem: Where did my payment go?
Customers using the mobile app had limited visibility into their billing and payment history:
• Limited view: The “Recent Activity” screen only displayed payments from bank accounts or credit cards.
• Missing statuses: Key states such as failed, canceled, or pending were not visible.
• Unclear outcomes: Customers could only see “scheduled” or “completed,” which led to uncertainty.
• Increased support calls: Users had to contact customer service to confirm payment status.
• User frustration: This lack of transparency eroded trust and created avoidable stress.
Solution: Clarity at a Glance
To restore trust and reduce unnecessary support calls, I redesigned the Bill & Payment History feature to prioritize transparency and ease of use:
• Expanded payment history: Users can view all transactions across payment methods in one place.
• Comprehensive statuses: Payments clearly show if they are scheduled, completed, pending, canceled, or failed.
• Organized timeline: A clean, chronological layout helps users quickly scan and compare past activity.
• Actionable detail: Each entry provides essential context without overwhelming the user.
• Confidence restored: Users can confirm payment outcomes instantly, without relying on customer support.
IDEATION
From Pain Points to Possibilities: Reimagining Payment History
We worked through multiple narratives with product and engineering to validate edge cases and prioritize user needs. A few key design decisions included:
• Cancel/Rebill visibility: At first, showing both canceled and re-billed versions of a bill seemed redundant. But through discussion, we realized customers may want to compare both to confirm corrections. We decided to visualize both statuses in the UI.
• Call-to-action for customer support: We considered adding a “Contact Customer Service” option but, since the company is moving toward self-service, decided to exclude it from V1. This decision balanced short-term product goals with long-term scalability.
• Entries to display: Research into common practices showed customers expect at least 24 months of history. We proposed surfacing two years’ worth of bills/payments by default, with load-on-scroll to balance usability and performance.
• Loading states: Product suggested preloading 15–20 items with progressive loading as users scrolled. While not a primary UX concern, we tracked this as part of the overall user experience refinement
HIGH FIDELITY PROTOTYPE
HIGH FIDELITY PROTOTYPE
On Showing UI Exploration vs. Just Final Screens
Based on the YouTube notes you shared, here’s the breakdown:
• Final screens first: Always show these at the top. Recruiters and stakeholders want to see the end result right away.
• UI exploration / iterations: Include this, but frame it around rationale — not just screenshots. For example:
• “We started by only showing the updated bill, but through narratives we realized users may need to see both canceled and re-billed versions. The UI evolved to reflect both.”
• “Initial designs included a support button, but we removed it after alignment with product’s self-service strategy.”
• Keep it lightweight: Show 1–2 iterations or side-by-side comparisons to illustrate thinking. Don’t flood with every Figma screen.
Basically → Final screens up front, rationale-driven exploration in the middle, next steps at the end.