Numbrs Transaction details
2019 — Numbrs AG

Banking apps tend to be uninspiring. Nowhere is that more apparent than in their presentation of transaction data. Transaction details are usually a dry collection of technical data—often full of banking jargon and elusive abbreviations.

At Numbrs, our goal is to make banking more approachable and more insightful. In search for impactful ideas, I initiated a project to transform our original transaction details into a more meaningful and modular feature.

Due to my NDA, I can only share selected details of the project—no research, strategy or business background.

A departure from the norm

The original transaction details screen was limited to the essential data we received from the banks, such as counterparty, amount and subject (or reference in the UK). Very similar to your run-of-the-mill banking app.

At the same time, we saw that people were less interested in these descriptive details and more in seeing the bigger picture.

Context is king

Recognising a transaction is difficult—especially weeks or months after it happened. Banks use abbreviations and ambiguous conventions that are not human readable. With our data science team—hat tip to Antonio and Bartosz—, we identified that there’s a lot of partial information here and there that can be used to determine the type of a transaction (eg. card payment, direct debit, etc.) and to provide other meaningful metadata.

Apart from clarifying the data, I found that one of the most useful ways to make transaction data more understandable is to focus on habits and series rather than single purchases. This makes it easier for our users to grasp their own spending and saving patterns. Instead of looking at a single purchase at, for example, Tesco, you will see your full purchase history, your average spending, how many times you shop there, etc.

The new designs organises all information on a single screen:

Modular design

My goals to guide the design process were:

• Contextual enrichment
  Not all transactions can be treated the same way. You need a different context for a payment at a merchant (eg. am I spending too much at Joe & The Juice?) than for a cash withdrawal (eg. where was it, what fee was I charged?)
• Gradual enhancement
  It’s always tough to squeeze bigger improvements in our product roadmap but we tend to have time for filler projects. The new transaction details should therefore allow for independent modules to be gradually rolled-out, constantly improving our users’ experience.
• System agnosticism
  Payment systems are different in Germany and in the UK. Fiat and crypto currencies also have their own peculiarities. I needed a system that caters for all these variations and can be extended as we grow to new markets.

Some examples for the transaction description variations:

Apart from systematic differences, I also designed for the various usage patterns we saw analysing behavioural data:

Classifier suggestions

To properly organise and analyse income and spending, transactions need to be sorted in the right categories first. Even though our algorithms will try to classify each transaction automatically, in some cases we rely on the user to manually pick a category.

Realising that the classifier will mostly have some bets—matches with lower weights—, I created a concept to show these matches as suggestions. After validating the idea, I redesigned the category picker adding suggested categories. The project made manual categorisation a lot faster, users selecting from the suggestions even more often than we have anticipated.