Payment and Account History
Aligning stakeholder requirements with user centered design
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
Defining 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:
- Is adaptable not only to Yardi and AIM backend ledgers, but future partners.
- Performs well at mobile sizes without horizontal scrolling or omitting information.
- Is aesthetically pleasing and on-brand.
- My first solution is usually the simpliest one. I attempted to put the tables on separate pages in nested navigation. However the detail in the Account History still won't fit without horizontal scrolling.
- How would this scale to other integrations that include more categories? It already doesn't work.
- Later iterations included tabbed navigation and with increased rows to move away from a web page feel
- Additional information such as description can be displayed on a pop over drawer that appears from the bottom after a user taps on a particular row
- More data can be added inside the pop over UI for other integrations or other info categories in the future
Later prototypes: Payment History
- Taking inspiration from credit card apps and how they display payment history, I went with a stacked row UI that uses icons to show different payment methods. Now users can see status included with their payment info.
- Additional information can still be included in the pop over UI to scale this feature.
Later prototypes: Account History
Sometimes the ideal doesn't work
- Icons can be used to represent detailed categories. This works fine with Yardi integration, but AIM has 64+ categories of things with long names that cannot be easily visually represented or understood. Ex. (Loss of lease in force)
- What happens if we integrate with other systems that have 1000+ categories?
- The solution was to simplify the categories to 2 options: Payment and Credit. Additional detail can be contained in the pop over UI.
Live screenshots from latest build
- Payment history now clearly shows Charges, Payments, Returns, Voids, and as well as all specific payment methods
- During user testing, comprehension of payment and charge types increased from 3-7 on a 10 point scale. 1 - low 10 - high
- The concept of Charge and Credit confused internal teams as well as users. To simplify this, I changed the term "Credit" to "Payment"
- A small minus sign was added to Payments in the ledger to show the changes to a Resident's balance. Similar to banking apps such as Chase. This alleviated confusion surrounding Credit and Charges.
- UI can adapt to any backend integration, including AIM, Resman, and more.
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.