How to UX/UI complex banking applications

Other languages: Russian

Hi. This article is the written version of my talk at the RAUX 2021 conference. There’s a link to the video below.

The original title of the talk had an element of hype in it: “Why boring people are better than anyone else at designing complex applications, such as banking apps.” However, to a greater extent, the story will be about how the team should be organized and in what sequence to do the work.

I make big apps for top Russian companies — mainly banks. I try to be more on the managerial side of things, but sometimes I design and program myself. I have been doing this for almost 10 years, during which I’ve made the following observations…

The process of UX/UI creation goes on for at least 3 months. Sometimes even 6–9 months. It is a very rare occurrence to finish a project with the same designer that you started with. People experience burnout throughout the process and can no longer do their job efficiently. At the same time, with smaller projects (1–2 months), everything goes much more smoothly.

This tendency isn’t exclusive to our team. Have a chat with some the people that work in the designer department of a large bank, and you’ll find that many of them have a huge turnover rate. Even top employees can change quite often.

However, some outstanding people who can withstand the entire 6 months, or even longer, do exist. All their massive amounts of talent and creativity aside, these people are very tolerant of boring and mundane tasks. Perhaps they even enjoy such tasks to a certain extent.

In this article, I will tell you what the UX/UI design of banking projects consists of and why it’s such a boring undertaking.

It will be useful knowledge for novice designers and for those who want to move on to the implementation of big projects.

For those who prefer to consume content in video form, here’s a recording from the conference (for now it’s only in Russian):

Contents

1. What clients value in the design
2. Stages of creating a design for a large project
3. How to help developers
4. Conclusion

It will become clear at the very end what boring people have to do with it all. But first things first:

How is the complexity of a project measured?

It’s arguable what can even be considered a complex project. Generally, it can almost always be reduced to the number of screens drawn.

For any landing page, 3–5 screens are enough. For an online store, it’s 10–20 screens. Banking applications for businesses go from 100 screens and up.

Moreover, the first 100 screens are simply fodder for the designer to warm up on. Throughout the process, they are redone and reworked many times, and in the end, the client receives 150–200 screens (not counting night mode themes and mobile versions).

If the client is a large bank that’s in the process of changing its design, then in 2–3 years, it will already have 1000+ screens when the design is distributed among different teams and departments of the bank.

What clients value in the design

Imagine that you are the bank — the client. You understand full well that the process doesn’t stop at you. After you, the design will go on to other departments and it will be used by people that you cannot control.

Thus, if problems appear in the future due to the design or if the app will be difficult to implement, you will be the one to take the fall.

All of the client’s main fears and hesitations are connected to this notion. If you want to land a project, it would be a good idea to show how you plan to cover these risks. For this, three main principles will come in handy:

1. Feasibility. The project must meet the requirements and constraints of the business department, development department, security department, and all other departments that are involved.
2. Usability. Users should have no problem using the app.
3. Scalability. The design should apply not only to the cases that you are working with right now but also to cases that you can only speculate about at the moment. In a sense, you need to try to look further into the future.

Further, I will try to show how exactly these principles can be applied.

Stages of creating a design for a large project

The plan below is almost identical to what I tell my clients so that they can imagine what the process will be moving forward. If you need to, feel free to take this video and arm yourself with the knowledge it contains.

Generally, the plan consists of four stages:

1. Setting the task
2. Design
3. Delivery of results
4. Support

In the video, I use figurines as props to show who is doing what. They are also used during a real-life presentation to the client.

The team consists of 10–13 people. In its entirety, this is:

1. Design director (that’s me). Responsible for the entire project as a whole. Works on planning, the initial task setting, and quality control of the work performed.
2. Project manager. Responsible for the interaction between team members and the interaction with the client. Monitors compliance with agreements and helps achieve them by any means possible.
3. UX researcher. Identifies the needs and pains of clients. Describes the client’s portrait and application usage scenarios. Conducts UX tests and provides commentary on the design.
4. Assistant UX Researcher. Assists the UX researcher. Makes records (including videos), drafts, notes, etc.
5. Front-end developer. Makes a clickable app prototype for use in UX testing.
6. Business analyst. Helps the team understand the client’s requirements. Checks the design for compliance with these requirements.
7. Accountant-consultant. Represents the main target audience for our application. Shares insights about his or her work with the team.
8. Senior designer. Draws the main, most critical scenarios.
9. Assistant senior designer. Draws everything that the senior designer doesn’t have time to.
10. Data designer. Ensures that the layouts and mock-ups have correct and consistent data.
11. Graphic designer. Draws the presentations based on the results of UX testing and the results of all the work performed.
12. Illustrator. Makes icons and other illustrations that are needed for the application.
13. Editor. Edits records based on the results of UX testing.

Stage #1. Setting the task

I’m going to say something that might terribly upset you if you are a designer.

Responsibility for a correctly set task should lie with the one performing the task.

For a client, this may be the first design project ever. How can they possibly know what needs to be done?

I’m going to presume that in such projects, the ones that are doing the work are much more competent and have more expertise in design than the client, regardless of whether it’s the client’s first project or not. Thus, the ones performing the work must set the actual task that will be performed.

Of course, the client needs to provide some kind of initial direction. But you shouldn’t expect that this will be the final and finished version of the task. You should be the one to set the final version.

So, the first stage of the process is to understand what the client wants. Clients usually express these desires themselves in the business requirements document, which is usually a 50–100 page manifesto that’s written in corporate-speak. That’s sure to be a delightful read.

There are 4 phases to setting a task:

1. Analysis of the requirements and the current application (if there is one)
2. Interviews with users
3. Sketching
4. User story mapping

The requirements are analyzed by the two main people working on the project: the design director and the project manager. If additional expertise is needed, the business analyst and accountant-consultant get involved.

The first task is to read all the documents that are provided by the client, communicate with the client, and understand how the client imagines the project, at least in the general sense.

A UX researcher starts doing the user interviews. He or she needs to find out why users love the existing application (so as not to lose that functionality in the future), and what problems they have with it.

At this stage, the team must also determine the main scenarios for using the application, identify its user groups, and as create user portraits.

At the conference, some people pointed out that the talk didn’t have enough examples. I say “compose portraits”, but I don’t show what they might look like.

We are now actively negotiating with clients so that they allow us to show these types of things. So far, most of the work is under NDAs. Therefore, there will be very few real-world examples.

But in essence, a portrait looks something like this:

Claudia Vivaldi. 50 years. Works as an accountant and has done so for nearly half her life. For the last 10 years, she has been the chief accountant at the Emperor’s Leg, LLC. The company supplies sandals wholesale to Mediterranean countries. Claudia works in 1C (it’s the most popular Russian accounting software) and logs in to the banking application several times a day to import documents from 1C, checks that they are filled out correctly, and sends them to her boss to sign.

Claudia has an assistant — the junior accountant Valentina Shpak. 30 years old. Aries. Valentina is responsible for paying out salaries. She visits the bank’s site several times a month to form salary registers and sends them to her boss to sign.

Claudia and Valentina use the bank’s site exclusively from their work computers.

Their boss is Adolf Ivanov. 40 years old. A busy and well-to-do person. He uses the bank application on the go and often while in a hurry. Usually, he does so from his phone. Once a day, he signs documents.

I hope this paints a clear picture.

Then the design director draws sketches. The design director specifically — not the designer. This is when we find out how the client actually imagines the project. Usually, most of the edits can be done at the sketching stage.

You can’t put too much effort into sketching. They are created solely for the purpose of being able to sit down with the client and quickly move them along the process. The sketches will probably need to be changed beyond recognition several times over.

It is much easier for people to think when they see pictures. Sketches are needed to think further, nothing more. By no means should this be considered the final results of your work.

Finally, the design director and UX researcher draw up user story maps based on the created sketches.

Example: Claudia imports documents from 1C. She opens the main screen and clicks the ‘import’ button. She selects the desired files. Suddenly she sees an error — one of the documents is filled out incorrectly. Claudia opens this document and corrects it directly in the banking app. And so on and so forth.

A sketch should be prepared for each step in this process.

There can be several various possible scenarios. Claudia may not run into errors in the process and everything goes smoothly. Or Claudia wants to set up automatic importing from 1C.

It is necessary to think over as many possible scenarios for how events can develop.

Let’s reinforce the knowledge:

Stage #2. Design

Only now can we get started on the meat of the work. It consists of 4 phases:

1. Design
2. Prototyping
3. UX research
4. Expert analysis

This cycle is repeated until all participants are completely exhausted or until the desired result is achieved. Our team usually goes through 4 cycles.

The design is done by the senior designer. More precisely, the senior designer starts the process, draws the main screens, and then the second designer picks up the work so that the first one doesn’t drown in it.

At the same time, the data designer makes sure that all TIN, IEC, ETC look similar to real ones, so that the texts don’t conflict with one another, and so that the data is correct from screen to screen and doesn’t result in unnecessary questions.

This is a nuance particular to banking applications. Most of the comments from the clients are not about the design as such, but about the data contained therein. Data design is performed to avoid having to do unnecessary edits to the project.

Well, that and it also helps to avoid confusing the users.

The prototype is made by the UX researcher and the front-end developer. In theory, you can do without a developer and make a clickable prototype with Figma or InVision. However, HTML works much better. Users perceive HTML as a real application and behave noticeably different than when they just see clickable images.

Naturally, UX testing is carried out by the UX researcher. An assistant helps the researcher do this. At this stage, usability tests give a good return. Here is my article about how we carried out one such test: UX-research of Remote Banking Services: our experience, mistakes, and discoveries

The usability of the application is determined at the stage of UX research. As I wrote above, this is very valuable to the client.

By the way, designers shouldn’t participate in the study at all, so that its results are as unbiased as possible.

Expert analysis should be performed by at least four different entities:

1. UX expert — discusses whether the app meets user expectations
2. Business analyst — checks whether the app meets the business requirements
3. Developer — technical requirements
4. Client — checks whether the app conforms to his or her own expectations

At the stage of expert analysis, the feasibility of the project is determined, which is also one of the most important parameters for the client.

We gather the comments for the designers and start the cycle over again.

Let’s reinforce the knowledge:

Stage #3. Delivery of results

Many designers (and even companies that are quite large) are already beginning to forget about this stage.

Just send the client a Figma link (and then let them figure it out). This approach equates to throwing the project in the bin — all that work for nothing.

To achieve the proper effect, you need to deliver:

1. UI Kit
2. UX Guide
3. Presentation

The necessity of a UI Kit and what it includes is generally well-known. Everything that can be clicked and everything that has different possible states must be put on separate slides. This is done by the senior designer.

However, the UX guide (or something akin to it) is something that very few people do. It is necessary to test the scalability of the project. This is created by the design director.

Example (only in text form for now — no pictures, sorry): You have a list of documents, such as statement. This list can be sorted, filtered, and some document data is visible in it.

But what happens if you need to display something besides statement? For example, requests for operations with foreign securities, which you have not drawn yet.

Will it be possible to use the same filtering and sorting principles? Will the data from the new document type fit into your current template? Is it possible and/or necessary to import/export/edit it according to the same scenarios as the statement?

In the UX Guide, you need to describe the rules that govern the addition of new elements to the application.

Finally, you need to present your work. This needs to be done with a separate presentation and during a separate meeting, where you describe which paths you took and why you made the decisions exactly the way you made them.

In the future, your design will go over to someone who hasn’t seen the process of its creation. These people also need to understand why everything is the way it is, and not some other way. If they don’t understand this, then they may simply refuse to accept your design as a basis, and instead will create something of their own.

Let’s reinforce the knowledge:

Stage #4. Support

To confidently guarantee a high-quality result, you need to provide:

1. Designer supervision
2. New UX research studies
3. Update of guides

During designer supervision, the designer takes a look at what the developers are doing and corrects them so that their work reflects the mockup.

For the next round of UX Research, check out the article 21 methods of performing UX research: choosing the right one. The ones on the right side of the chart are certain to come in handy.

It is also a good idea to give the client advance warning that your guides most likely won’t cover 100% of everything that is needed. Therefore, in half a year to a year, the guides will need to be adjusted and updated.

How to help developers

Four simple rules to make your design more palatable for developers:

1. Think up some cases for errors. Not just errors in the input fields — remember about errors in scenarios. Above, I have already given an example when Claudia ran into an error while she was importing documents.
2. Strictly follow the established variables. This mainly concerns colors. Designers like to say that they used 5–7 colors (because it looks nice in a Behance presentation) when the layout actually uses 20. For colors, use Opium.Fill (this is another link to one of my articles), which generally helps to establish mutual understanding between the designers and the client quite well.
3. Make sure the filling is correct. Above, I explained why you need a data designer. It is also important for developers that the data is consistent.
4. Show empty lists and empty pages.

Conclusion

Sometimes I tell people that what we are about to do will be the most difficult project of their lives. Usually, that’s exactly the way it turns out.

It is often the most difficult not only because it is so huge, but also because it is incredibly boring.

If you’ve read the entire article, you can already start to understand that the designer doesn’t get to do the most interesting work in the project. All the fun comes to an abrupt stop in the first couple of weeks when the basic design concept is ready. Then there come months filled with identical-looking pages — hundreds and hundreds of pages.

Good luck.

The article was written by Denis Elianovsky. Thanks to Stanislav Lushin and Tatiana Kitaeva for their help with transcribing the video, to Elena Efimova for the illustration in the header, and to Pavel Chernetsov for the English translation.