Spending Feature

Feature Summary

Duration

2018: started mid-July, launched mid-August

process

discover
define
develop
deliver

Level of Work

Spending Overview

"Potential"

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.

the old transaction list—just Pocket Money transactions and sorting functionality.

Problem Areas

  • Users felt that the transactions list didn’t give them the whole picture.
  • Users didn’t understand why they had to click around to see all the types of transactions (in flows, bills, pocket money, credit card payments, etc.), and it was requiring them to do extra thinking.
  • It was hard to interact with the transaction list in a way that was meaningful, as it was just a sortable list of Pocket Money transactions from the last month.

Potential solutions

  • Turn the Pocket Money transactions list on the Spending dashboard into a complete list of transactions.
  • Add search and filter by account functionalities in order to interact with transactions in meaningful ways. Users could already sort transactions, but they couldn’t do much else.

Ideate

We knew we wanted to add filtering and searching but what did that mean for implementation?

some hand drawn sketches

A meaningful transaction list

We needed to make small changes to the design to implement a complete list of transactions.

  • A way to differentiate in the number which is money in and which is money out
  • Distinctions among the different types of transactions in the list
  • A sum of the transactions upon user interaction through search, sort, or filter. Because the list no longer was just outflows, we had to show both figures—the sum of money in and the sum of money out.

Interacting with that transactions list

the dynamics of searching our transactions

  • Search results were based on the description in the transaction cell itself.
  • We were mobile first and pretty much only, so we only had so much screen real estate to use for these functions. I played around with trying to fit it all on one bar, only using icons, hiding until point of need, and other ideas. I made a pros and cons list for the different options.
Examples in the slides
Photo 1
  • pros: clean, all on one bar and in one drop down
  • cons: can only see one filter at a time, accounts list could be very long
Photo 2
  • pros: much cleaner look
  • cons: users wouldn’t be able to sort/filter through their searches
Photo 3
  • pros: having two bars did give some breathing room for the rest of the components
  • cons: it would break with the rest of our style, as searchable things were never in grey—only white
Photo 4
  • once I nailed down the requirements and behaviors, I zeroed in on the visual display of the functionalities
  • these are just explorations

Filtering and Sorting

  • For filtering, we went back and forth between being able to filter by multiple categories at a time. I included account (by card) and by transaction type (Pocket Money, income, bills). I mocked up examples of both, and we ultimately decided that for this release, we would only have one filter type to start—filter by account. If users wanted to see the specific transactions, they could navigate to the bills and income sections of Spending.
  • It was also tricky to find a representation of what is filtered and the number of filters applied. I had to make sure that we could filter by more than one account at a time, and that the accounts in the drop down were legible and distinguishable.
  • Sorting stayed the same.

the dynamics of filtering/sorting our transactions

  • For filtering, we went back and forth between being able to filter by multiple categories at a time. I included account (by card) and by transaction type (Pocket Money, income, bills). I mocked up examples of both.
  • It was also tricky to find a representation of what is filtered and the number of filters applied. I had to make sure that we could filter by more than one account at a time, and that the accounts in the drop down were legible and distinguishable.
  • Sorting stayed the same.
Examples in the slides
Photo 1 and 2
  • pros: multiple filter categories
  • cons: only one filter per category, was also very tight and small
Photo 3
  • Still too tight, and our standard was to use checkboxes when picking multiple items
Photo 4
  • Pros: multiple filters could be applied per category at a time. We ultimately decided to only have one category—accounts
  • Cons: the transaction type took up more screen space
Photo 5
  • Pros: multiple filters could be applied per category at a time. We ultimately decided to only have one category—accounts
  • Cons: the two columns looked confusing and unnatural

Solution: a Better Way to Understand Your 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.

Transaction list

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.

Searching

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.

Filtering

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.

Individual Projects and Features

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.