Reviving mobile business finances — redesign of ING Business App
By: Daniel C. Dul
Tags: Mobile App Design, Design Patterns, Design, UX, Interaction Design

Getting the right design before designing it right — initial research

Back in 2017 along with a 3rd party research company ING conducted roughly 200 CATI (Computer Assisted Telephone Interviews), a number of focus group studies and in-depth interviews in order to better understand our customers’ attitudes toward mobile banking. These, supported by insights from our NPS (Net Promoter Score), taught us that:

a number of big business CEOs and smaller businesses’ owners did not use browser versions of electronic banking systems — one of the main reasons for that was that they had specialists hired for performing operational tasks. What was important for them though was easy authorization and general overview over their companies finances on mobile.

one of the main reasons for that was that they had specialists hired for performing operational tasks. What was important for them though was and on mobile. users called for a broader set of features available to them on the mobile app such as currency exchange, bank cards management, more transfer types, notifications, applications authorization, mobile payments, etc.

available to them on the mobile app such as currency exchange, bank cards management, more transfer types, notifications, applications authorization, mobile payments, etc. our app delivered suboptimal user experience due to its unintuitive design and unstable operation

As a next step, we reviewed a then-current banking apps landscape. Partnering with another UX research company we reviewed 45 banks’ apps from 18 countries (with a major focus on our polish competitors). This gave us a general overview of the mobile apps, their features and design styles. It left us with an impression that even though they had various interesting features most of these apps felt outdated and rusty, and were not providing great user experience. There we spot a chance to gain a competitive advantage by doing better than that.

What to do then? — the objectives

Having these insights coupled with general business requirements we defined the following objectives for this project:

creating a solid foundation for app’s new features development at a reasonable costs and time-to-market of new functionalities making the app more enjoyable, modern and usable delivering great UX for our users

For the app to reach these objectives it was necessary to design it anew as we couldn’t see our 2015 app to still be up to the mark in 2020 and going forward. Apart from its look and feel, it was the technology that wouldn’t effectively support the app expansion plans. We therefore selected Flutter as an underlying technology — UI toolkit using a single codebase to compile native codes for both iOS and Android platforms. Did I mention we were the first bank in Poland to design an app using Flutter by Google?

For whom are we doing it? — personas

Knowing what we wanted to do, it was crucial to remember who we were doing it for.

There are two main personas whom ING Business (the full-fledged desktop version of the system — ingbusiness.pl) serves and supports in their daily jobs: accountant and authorizer.

Accountant is a person who prepares all the application forms and transfers for their superior — authorizer — to sign (and send). Since ING Business serves numerous medium and large enterprises it is important to emphasize our clients tend to send dozens, hundreds or even thousands of transfers each day, which makes these two personas very distinct.

Considering the sheer size of a typical mobile device and the type of jobs-to-be-done by an accountant — filling forms to prepare transfers and various applications — both much easier to be done on desktop, it was evident that what we should focus on in the mobile app was authorizer’s tasks.

What does the authorizer (key persona) do? — user tasks

Therefore as stated above the app was mostly meant for effective support of authorizer’s tasks which are as follows:

searching (for accounts, transactions, orders, beneficiaries, etc.)

(for accounts, transactions, orders, beneficiaries, etc.) browsing (through a number of accounts, transactions, orders…)

(through a number of accounts, transactions, orders…) viewing (detailed information about accounts, transactions…)

(detailed information about accounts, transactions…) authorizing transfers, and

transfers, and exchanging currencies.

Who’s gonna be involved — the team

I coordinated the design part of the new app development process since the beginning of the process in late 2018 up until May 2020 when it was launched. I collaborated with two other experienced designers, Szymon Pepliński (UX/UI) and Magda Wilk (UX), and the product owner, Przemek Klimek, who displayed a lot of UX-oriented sensitivity and acumen.

Most of the conceptual work has been done by me and Przemek with a great input of other stakeholders and Magda who never failed to provide us with crucial design ideas and support in structuring vast business logic needed to be accounted for in our design decisions.

Following the conceptual work it was my responsibility to translate it into detailed interaction designs, mid- and high-fidelity wireframes in Sketch, preceded by competitive analysis and validated through user testing.

Szymon on the other hand created the detailed visual style of the app and provided invaluable insights during the process of finding the best design patterns for any given design problem we faced.

In addition, there were other colleagues intermittently involved in the process in consecutive design stages — analysts, developers, product owners, other UX designers and CX professionals.

THE PROCESS

Way of working — organization & workflow

We first divided our app into separate ‘themes’ such as accounts, history, orders, transfers, navigation, filters, types of animations or icons, etc. A given theme would typically take between two–four such design sessions and was followed by my individual work on prototypes and when validated with users, individual work of Szymon to deliver pixel perfect screens in Sketch. These were subsequently shared through Zeplin, reviewed with product owner, and eventually provided to our developers.

Typical deliverables of our weekly design sessions would be sketches with the logic behind concepts they depicted, along with a broader consideration of the context given theme was related to e.g. if we place selected controls on the orders list would that also fit well on the transactions list? Should it even be replicated there? Why so, or why not? Is there any better pattern we could use?

Discussions on the topics like these have been a large part of any choice we made about our design and each and every one of them has been considered in terms of its internal (across the app) as well as external (related to our customers’ previous knowledge, experience from web version of ING Business, market standards, etc.) consistency.

First session of each theme would involve making sure everyone understands business requirements and typical use cases related to the given theme, e.g.:

- buying 20 000 EUR at the currency exchange module, or

- authorizing a transfer that is already two days late on the orders list.

Having this fundamental understanding of the topic at hand we would brainstorm and sketch our ideas on a piece of whiteboard or paper. Usually these would feed subsequent rounds of conceptual discussions followed by internal and external consistency considerations before we were confident they were worth proceeding with to another stage of the process.