6 things I learned from designing a mobile wallet

Viktorija Bachvarova
Netcetera Tech Blog
5 min readDec 18, 2018

--

1. You are not designing for the bank, but for the end users of the wallet

When it comes to designing mobile wallets, significant number of stakeholders are included in the decision making process. Therefore, due to many opinions, preferences and business goals being involved, it might get difficult in time to decide what is best for the user since the focus becomes slightly adjusted with every design decision being made.

Designing mobile wallets requires strong user centered approach.

For example, the bank may argue that they would like to see the card taking up to 100% width of the UI. This doesn’t necessarily help the user in every situation.

While paying at the store, just the sufficient card size might help the user to easily recognise which card he is using for payment and therefore do the payment process quickly as the situation implies.

In the middle we see example of a payment card, that can be activated for payment, in rather big size which isn’t necessarily needed in this flow of card activation.

That is why a good recommendation is to always test ideas for the sake of avoiding assumptions in UX decision making.

It is the perfect situation where many people might have input for, which doesn’t necessarily mean that is the right concept for the end user as well.

2. Mastercard has strict requirements on how you display their brand and in which size in the UI

In order your wallet to be accepted and go “live” first of all it needs to be validated against Mastercard’s brand requirements in digital payment UI’s. This document is not more then a list of requirements of how the brand of Mastercard must be presented in your UI. Most probably their brand will appear in the bank card, in the documents acceptance flow as standalone symbol, during card digitalisation etc.

Here are the main pain points of those requirements:

  • The size of the bank card which is exact replica of the physical card and is containing the Mastercard’s symbol must be no smaller then 15mm or as they specify 54 pixels (108 points)/15mm (0.59”);
  • The final display of the standalone symbol in the UI must be no smaller then 7mm in width.

How do you measure 15mm on a relative screen size? You don’t. Here is an online calculator that can help with that, especially for Android devices and dp’s.

Additionally, you need to display Mastercard’s brand mark when:

  • Activating an account;
  • Selecting credentials / account for payment;
  • Viewing account details (e.g. selecting a card to digitize, looking at transaction history etc…);
  • Completing the use of credentials /account in a transaction (payment screens).

Mastercard is changing these requirements over time, so it is always a good idea to double check if something’s changed.

3. Visualising card statuses

A recommendation is not to use greyed out style for visualising the different bank card statuses, e.g. activated, blocked or inactive card. Additionally, in order to clearly distinguish inactive and blocked state e.g., for which you might use transparency, a good recommendation would be not to rely only on the card artwork, but also use accompanying visual queues as text and iconography to reinforce the meaning of the card status itself.

Sample how we can additionally use iconography and text to reinforce the meaning of the card status.

4. You need to be aware how transactions are being handled in real life and clearly communicate that in the UI

In real life when you make a transaction of any kind, whether paying at the store or doing a money transfer, the assets are not instantly “gone” from your account and “settled” to the other side. That process can last up to 3 weeks. Therefore, in the UI, we need to indicate these states where the progress is ongoing since if we don’t provide this feedback to the user as a result of his action he would expect that there isn’t any additional ongoing process. Even though it might be more obvious for paying at the store at the terminal, when using wallet to split bills or send / receive money from friends, the expectations of immediate response from the ui are higher because of the nature of this type of transactions.

Indicating different progress statuses of the transactions.

5. You need a good design system that will help you be consistent

Creating a good design system in your design file is essential to keep up a neat workflow and ensure the file is flexible enough to easily apply branding or to globally change a text or a color style. With that kind of working flexibility you avoid the possibility of elements appearing differently on separate screens. In terms of Sketch, Figma, Adobe XD, that means constant work with symbols or components and text and layer styles applied to them.

In our solution we based the color and text styles system on Material design’s guidelines.

A sample of our base color system and the extension of colors we introduced.

6. You need to distinguish clearly what is brandable and what not

If your wallet is a potential product you need to distinguish from the start what is brandable and what not. That will help development to define everything that will act as a brandable component in the UI. Defining what is brandable and what not also gives you great insight whether your UI will work in different branding styles of multiple banks. Moreover, you will be able to set the theme of your wallet more easily and push towards that style by defining the constraints of the branding possibilities for the different banks and therefore keep a consistent experience of the wallet product no matter the bank brand.

Example of the top bar component and the constrains of branding.

More info about how we created our design system and organized the components and styles will be featured in a follow-up article. Thanks for reading! (:

--

--