Cinch Financial
↖︎ back to the project
2018: started mid-July, launched mid-August
.png)
Potential was the word a couple of our users used to describe the Spending dashboard. The building blocks were there, we just needed to add to it. From our research, we found a few problem areas and potential solutions for them.
We knew we wanted to add filtering and searching but what did that mean for implementation?
We needed to make small changes to the design to implement a complete list of transactions.
After a few iterations and design reviews with the team, we came up with a solution that worked. For a comprehensive transaction list, we included all transactions—in and out—with colored annotations to distinguish them. Blue was income, purple was bills, and no annotation was Pocket Money. If a transaction was ignored, we changed the opacity of the text and numbers in the cell to 60%. The transaction totals would contain a + if they were inflows.
For the search, sort, and filter functionalities, we decided to do two bars—one with search and one with sort and filter—above the transactions. When the user interacted in any way (other than sort) with the transactions, the sum of the transactions appeared. We designed it this way to reduce the mental accounting on the user. If a user is interacting with the transactions list, they are actively looking for something or trying to figure something out that combined the different transaction types. That’s when a sum would come in useful. Otherwise, we kept the Spending dashboard as simple as possible to reduce the cognitive load by giving them one number—their “safe to spend” Pocket Money number.
Additionally, We opted to only sum up the amount of money in/out, and didn’t sum up the number of transactions, as it didn’t come up with users during research. The user could filter by account, and the type of account (credit card, deposit, savings, etc.) and last four digits would be listed under the name for easy recognition. We worked closely with the UI engineers to ensure that the interactions with these functionalities would make sense and be what the user expected.
We represented the inflows with a + in front of the number. We didn’t want to represent it in color because it's not the best differentiator regarding accessibility, and annotations were already different colors. The annotations to draw distinctions among the different types of transactions in the list were in text. By nature of textual design/description, each annotation type is different, therefore, using color as differentiator wouldn't hurt accessibility. We put annotations on inflows and bills. Most users already knew Spending dashboard to be where the Pocket Money transactions are, so we wouldn’t have annotations on those.
Search results appeared after typing and hitting enter/return. It was a better decision for both UX and performance. Otherwise, each new letter would've initiated a new database query, causing the transaction list to flicker and show different results.
The sum of transactions appeared above the list and under the functions. Money in sum appeared on the left, money out on the right.
We explored having multiple filters, but we decided that we would start with a single filter, account, for this release. If users wanted to see the specific transactions, they could navigate to the bills and income sections of Spending. We put additional details in grey, i.e., the type of account would be a descriptor on a second line and the number of filters applied in a circle.
Each project and feature I worked on either stemmed from or was influenced by from that user research session. I've broken each out into its own page to for readability.
