Payment and Account History

Aligning stakeholder requirements with user centered design
Timeline
May 2021
My Role
Research, Design
Tools
Figma, Maze

Project Overview

Currently deployed in prod as of June 2021

Domuso is a late stage Fintech startup in the property management sector. Their resident facing mobile app here allows a Resident to pay rent, submit a service request, as well as view their payment and account history. Domuso has partnerships with several big players in the industry such as Yardi and AIM, and incorporates their backend which stores a user's account history. Recently it had become possible to display Account history on the webapp. My task was to adapt this to the mobile app as well.

The Problem: Display Account History in a mobile friendly way which scales with any partner backend integration
Project Index
Background
Defining product requirements
Iterations
Implemented solution

Background

Domuso has backend integrations which several large players such as Yardi and AIM. Until recently it was only possible to display total charges without any breakdown. Here is an example with AIM:

Web version

  • There are 2 categories: Payment and Charge
  • The description gives details. For example, Parking, Pet fees, Trash pickup, etc.
  • Activity is the amount of Payment or Charge.
  • Balance is total balance or credit for the Resident.
"I don't understand the breakdown of my account charges" - Resident
"Can't you just use a proper description and word it logically?!?" - Resident

Old mobile version

Defining product requirements

Product requirements

It's never wise to just jump into UI without first defining the product requirements. I needed to confirm several details before proceeding.

I needed to design a mobile interface that:

Iterations

Early prototypes:
Later prototypes: Payment History
Later prototypes: Account History
Sometimes the ideal doesn't work

Implemented solution

Live screenshots from latest build
Takeaways

Sometimes the ideal solution isn't a realistic one. Companies don't always control all the inputs into their product. The ideal solution here would have been to have a collection of beautiful icons to represent all possible Charges on a user's account. However this method would have likely caused issues in the future, and major headaches for QA and everyone involved.

We must not only keep the present solutions in mind, but how this will affect the future.

Back to top
Joel Lipton 2020