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.

• 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.

Iterations

Early prototypes:

• 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

• 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.

Implemented solution

• 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.

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.