Making Card Payment Data User-Friendly
How we used magnets, paper wireframes, and role-playing, in order to weed through the complexity of card transaction data
Credits: Boa Min (Product Designer), Andric Tham (Product Manager), and Christina Wu (Research Assistant)
Hi community! I’m Boa (Heather), a Senior Product Designer at TenX. This is the first time that I’m posting on the TenX blog — excited to share what we’ve been working on so far. 👋🏻
Background
At TenX, we make a flagship debit card that lets you spend Bitcoin and Ether from your TenX Wallet balance.
Last December, when we were launching a new version of the TenX Card, we started testing out the product with a small closed group, and immediately ran into usability problems with how we displayed past transactions made with the card.
The most pressing problem? The poor choice of words we used to describe the status of card transactions.
These status labels were assigned by our engineers when the first version of the TenX Card was rolled out in 2017, and their meaning was lost to our users.
We were using terms like “Error” and “Confirmed” to refer to certain card transactions, which, in an effort to be transparent to our users, ended up confusing them.
Internally, “Error” meant that your card transaction was “reversed” by your bank or the merchant, and didn’t go through successfully. “Confirmed” meant that the payment was authorised by you, but not settled by the merchant.
Understanding the Problem
Debit and credit card transactions are complicated.
When you swipe your debit or credit card at a terminal of a store, your payment is considered “authorised”, but not “settled”. It normally takes more than a day before it’s considered “settled”, by which point you’re considered to have paid the store owner.
Most of the time, the amount that you “authorised” will be the same that is “settled”, but in some cases, the transaction amount can be resized (the amount changes) or reversed (the amount is refunded).
This is a simplified version of what’s happening in a “best case scenario”. There roughly three steps to this (acknowledging differences between credit and debit cards):
- Authorisation. The merchant obtains approval for payment, from your issuing bank (the bank that issued you your card).
- Authentication. The issuing bank verifies that your credit card is valid, that the payment isn’t fraudulent, and that funds are available.
- Clearing & Settlement. The merchant asks for the money owed to them from the card network (VISA or Mastercard).
This is a friendly infographic from WalletHub showing the “Clearing & Settlement” step, which takes place before money actually changes hands and you’re considered to have “paid” the merchant:
We studied how other payment apps dealt with this issue, and found that many apps only show transactions that a customer makes with the card if they had been settled by the merchant (which can take few working days).
And while that approach may make the information architecture simpler, it meant that a customer may not see what he/she spent with the card in real-time.
We wanted our users to be able to see the transactions they were making, in real-time. We understood this to be extremely important to our users, since we convert the cryptocurrency in their wallet balance into fiat currency (such as Bitcoin to Japanese Yen) at the point-of-sale, in real time.
As soon as the card was swiped at a terminal, if the information was available to us, we needed to update the transaction history in our app, as well as dispatch notifications to users who had them enabled.
This meant that we needed to solve the opaqueness of what was going on with these transactions and make the data comprehensible to folks who are not fluent in the jargon of the payments industry.
This is especially important for cases when card transactions got refunded back to the user (Uber does this if you link your card to their app for the first time), or if the amount changes (some gas stations do that, and so do hotels).
Researching the Problem
Before we jumped in to redesign the app’s interface, we wanted to clarify some of our uncertainties by understanding how our users thought about the problem.
Because the data involved in a card transaction is varied and dynamic (meaning, the status of a transaction changes as time passes), we couldn’t research the problem by just asking users in an interview or survey.
We originally thought of doing a Card Sorting exercise, but this didn’t quite capture the aspect of time, nor the situational aspect of it. We knew that our users would expect different information from the app depending on the scenario.
Eventually, we decided on a scenario-driven interactive exercise that blended elements of a user interview, card sort, and “Wizard of Oz” concept test.
For those of you unfamiliar with the “Wizard of Oz” method, it’s a prototyping activity that marshals the humble pen-and-paper, and ‘good old’ in-person human interaction, in order to “simulate” a software interface or system.
It uses real people and role-playing to simulate how one would interact with a given digital interface.
None of our team had facilitated a hybrid Wizard of Oz and card sort, so we needed to try it out to know if we could extract any useful insights from it.
The Pilot Study
The first thing we did was to run a pilot study with internal staff members.
This let us test out the rigour of our research methods, and iron out our moderator script so that we can get reliable data when testing with actual customers, instead of stumbling over our questions.
When designing the pilot study, I came up with idea of using magnetic labels. Using a generic label printer, along with a magnetic tape cartridge, we printed out labels on demand that we could stick on a magnetic board.
We also bought a few portable magnetic boards, cut them up, and pasted low-fidelity versions of our TenX Wallet app UI on them.
For the exercise, we had magnetic boards representing each transaction item, one representing our app home screen, and one representing a detailed transaction view.
Similar to a close card sort, the exercise lets our users define what elements of information they expected to see in the interface, in what order, and under a descriptor they thought made most sense to them.
We printed magnetic labels that represented a piece of transaction data (like date and time, transaction statuses, fee, amount, conversion rate, etc); and these magnetic labels can then be re-arranged during the exercise.
Users could build their ideal interface based on what they expected to see in any given scenario by picking up one of the labels, and putting it on one of the magnetic boards. If a label didn’t exist, we’d print one on the spot.
Initially, when running the pilot study, we thought that it would be a good idea to put a representation of the UI on a whiteboard.
This didn’t feel very natural, so we switched to laying out the materials on the table in the actual study, where participants felt more immersed in the scenarios we were role-playing.
Finalising the Research Method
In user interviews, we found that many of our cardholders would use the TenX Card when they’re traveling around the world.
So, for our Wizard of Oz test, we designed a role-playing script that took our research participants through an imaginary scenario traveling from Singapore to the Netherlands, and using the card to make purchases throughout their trip.
Throughout the imaginary story, we’d walk through these payment scenarios together with the participant:
- At the Singapore airport, buying a coffee. Use the card to purchase a coffee.
- Arriving at the Netherlands and renting a car to the hotel. Use the card at a gas station to fill up your car.
- Arriving at the hotel. Check your transaction history to see that the pre-booking deposit went through.
- Leaving the hotel. Checkout by closing the tab at the hotel reception, with your card.
- Leaving the Netherlands, and trying to hail a car. Add the card as a payment method to Uber.
- Arriving in Singapore. Review your transaction history to see all the transactions you’ve made while traveling. What changes or additional information would you expect to see?
Conducting the research with actual users
Once we finalised our research plan, we invited users who had previously used the TenX Card.
Since we were testing an experience that was later on in the user journey, scoping our participants to existing cardholders meant we’d work with users who already had a certain level of understanding regarding how our product works, and will have some opinion about what to expect.
During the sessions, our research assistant Christina helped to set the scene by playing a Starbucks barista, or by being the “wizard” behind the gas station machine, or the Uber app.
Within each of the specific scenarios, we got users to match transaction statuses (magnetic labels) to what they thought was happening. For instance, in the hotel example, we’d show a transaction that’s resized after the bill is closed, from the initial deposit amount.
Participants would show us how they expect the app to communicate this to them.
Besides the app’s transaction history, we also walked through how they expected this transaction to show up as a push notification.
Using this approach, we were able to draw certain conclusions from understanding how our users thought about each scenario, which helped us design a clean, intuitive, and structured interface for presenting card spending data.
Redesigning the interface
Laying down our guiding principles
Once we concluded our research study, we synthesised our findings to four guiding principles, which helped us redesign how card transactions were shown in the app.
Principle 1. All transactions shown in their history are considered to have “happened”, unless otherwise stated.
Indicating a transaction as “confirmed” prompts them to ask, could it ever be not confirmed? Users only expected to see a transaction tagged with a status, if it requires special attention (such as a refunded or declined transaction).
Principle 2. The status of a transaction should communicate its finality.
Finality is a key concept in cryptocurrency. Bitcoin transactions are said to be final if the transaction has seen a certain number of confirmations. In the fiat currency world, finality is less of a concern, but our users expect it to be communicated wherever we indicate the status of a transaction.
For instance, users expected to see an authorised transaction labelled “Completed” or “Paid”, and a pre-authorised transaction labelled “on hold”. Alternatives like “Confirmed”, “Settling”, “Verifying” didn’t communicate the concept of finality well enough.
Principle 3. Once a transaction has expired, it should no longer be visible.
This might sound counter-intuitive, and was one of our most surprising findings from the study. When walking through the scenarios, users weren’t interested in transactions that were expired, they were only interested in seeing transactions that happened (Principle 1), or are soon-to-happen (Principle 2).
Principle 4. When something unusual happens, provide timely assurance.
Credit cards are incredibly versatile, and merchants are allowed to use it in a myriad of ways that users might not be familiar with, especially when traveling abroad. There are many ways merchants can deduct money from your card, or to refund money back to you. For some of these transactions, it can be alarming if you saw it represented like a typical transaction.
When this happens, we should notify the user immediately, and provide assurance. e.g., “You don’t need to worry about this…” or “Something happened, and we’re on it”.
Making improvements to the interface
Remove invalid transactions from the transaction history
Through research, we’ve learned that showing full details can create more confusion for users.
For instance, this is what’s shown when the ride-hailing app Grab reserves a specific amount on your card before the ride, then adjusts it after your ride was completed:
In our redesigned interface, we decided to hide “invalid” transactions in their transaction history.
Transactions previously labelled “Error” or “Declined” transactions will not be shown in the new transaction list design.
Additionally, we omitted the status for completed transaction (which was “Confirmed” in an earlier iteration). Now, we’re only showing valid transactions in the list:
Reword labels to better communicate transaction status
The way we named our transaction statuses were confusing to users. Based on our card sorting findings, we updated them to be more intuitive:
- Pending→ On hold (next phase)
- Error→ Cancelled
- Receive→ Refunded
We also changed the transaction title to use the past tense (i.e., Sent, Received) instead of the present tense (i.e., Send, Receive).
Include additional context to help users understand unusual transactions
The VISA network provides an optional ‘Description’ section that merchants can furnish with any transaction.
Since this is not within our control, and can sometimes get quite technical and confuse users, we thought about removing the section, but we decided to keep it since the users still find the information useful. To help the user better understand this, we named this field “Message from merchant”.
To add further context, we also added separate ‘Info’ section, which communicates an additional layer of detail.
Remove transaction full list drawer from the home screen
Finally, we wanted to make the transaction list screen more flexible, so we could add enhancement features in the future, such as letting users sort, filter, and search their transaction history.
Additionally, we wanted to reduce the information density on the home screen, in order to reduce our user’s cognitive load.
In our redesign, we decided to remove the sliding drawer from the home screen that housed a full transaction history. This reduced the information density on the home screen. We moved the full view to a separate screen which also solved a related performance issue with long transaction histories.
A side-effect of this is how we’re able to simplify the app navigation, from both a technical and user experience perspective:
While there are upsides to using modal sheets such as our transaction drawer to maintain context, our users found the paradigm confusing.
Rolling out the redesign
In the spirit of getting this out as quickly to users as possible, we decided to implement changes to the transaction history in phases.
In our first phase, we revamped the navigation, wording, and layout, with the foundation laid for future enhancements such as notifications, sorting, filtering, and searching.
These updates are now live in the TenX Wallet app (iOS / Android).
If you’re a user of the TenX Wallet app, make sure to update your app to try it out.
To receive the update, open the drawer menu in the upper-left corner, and tap on the ‘Update available’ button on the bottom of the drawer, if it exists. The app will refresh for a second — that’s all the time it needs to update.
Try it, and let us know in the comments what you think!
If you have any further questions about TenX please…
- Join our community chat on Rocket.Chat
- Join the discussion on our Community Forum
- Subscribe to the TenX subreddit
- Follow TenX on Twitter
- Subscribe to us on Vimeo
- Follow TenX on Facebook
- Follow our blog on Medium
- Subscribe to our monthly newsletter
