Usability design principles – UX in online credit processes
User experience (UX), which is what users experience when using a given system, is used in the process of building added value for our customers, i.e. usability, pleasure, ease of use, and having a specific flow that will make our product attractive and make good impressions on the customer. We use it, among others, in such processes as: modern electronic banking, bidding processes, after-sales events and any other in which the client performs certain activities in our environment. What principles should we follow when designing online processes for banks or other financial institutions? What does it mean to be based on the client’s requirements and listen to their voice? Do we really need it? We asked our expert on UX and an ardent supporter of translating customer requirements into the language of “implementers”, Magdalena Równicka – a project manager from the banking world, who has been successfully implementing projects based on, among others, quality research, designing agile methodologies and creating credit processes. Welcome.
Kuba: Magda – what do you think UX is or should look like in modern banking?
Magdalena Równicka: The UX principles, i.e. User Experience, and the customer experience, are similar both in banking and in any other field in which we create solutions. The most important thing is to put the client, or rather the user, in the center of our attention. By the user, I mean a person, and more often groups of people, who will use the application we are creating. In the case of banking, it is most often a bank customer or employee.
We must remember that we create solutions for users, and not for us. A committed, professional design team of enthusiasts wants to create the best solution. Its individual members are experts in their respective fields. They know the best practices which they want to implement in a given solution. Sometimes their ideas are contradictory. Sometimes it takes a lot of work and a significant budget to implement all of them. Sometimes they work well together and it seems that they have created an ideal. Sometimes we are looking for the best market solutions and want to copy them in our products. However, it often turns out that users are not thrilled. It happens when we omit the most important element – getting to know our users and their expectations.
As bankers, engineers and developers, we are not “standard” users. We know more, we have more experience and that’s good. But this knowledge and experience can be a burden. There are some things obvious to us, which the client does not know about, is not aware of, and we do not understand his/her perspective.
With this in mind, at the very beginning of the solutions’ designing process, we should start by determining who our client or user is and how she/he wants to use a given solution. This also explains why copying the best, appreciated solutions of the competition is not always a guarantee of success. Yes, it increases the chances of success, but it will only work if we are sure that our user or client is very similar in their expectations and habits to the client or user of the copied competition. In my experience this happens very rarely.
And what is the preparation for the implementation of an online solution for credit processes based on UX?
Magdalena Równicka: Preparations start long before the implementation itself and, in my opinion, they have two pillars. We start our work with the first pillar I mentioned a moment ago, that is, by specifying who will use the solution. It can be an internal user, a bank employee or a customer. Additionally, each of these groups is not homogeneous. For example, on the one hand, we have older clients with longer experience and habits that have been developing for many years. At the other end of this scale, there is a group of new, young customers, expecting modern solutions that they know from other applications. The main challenge at the beginning of work is to determine which clients or groups constitute our majority, which are our priority. We create their personas – we gain as much knowledge about them as possible, we try to understand their way of using solutions and their motivations, habits, experiences, and readiness for change.
The second pillar of a successful UX is for the actual solutions to be based on the knowledge of our personas and constant cooperation with the client in the process of their creation. This knowledge allows us to answer very practical questions – where is the button supposed to be, what the content of the message should sound like, whether to use icons, images, shapes in our message, and many more. We must contain our tendency to do “the best”. The best is what the client wants, what is easiest for him, and not what results from our best expert knowledge.
Are we done with UX after passing the requirements to the supplier? Or is it a continuous process based on market or product development?
Magdalena Równicka: Communication of requirements is just the beginning of the road. Less and less often, we start from creation of a detailed project and its gradual implementation in accordance with the assumptions used. We used to go in a straight line from point A – description of requirements, to point B – implementation. Along the way, we were surprised by changes and we dealt with them, but we treated them as “necessary evil” that must be managed.
Currently, the road from A to B more and more often resembles a winding ribbon of a gymnast, with many loops and twists but also the beauty of movement and new, surprising discoveries. We must give ourselves the right to make mistakes and constantly verify assumptions. This means that along the way we must often ask the client how she/he likes what we have already created, check whether she/he uses it as we assumed, whether she/he follows the path we planned for her/him and whether she/he achieves the goals that we assumed. Each piece of feedback is a benefit for us because it allows us to draw conclusions and go further without having to rebuild the entire solution.
Moreover, more and more often, when creating solutions, we assume that they will “live” as long as they are used. From the beginning of their design, we add the requirement that they can be easily modified.
How do we collect customer requirements?
Magdalena Równicka: This is one of the biggest challenges. This is a paradox because we cannot rely on customer feedback. This is due to several reasons. The first is that as users, we often don’t know what we want. We carry out many activities instinctively, without thinking why they suit us. It has to be good, easy, pleasant. But how? What does this mean in practice?
Secondly, we are prone to self-deception. We say, for example, “I am frugal,” but the history of our bill contradicts this. Another example: we declare “the price is important to me” and for some other reason we buy solutions that are more expensive than those of the competition. It cannot be denied that, when asked, we want to make a good impression and give answers that, in our opinion, put us in a better light as prudent, experienced, making rational and “good-sounding” decisions individuals.
In my experience, some of the best methods are all based on observations. There can be many sources of those. However, the group reflects historical data among which we are looking for knowledge about customer behaviour. How did they behave while using our solutions? Where did they go smoothly, where did they get stuck, what goals did they reach easily, where did they get lost? Another source of knowledge lies in testing prototypes with clients. We create a quasi-solution – a prototype resembling it and we check how the client deals with it.
On this basis, we create hypotheses, assumptions: how the solution should look and work? Sometimes one hypothesis definitely dominates and seems to be the most effective solution. Sometimes several are created and require quantitative confirmation of the weight and impact of each individual. Only then would I recommend relying on the results of quantitative research.
How to confront hard legal/product/risk requirements and, in result, 100 fields on one form with the vision of a customer who submits an application for PLN 10,000 on a mobile phone and has 10 minutes to go through it. Maybe the example is not taken from real life, but the question is, how is the voice of the customer to decide in the process of giving products?
Magdalena Równicka: This is a design rope dance, the kind with a long stick in your hands. On the one hand, we have a burden in the form of business goals, our expectations – after all, each solution must earn profits. On the other hand, there are the aforementioned legal requirements. The banking market is heavily regulated. Many solutions must contain numerous required contents, messages and methods of action. Customers don’t always expect this. For example, if in a process we are required to provide all the requirements resulting from the GDPR, then later we see that customers spend the least time reading them, skipping quickly, marking “I have read”.
Often, customers do not know that the solutions are aimed at their well-being and safety. A perfect example of this category is masked passwords when logging into banking. For the client, it is difficult to enter a long, complicated password and, in addition, use only some characters. However, we know that this significantly reduces the risk of password theft by criminals.
Design work is, in effect, constant balancing between what we want to achieve in business and what we need to achieve for regulatory reasons. The point of balance, the specific centre of gravity, is what the client expects, which will make him/her use a given solution, preferably not only once, but she/he will come back to it and recommend it to others.
Is there anything you would like to add at the end of our conversation?
Magdalena Równicka: It is worth remembering one more rule. Let us strive for the ideal but do not wait for it. Let us implement solutions that are good enough, sufficiently effective, those that the user can already use. Let’s learn by watching them being used. Often, waiting for the ideal means that we do not implement anything and all the effort put into work by the team is wasted. There is no greater motivation for a project team than the fact that someone is already using their solution.
The complicated process of creating UX, learning from mistakes and starting over and over again gives great satisfaction. Real success comes when users are found to be using it effectively, easily and sometimes even with joy. If at the same time they pursue the goals that we set for ourselves and for them at the beginning of this path, then we can speak of a real success. Then all the toil on the way makes sense and we catch wind in our sails for subsequent realizations.