Mobile banking app redesign: case study

In the life cycle of a mobile product, sooner or later there comes a time when you need to radically upgrade. As time passes, changing business requirements and customer expectations place new demands on platform capabilities and development tools — this makes an update impossible to implement by “decoration”. In the world of mobile applications, software life cycle is 2–3 years as opposed to the 10–15 years in a conventional enterprise segment. For us at Redmadrobot, along with the Open Bank Digital Team, the time to radically upgrade the iOS app arrived at the end of last year.

From mobile first to mobile only

The mobile application of Open Bank appeared in the AppStore in the autumn of 2014, when users had iPhones 4 and 5 with iOS 7 and 8 on board. At first, the functionality demands were simple — transfer between accounts, payments, conversion, viewing statements, information about deposits, and finding branches and ATMs. It was believed that for more complex operations, customers would turn to online banking or go to a bank branch. Now, two years later, the mobile app has become a full-fledged mobile banking channel for remote banking services, and users perform certain types of operations more often on mobile than on the Web. This especially includes cell phone bill payments, but also encompasses all payments in general.

Mobile users are more active — mobile visits to the bank are distributed throughout the working day rather evenly, whereas when it comes to mobile bankingб activity has a morning peak and then decreases.

In 2010, a well-known web designer, Luke Wroblewski, put forward the concept of developing “mobile first”. For that time it was a revolutionary idea — to first develop UX and UI for mobile devices, and then adapt the project for web and desktop applications. This, however, became old news fast, as there appeared a category of users whose only channel of communication was their smartphone, including communicating with their bank.

Conceiving the redesign, we set a goal: to create a platform on which we will build truly intelligent mobile banking in the future. To implement this concept, we started with a new communication block on the main screen and the “Profile”, which is the center of communication with the user. At the time being users could control their account settings and receive personalized offers from the bank via the “Profile” (in the future it will be completely personalized), and all the information will appear only in the proper context. Customers will also be able to change personal information in the “Profile” without going to a bank branch.

Agile, kaizen and kaykaku

The Open Bank application did not remain static in comparison with the first release. The functionality which we started with was constantly evolving. The business was setting new goals, new devices were coming out, operating systems were updated, and users developed a taste for mobile banking — in a year and a half we added thirty new functions to the application.

Alexander Nesterov, product owner, Open Digital

“Even at the design stage of our first application, we thought about how to make it as user-friendly as possible and therefore chose a path of continuous improvement. At first we went through long iterations, with the first major update, the possibility to open a deposit, happening a few months later. The bank was at that point operating by standard waterfall processes and did not know how to break up the large features and implement them in parts, but gradually we began to decrease the length of iterations — we moved to Agile and now release every two to three weeks. This greatly helps us find the right vector of development and thus insures against serious mistakes.”

In developing the application, we engaged in an intense interaction with the customer at all levels, from the server and security teams to product owners and top management . During the final two months of our involvement in the project, there were two development teams. One engaged in the development and support of the current application, and the other focused on the development of new functions (using the fulltime efforts of two iOS-developers, an analyst, a designer, and a project manager). A core team of team lead, design teams and project managers was busy in both directions at once. To keep within the scheduled release time, the task of each team member was laid out every day for two months in advance and constantly adjusted on the fly.

An example of Agile would be implementing the function of ordering cards through the app. In previous versions of the mobile bank, one could order a card at the login screen, but for most of the order the user was redirected to Safari. This function proved highly popular and we made this process completely within the app and are now planning to coordinate card delivery via chat.

This is kaizen, which represents the way of continuous small improvements. At some point, however, there comes the need to carry out a radical change of the system to reach a new level — in Japanese business terminology, this is called kaykaku. In our case, this moment came at the end of last year and was spurred on by two factors: businesses and users demanded a serious functionality expansion, which crowded the design, while the technical side deemed it necessary to “chop off their tails” by stopping supporting older iOS versions and going to Swift to create a platform for future development. Tasks at the start of the project were as follows.

On the business side:

• Personalization of service;
• Increased ease of use;
• Increase in transactional revenue;
• Building up a customer base;

On the technical side:

• Ceasing support of older iOS versions (only 9 or above);
• Transferring development from Objective C to Swift;
• Maximizing usability comfort via the platform tools (quick access to functions through a 3D Touch, Spotlight Search, etc.)

Timeline of the project, work organization, and usability testing

In November 2015, we began to discuss the logic of the new Open Bank application: we created our vision of product development, received the road map from the bank, and began the work of aligning them together. By January, we presented the design concept to the customer of what a mobile bank should be in the absence of resource constraints and limitations due to the integration with the customer’s systems. But then, of course, we had to prioritize.

In March, a native prototype was ready, and in early April, colleagues from the Usability Lab conducted usability testing and provided us with a report from which we made some adjustments. For example, the application has the function of “refill with other bank cards,” which was at first hidden in the “transfer between accounts and cards”, with “add another bank card” appearing in the bottom of a drop-down list. However, when users had a specific task, like wanting to fill their Open Bank card with another bank card, they did not find this feature, so we transferred it to another section.

We started development, which took 2.5 months, in mid-April.

Planning, design and usability

Leonid Borisov, art director at Redmadrobot

“Our task was to optimize user workflow for the majority of actions — to reduce the number of steps, to supply content more easily, and to start moving in the direction of a more personalized service.”

Payments

The greatest update was seen in the payment function on the main screen and the payments section — which are what bank customers use most often. Among the main changes:

• Templates of popular operations are displayed at the top of the home screen, and they can be created directly through the app
• Payment and money transfer services can now be done in a couple of taps
• A quick refill button appeared in the payment field
• Quick access to currency exchange
• Overhaul of directory services
• Quick transfer of funds via phone number to Open Bank customers

Expanding the prelogin zone possibilities

We redesigned the prelogin zone, with the unauthorized mode no longer functioning exclusively for Open Bank customers. Authorization is no longer necessary to view information about ATMs and offices, and the prelogin zone has an additional functional P2P network with transfers from one card to another (earlier, this function redirected the user to the Bank’s site on Safari).

Personalization and “smart banking”

• We thought of the new “Profile” section as a center of account management and communication
• Personal contextual offers from the bank in the “Profile” section
• A communications unit on the home screen with personalized suggestions for the user
• Contextual the Call-to-action buttons for all of the key products of the bank
• Personalization of banking products — for example, an Open Bank customer has a card with a design from “Game of Thrones”, this design will be on the main screen and on the page of the product itself as a stylized background image.

Paul Usachev, business analyst of Redmadrobot

“Personalized service was one of the main focuses of the redesign. In the context of personalizing banking products, our task was to learn how to display the required card data which was only relevant to its type, tariff plan and loyalty program. The work of gathering this data was done in conjunction with the Bank’s team by studying the backend specifications. This information allowed us to finalize the design layouts and describe the functional requirements and specifications for the application.”

As a result, we were able to implement a completely new concept of digital banking products which does not differ from the “off-line” user card. In addition to the visual design of the product, we enriched the amount of useful information at hand, making it unnecessary to search for the description of tariff conditions in large files. “

Development

The project in Swift

Egor Taflanidi, Redmadrobot architect

“The task of the architect is to implement the same solution from project to project, as such projects are easier to operate and easier to maintain. The case of Open Bank was no exception, with the code design and ideology of RESTful client-server communication remaining unchanged, the project required rewriting in a new programming language, which resulted in a renewal (often rewriting from scratch) of the old libraries written in Objective-C. In fact, the layer of data processing and communication with the server was completely re-assembled and reinterpreted. “

The mobile application is designed with an eye to the principles of SOA (service-oriented architecture), with the logic divided into the layers of Presentation / Business Logic / Persistency. Depending on the complexity of the scenarios and the amount of data, part of the user stories were written in the style of MVVM in conjunction with RxSwift and our own library for bindings . In terms of the scenarios applied, our “favorite” MVC used a lightweight (lighter) view of controllers and distinguished delegates, data source and other auxiliary facilities. We continue to carefully implement reactive programming and use it only for simple subscriptions and transforming data streams. This is due to the ease of supporting, debugging, and developing such a code.

Since this application is a mobile bank, we give priority to the observance of best practices and safety standards. The code is regularly checked by experts personally responsible for the security of the bank, known as static analyzers, who periodically conduct external audits and research. Open Bank has been found to have zero critical security vulnerabilities. At the time, the project served as a pioneer and a driver for the development of safety practices in Redmadrobot. Thanks to this, no project is complete without such basic things as SSL-pinning, protection from debugger connections, protection from launching on jailbroken devices, removing the caching of web requests, paying very careful attention to the data that is stored in the database, and much more.

We continue to actively use the practice of reusing code, which allows you to maintain a single architecture to reduce the development time of several projects as well as improve reliability. We have reused a single framework of business logic including the service layer, transport, and DAO and are now working on code generation parsers, compilers and database models. We use general developments in regards to colors and fonts, and the enumeration (enum) of Swift allows for full development in the use of styles. Extensions and custom UI elements are often reused in different projects.

Open Bank was predominantly written in Swift 2.2.1. Introduced two years ago at WWDC, the Swift language, though young by traditional standards, has already gone through several proprietary releases and has moved to open source. Despite the fact that the entire iOS ecosystem hasn’t adjusted to the new rails, it was not risky decision to port the development of a mobile bank to Swift. The main thing is that we saw that Swift could meet all safety requirements, which was the starting point. The initiative came from the developers. Slowly we began to use this language in the project for quite some time (we talked about this in the case of developing “AlfaStrakhovanie Mobile”). First one or two screens were began in Swift, leaving business logic to Objective-C, but then enthusiasts gathered within the company, who in a few weeks copied all of our template frameworks for iOS-applications to Swift, including a logic layer of server interaction.

This was not a “translation” from one language to another, but a “statement”, as if in school when the text must first be memorized and then written again. In terms of development methodology, in general there is not much of a difference regarding language to use. In the project Open Bank, the implementation of only a few units were not affected by the transition to a new programming language. For example, when you make a transfer in the application, there is a calculator in the “amount” field to calculate how much each person should, for example, pay for a restaurant bill- you can record the total amount and divide by three. Most likely, we would take this and simply integrate it into the new application. In general, today we have almost given up on Objective-C and write all new projects in a new language.

Anton Poderechin, iOS-developer Redmadrobot

“Swift is more like syntactic sugar, as it is nicer to write in, it is easier to format, and code is eventually readable. Of course, it is not perfect, with a weak debugger, refactoring that does not work, and IDE syntax highlighting which isn’t the best. By and large, when compared with Objective-C, Swift has in a sense even fewer opportunities (for example, there is no dynamic typing), so there is nothing you could do in Swift which would be impossible with ObjC. Of course, one the one hand static typing is a plus, but on the other hand can be a minus because the compiler always illuminates the error type mismatch and does not take liberties as before. The dynamism of Objective-C has sometimes helped us a lot — for example, parsing JSON was more convenient. You can not say, however, that this was such a horrible pain that made us want to return to Objective-C .”

It was clear that the release of the application would be held in the summer, and in September iOS 10 will be launched, so we were able to convince the bank to restrict support to only iOS 9 — it has a lot of things which are easier to use than in earlier versions, like working with animation tables, Stack View, WebKit, Layout Guides, Layout Anchors, Touch ID Reuse Duration, Contacts Framework, and so on. This decision was not made on a whim, but dictated by intelligence: iOS 8 or below is used by 13% of the users, and all devices that support iOS 8 can upgrade to iOS 9. The only exception is the iPhone 4 with iOS 7, but this customer base is very small (and can only use the previous version of mobile banking).

Data Caching

Gregory Matvievich , iOS team lead Redmadrobot

“We used to store all data only in the current session and did not keep anything in the database due to objections from the bank’s security team. To prepare for the redesign, we studied the problem, and concluded that all information not related to personal banking data would be stored in the database. Thanks to our architecture, caching took off at the flick of your fingers — we only had to write the data model for the database and translators. While we currently use Realm, we are not dependent on it, and we could move quickly to CoreData or any other technology if desired.”

Integration with banking systems

We are working with Open Bank’s mobile server team. All customer data, including their accounts and requests, is stored in numerous internal bank systems. We met with analysts of Open Bank to understand the opportunities, and helped the mobile server team to integrate this data in the model. Difficulties arose when data presented to us was a part of a single entity but stored in different systems. In each such case it was necessary to test and make a separate decision: either make several requests from the app or make a single request and combine the data on the server. “

Thus, the data on tariffs and loyalty are stored in very different places. Data regarding deposits, for example, is generally not present, but it can be calculated based on other data. We had to investigate all of this and relay it to both parts of the team in Redmadrobot and Open Bank.

Repeated operations, patterns and platform capabilities

In re-working the app, we found fast and easy payment in addition to repeat operations as the critical functions. We added repeat operations, templates and contextual buttons to different banking products.

To accomplish this, we actively used the capabilities of the platform (simple in terms of implementation, but pleasant for the user), adding 3D Touch and Spotlight Search; iOS 9 allows you to search not only by contacts and notes, but also by application objects, if they are published. Thus, even without going into the app, a person can find the right template via Spotlight and, by clicking on it, go directly on the screen of the corresponding payment in the mobile bank.

In implementing repeated operations in the backend, there were problems with defining the payment scheme, how it was conducted, and how it was filled out. Once these problems were resolved, repeat operations took off in addition to payment templates (which had similar problems). In order for everything to correctly work with the Spotlight search, counters that calculate the most common patterns were implemented in the backend. Some difficulties were encountered in defining those templates which could be carried out through quick payment (a modal window), and which could not, and how to calculate which fields the user could change in the template and show only these fields.

Payment scheme and instant commission calculation

There are dozens and even hundreds of different payment providers with many types of transfers, so making a unique screen for each of them would be impossible. After a while a specific protocol was invented in the app: payment schemes in which the server sends a set of fields required for payment. These fields can be limited to an input mask, a set of valid values, regular verification, dependence on other fields and others. In addition, each field has a type that defines the interface in the application. This protocol has been significantly modified to meet new requirements like the design of bank cards of other banks, the bank’s designating and correspondent accounts via the bank’s identification code, and the definition of a bank’s client by phone number. Another example is that the commission was only displayed by alert after the “Pay” button was pressed — at the time of payment, the user did not know the size of the commission. The protocol immediately shows the field from which the commission will be calculated, enabling it to be calculated on the fly.

Other improvements

While working on incorporating functional P2P-transactions, we collected a base of BINs to determine the bank based on the card number and show the user its coloring and logo. This database is not publicly available, and in fact we had to make it by hand.

We have begun work on updating the JSON of ATMs and offices, which made it possible to remove the duplicate displays on a map. Thanks to the online banking team! Our next plans include adding listings by subway stop, listings of where ATMs currently aren’t, and a button to file complaints regarding ATMs.

Chat

We installed a customer support chat in the new Open Bank application in order to relieve the call center and give people the same kind of communication channel which they are accustomed to in everyday life. Since the chat is only available in the authorized area of the application, the client doesn’t have to go through the identification procedure in the call center area — saying their passport data, code word, etc. This means the client can move straight to the point instead of wasting time in this area.

What we have in store

As usual, all of our cool ideas did not fit into the new release :) So what do we want to add?

• Tighter integration with the bank’s CRM-system — the work that we have done with personalized offers is only the first step.
• Discount programs, loyalty programs, and recommendations to friends.
• Further growth of payment functionality: for example, payment of traffic fines. It is difficult to make this functionality in a convenient way, as we must be able to look for a wide set of details, like the driver’s license number, phone number, and car brand. A search must take all of these nuances into account in order to process a ticket.
• Payment via mobile phones with automatic definition of service providers. For customers it would be convenient not to fill in too much information- in general, when we are asked to transfer money to another number, we do not always remember the service provider. However, the bank should definitely know the service provider in order to make the payment. There is a simple base of mobile operator codes, but after a mobile service law was enacted in Russia, the operator code of 4 million people could not be determined. This needs more integration with third-party services.
• Infographics of deposits and account status.

Other features in our plans include making transfers from other bank cards, paying utilities by barcode, paying for parking, and more. Siri Kit was introduced at the last WWDC, and Apple opened an API to communicate with its smart assistant. This provides great opportunities for new user scenarios.

Instead of a conclusion

Users whose devices are running iOS 9 and higher may download the updated application. For those who have iOS 8 and earlier versions, it is available in the latest version of the old design, in which we have maximized updates like renaming products, creating templates, and repaying loans early. The old application will continue to operate and be maintained, but development will cease.

This is how we made the new Open Bank. As not all of our great ideas fit in the application, this article did not include everything we would like to talk about the project. We have planned a few posts, like how we created the MVP and made the chat application. Stay tuned :)