Been there, done that: storm clouds are gathering above a project that started off as clear-cut and feasible from both the client and UX agency sides. The third milestone had to be postponed, because more and more interested parties were getting involved, all pushing their own agendas and needs. At one point, management questions the validity of the whole project, and even developers are getting restless because their capacity was tied down to the hours. However, this could have been avoided with thoughtful planning and protocols. This article sheds light on the biggest pitfalls in designing digital fintech products, and more importantly, how to avoid them.
At the CoolBrokers board meeting in Amsterdam it was decided that it would be profitable to release a smart, easy-to-use mobile Fintech application that enables their customers to track their investments in real time. They came up with a business plan and allocated the adequate budget for it. They appointed a project manager, provided them with the necessary room for maneuver, the right to make decisions and also tasked them to consult with the department heads. The Fintech app's UX design was underway. By the help of the in-house UX specialist, they contacted and contracted the right partner agency to thoroughly examine the needs and habits of prospective users. Ideas were formed, wireframes were presented, the agency and the developers seamlessly worked together to deliver the different building blocks of the Fintech app until they assembled a working prototype, and finally the product was ready.Well, it did not go down like this at all.In fact, at the board meeting, someone suggested that their biggest competitor, BestInvestors in Brussels, had already built a mobile application, so they should immediately have one. Salespeople suddenly paid more attention than usual and saw a new avenue to bombard the clients, thus supporting the project immediately, which eventually ended up under the purview of the marketing department, as they still had some funds for the fiscal year. Someone in the marketing department compiled a ballpark list of essential features for the developers, who started developing like crazy - the marketing department wanted to deliver results in 2 months at the upcoming corporate bash celebrating the firm’s anniversary. Few weeks later someone suggested it would be great to have an app that looks cool, so they involved an Amsterdam UX agency in the process. The agency immediately suggested a UX research on the habits and needs of prospective users, but unfortunately there was no time nor funds to facilitate this request.
The second scenario may seem exaggerated, but it has roots in harsh reality: those who are involved in design or to be honest, deal with anything that requires client-agency cooperation, have already experienced similar pitfalls that could have been avoided with some foresight.
This article will generally focus on the products of financial service providers, mainly because we have worked on joint projects with many industry players in recent years. These included international financial institutions such as BNP Paribas Fortis (Brussels, Belgium), KBC, Sberbank, Unicredit or Citibank, and almost all major Hungarian banks (Erste, OTP or K&H). In addition, I will mention some fintech startups as well, for example Fundastik (an alternative investment planning tool) or Simple by OTP (Hungary's best-known mobile payment application). I am not trying to single out anyone, let alone those who are present, so the examples I will come up with are rather general and talk about the biggest pitfalls in UX fintech and digital banking.
Most people are familiar with the concepts of UX, design thinking or customer experience, but still often superficially at the level of buzzwords, not well integrated into financial organizations and processes. It is common knowledge that developers are needed because they produce a 'tangible' products, but it is not yet evident that designers are needed too - industry surveys suggest that there should be one designer for every 10 developers, but this is still very far from reality.
Managing design projects is still very haphazard, most of the time there is no dedicated budget allocated, the funds are coming out of the pocket of the one department that still has some. Rarely there is a dedicated department for projects like this, typically one or two employees try to juggle their regular responsibilities and work hand in hand with an external agency. I am not saying that an in-house department is the only good solution, but it is essential to have someone or even more people in-house who can handle a project like this.
This is all true not only for the field of UX but for the whole digital transformation process within the organizations. Often, there is no bigger, comprehensive vision behind the processes, only random ideas and projects. Companies do not seek to define directions, nor plan or optimize the digital channel, but when a project gets into the phase of thinking about implementation, they begin to look for experts - even though these experts should have been there from the moment the project went live. The idea of an end user and their needs and habits is only rarely dealt with whereas their needs should be the first and foremost when designing and developing a product. Let's see what cardinal 'sins' can be committed when implementing financial planning projects!
Since the concept of UX is known to all concerned with it to some extent or more and since they all have some ideas about the areas where it should be implemented, they are more confident dealing with it than they should be. If we have experience with previous projects, we think all the processes should look the same: if in the past the UX agency entered at this stage, then it should enter the flow at the exact same point, because “that’s how it is done”. Often the best foreign practices is ignored, saying, "We are not America, things are different here than at Capital One, we know our users." It is easy to become overconfident and put too much faith in past experience or advice obtained from various sources. This results in design conducted in mobile view, because somebody has read somewhere that it should be done like that despite the fact that most people will use the app on desktop computers, or if we already received the wireframe in black and white, it should be in black and white, no matter how critical a role colors would play when displaying error messages.
It is of the utmost importance to find out what our customers and users need instead of trying to tell them what we think they need. It is worth widening our horizon by checking out playful solutions like Design Studio or Lego Serious Play not only looking at the term sheet from the customer and listening to the ideas of the UX professionals. Involving the end user could result in fresh ideas that lead to new, innovative solutions. Continuous self training is essential within the company, but a single course or workshop is far from enough for this purpose. The customer does not really need to understand UX, because that’s what the experts are for, but rather how to use the UX approach, how to handle the planning process in their business. Naturally, finding best practices in the financial sector is quite difficult, as they are often closed systems (eg. Internet banking, administrator systems, etc.) that are only available to customers and internal users.
Application stores such as Google Play or Apple App Store at least show a few screenshots of the applications, but the real solution for the researcher would be if they opened an account at each relevant bank to thoroughly examine the different banking applications. However, this requires serious administrative efforts and real determination. Of course, this is not possible with internal administration systems, here the designers can only rely on what the customer shares with them, so basically design has to be done without foresight. For projects that do not have enough industry samples, it is also important to have a more in-depth review of other innovative areas, as we can draw relevant solutions from here. Solutions for well-established sites like Airbnb, Booking.com, or even Uber may also be relevant in some financial situations.
From the customer's side, it is natural that you want to see return on every step of business development, but it could end up to be counterproductive if you try to reach your goal too soon, neglecting other considerations. This is true for both the development process and the expectations from the digital product that is being prepared. It often happens that the real time requirement of a project, the natural rhythm of planning and development is not taken into account, but determined by external expectations. The client often comes up with the timeframe of the project well before the project is thoroughly planned out - according togeneral consensus, in case of an internet bank this predetermined time allotment is only half or even one third of the time actually needed to complete the project. In other cases, the client ties the project to a pre-existing milestone or event, such as the annual general meeting of investors, where the management wants to show off the progress that has been made. This, naturally, leads to haste and negligence. The rhythm of development could often be determined by the free capacity of the IT department, not the natural course of the project. This leads to cases where the pre-requested plans are stuck in development for months while logically, they could follow the rhythm of development.
This mindset can be caught in products overgrown features that are only used by a handful of users. It is avoidable if the features of the application reflect real needs and problems determined, for example, by mapping the mental models. If sales aspects pop up at the most unexpected times, it results in ad heavy home screen of an internet bank home screen peppered with non-customized but currently relevant offers, because the sales department (pardon the pun) is banking on growth from these solutions. Naturally, there is solid reasoning behind practices like this, but you can do it more subtly and efficiently by presenting tailored, event-driven offers for the customer at the right moment. The right moment is NOT when they log on to the site to actually do something on the interface what is important for them.
All of us are too familiar with the situation when, during the course of a process, a new player emerges at one point with new demands, sometimes opposite ones to the current direction of the project. It is particularly true in case of large multinational companies where the countries or branches are latecomers in certain projects but each one of them has their own agendas and expectations. Similar results can be seen if the specification is solely built on the basis of business needs, and by the time the UX designer enters the process, their hands are very much tied.
The solution lies in having clear structure in place for the decision-making process on the client’s side and by having dedicated teams responsible for each project. In addition, regular consultations and reviews put everyone on the same page, so that all the interested parties are aware of the different needs of the project and the status of its building blocks. Developing a design system that can be shared among the participants could be a great help: it can be continuously developed to meet the needs of the project, greatly increases the acceptance of the project and ensures that no participant is left out of any crucial stage of the process.
More often than not development is encouraged by what our competitors have come up with, no matter if we or our clients need that thing or not. However, if we are too obsessed with the activities of a competitor, we could be facing unrealistic expectations. At the same time, it could also limit us to focus our resources for innovation in something that a competitor has already done - take the implementation of voice control for example. Many companies see the opportunity in it, they can read the Fintech UX trends in English-speaking countries pointing towards this, but they all think that it is no coincidence that the others in the domestic market have not moved towards that, so everything remains motionless.
Generally it is better to think about what our clients need, map their needs through deep interviews or ethnographic observations that reveal real problems, issues and situations - because it is far from certain that the solution for our situation will be identical to what works for our competitors (and we cannot even be certain that they have proven to be good for them in the first place).
There are business goals to be met, but if we place this above everything else it results in focusing too much on acquiring new clients by luring them from other service providers. It ultimately means that providing high-quality services to existing clients and selling value-added services to them will be put on the back burner. We will end up with no digital strategy and our portfolio will not be treated as a unified experience. It is worth thinking in a unified, comprehensive customer experience, not just in separate digital projects that can attract new clients. In addition, it is also worthwhile to make decision makers on the client side understand that good work requires not only time but also a more creative and in-depth work environment.
A very seductive solution to save money that has no immediate, demonstrable benefit - such as pre-measurement and research. We should, however, keep it in mind that these phases that can save huge amounts of money later, simply by seeing clearly and not spending a red cent on later developments that could prove to be unfeasible. Likewise, if we do not employ an appropriately trained designer, for example, we will later have to bite the bullet when investing in a product that does not meet the standards, but costing heavily in time and money. And although it seems to have changed recently, it is still typical that we are trying to save costs on the employee side, which may be worthwhile in the short term, but not in the medium- or long run. This is also true for trying out new methods and approaches: the quarterly framework may not be burdened if we do not spend on this, but in the long run, it will be more damaging if we fail to innovate.
It is worthwhile to plan your budget (Return on Investment, ROI) based on your expected future benefits, not just thinking about the resources you invest in, but also how they will make profit in the long run. If we are uncertain, we always have the opportunity to try new methods in small investments, so our risk is less. It is also rewarding to be reasonable with our finances in the HR area: if we want to lower the cost by employing inexperienced staff at the outset, we can easily regret this when we’ll have to hire a team leader who replaces them for falling short of expectations. A much more effective approach is to recruit capable, experienced workforce first, even if they cost more to start with, and let them build team up – thus avoiding running unnecessary circles and ultimately saving money. It is also true for the field of designing that a good professional is the cheapest in the long run.
Digital transformation will not be done project by project. If we do not invest time and energy in changing the organization itself, the process will be hindered. This change has typically taken place in middle-management where the managers have more in-depth look at the projects, but top managers do not always understand the benefits at the get go. It is important that decision-makers are kept well-informed on the status of the project, but in a way not to make them feel overburdened. It is essential that managers understand what is happening and why, how much time it takes and at what cost, where the project is heading, and what the benefits are. Education in this area is essential.
It is also very important for all the people involved on the developer side to have full understanding of the processes. They need to accept that iteration is the key when designing and testing prototypes - that is to say, develop the specifications and specifications with the developers and do not expect to be available in the final form at the starting point.
When can we expect the coming of the digital Canaan in the fintech world? Well, if all interested parties are getting more informed on the goals of digitalization and the methods to achieve it and understand how it will help their business goals. Naturally, this requires continuous investment of time and energy and also education. The best Fintech UX experience can only be achieved in this way.
In my experience, the most effective structure is built like this:
However, there are some good examples in the application of UX Fintech approach to digital banking solutions from HSBC (London), Danske Bank (Copenhagen) or even ING (Amsterdam). Of course, external UX agencies need to have a broad set of methodologies and a framework that can be optimized for a given task. And if we don't try to save on research, understanding the needs of our users and gathering as much information as possible, because this is the foundation of everything.
At the CoolBrokers board meeting in Amsterdam it was decided that it would be profitable to release a smart, easy-to-use mobile Fintech application that enables their customers to track their investments in real time. They came up with a business plan and allocated the adequate budget for it. They appointed a project manager, provided them with the necessary room for maneuver, the right to make decisions and also tasked them to consult with the department heads. The Fintech app's UX design was underway. By the help of the in-house UX specialist, they contacted and contracted the right partner agency to thoroughly examine the needs and habits of prospective users. Ideas were formed, wireframes were presented, the agency and the developers seamlessly worked together to deliver the different building blocks of the Fintech app until they assembled a working prototype, and finally the product was ready.Well, it did not go down like this at all.In fact, at the board meeting, someone suggested that their biggest competitor, BestInvestors in Brussels, had already built a mobile application, so they should immediately have one. Salespeople suddenly paid more attention than usual and saw a new avenue to bombard the clients, thus supporting the project immediately, which eventually ended up under the purview of the marketing department, as they still had some funds for the fiscal year. Someone in the marketing department compiled a ballpark list of essential features for the developers, who started developing like crazy - the marketing department wanted to deliver results in 2 months at the upcoming corporate bash celebrating the firm’s anniversary. Few weeks later someone suggested it would be great to have an app that looks cool, so they involved an Amsterdam UX agency in the process. The agency immediately suggested a UX research on the habits and needs of prospective users, but unfortunately there was no time nor funds to facilitate this request.
The second scenario may seem exaggerated, but it has roots in harsh reality: those who are involved in design or to be honest, deal with anything that requires client-agency cooperation, have already experienced similar pitfalls that could have been avoided with some foresight.
This article will generally focus on the products of financial service providers, mainly because we have worked on joint projects with many industry players in recent years. These included international financial institutions such as BNP Paribas Fortis (Brussels, Belgium), KBC, Sberbank, Unicredit or Citibank, and almost all major Hungarian banks (Erste, OTP or K&H). In addition, I will mention some fintech startups as well, for example Fundastik (an alternative investment planning tool) or Simple by OTP (Hungary's best-known mobile payment application). I am not trying to single out anyone, let alone those who are present, so the examples I will come up with are rather general and talk about the biggest pitfalls in UX fintech and digital banking.
The fintech landscape
Most people are familiar with the concepts of UX, design thinking or customer experience, but still often superficially at the level of buzzwords, not well integrated into financial organizations and processes. It is common knowledge that developers are needed because they produce a 'tangible' products, but it is not yet evident that designers are needed too - industry surveys suggest that there should be one designer for every 10 developers, but this is still very far from reality.
Managing design projects is still very haphazard, most of the time there is no dedicated budget allocated, the funds are coming out of the pocket of the one department that still has some. Rarely there is a dedicated department for projects like this, typically one or two employees try to juggle their regular responsibilities and work hand in hand with an external agency. I am not saying that an in-house department is the only good solution, but it is essential to have someone or even more people in-house who can handle a project like this.
This is all true not only for the field of UX but for the whole digital transformation process within the organizations. Often, there is no bigger, comprehensive vision behind the processes, only random ideas and projects. Companies do not seek to define directions, nor plan or optimize the digital channel, but when a project gets into the phase of thinking about implementation, they begin to look for experts - even though these experts should have been there from the moment the project went live. The idea of an end user and their needs and habits is only rarely dealt with whereas their needs should be the first and foremost when designing and developing a product. Let's see what cardinal 'sins' can be committed when implementing financial planning projects!
"I know my way around this" - pride
Since the concept of UX is known to all concerned with it to some extent or more and since they all have some ideas about the areas where it should be implemented, they are more confident dealing with it than they should be. If we have experience with previous projects, we think all the processes should look the same: if in the past the UX agency entered at this stage, then it should enter the flow at the exact same point, because “that’s how it is done”. Often the best foreign practices is ignored, saying, "We are not America, things are different here than at Capital One, we know our users." It is easy to become overconfident and put too much faith in past experience or advice obtained from various sources. This results in design conducted in mobile view, because somebody has read somewhere that it should be done like that despite the fact that most people will use the app on desktop computers, or if we already received the wireframe in black and white, it should be in black and white, no matter how critical a role colors would play when displaying error messages.
It is of the utmost importance to find out what our customers and users need instead of trying to tell them what we think they need. It is worth widening our horizon by checking out playful solutions like Design Studio or Lego Serious Play not only looking at the term sheet from the customer and listening to the ideas of the UX professionals. Involving the end user could result in fresh ideas that lead to new, innovative solutions. Continuous self training is essential within the company, but a single course or workshop is far from enough for this purpose. The customer does not really need to understand UX, because that’s what the experts are for, but rather how to use the UX approach, how to handle the planning process in their business. Naturally, finding best practices in the financial sector is quite difficult, as they are often closed systems (eg. Internet banking, administrator systems, etc.) that are only available to customers and internal users.
Application stores such as Google Play or Apple App Store at least show a few screenshots of the applications, but the real solution for the researcher would be if they opened an account at each relevant bank to thoroughly examine the different banking applications. However, this requires serious administrative efforts and real determination. Of course, this is not possible with internal administration systems, here the designers can only rely on what the customer shares with them, so basically design has to be done without foresight. For projects that do not have enough industry samples, it is also important to have a more in-depth review of other innovative areas, as we can draw relevant solutions from here. Solutions for well-established sites like Airbnb, Booking.com, or even Uber may also be relevant in some financial situations.
"I want everything, now" - gluttony
From the customer's side, it is natural that you want to see return on every step of business development, but it could end up to be counterproductive if you try to reach your goal too soon, neglecting other considerations. This is true for both the development process and the expectations from the digital product that is being prepared. It often happens that the real time requirement of a project, the natural rhythm of planning and development is not taken into account, but determined by external expectations. The client often comes up with the timeframe of the project well before the project is thoroughly planned out - according togeneral consensus, in case of an internet bank this predetermined time allotment is only half or even one third of the time actually needed to complete the project. In other cases, the client ties the project to a pre-existing milestone or event, such as the annual general meeting of investors, where the management wants to show off the progress that has been made. This, naturally, leads to haste and negligence. The rhythm of development could often be determined by the free capacity of the IT department, not the natural course of the project. This leads to cases where the pre-requested plans are stuck in development for months while logically, they could follow the rhythm of development.
This mindset can be caught in products overgrown features that are only used by a handful of users. It is avoidable if the features of the application reflect real needs and problems determined, for example, by mapping the mental models. If sales aspects pop up at the most unexpected times, it results in ad heavy home screen of an internet bank home screen peppered with non-customized but currently relevant offers, because the sales department (pardon the pun) is banking on growth from these solutions. Naturally, there is solid reasoning behind practices like this, but you can do it more subtly and efficiently by presenting tailored, event-driven offers for the customer at the right moment. The right moment is NOT when they log on to the site to actually do something on the interface what is important for them.
"This should be squeezed in, too," - lust
All of us are too familiar with the situation when, during the course of a process, a new player emerges at one point with new demands, sometimes opposite ones to the current direction of the project. It is particularly true in case of large multinational companies where the countries or branches are latecomers in certain projects but each one of them has their own agendas and expectations. Similar results can be seen if the specification is solely built on the basis of business needs, and by the time the UX designer enters the process, their hands are very much tied.
The solution lies in having clear structure in place for the decision-making process on the client’s side and by having dedicated teams responsible for each project. In addition, regular consultations and reviews put everyone on the same page, so that all the interested parties are aware of the different needs of the project and the status of its building blocks. Developing a design system that can be shared among the participants could be a great help: it can be continuously developed to meet the needs of the project, greatly increases the acceptance of the project and ensures that no participant is left out of any crucial stage of the process.
"They already have it" - envy
More often than not development is encouraged by what our competitors have come up with, no matter if we or our clients need that thing or not. However, if we are too obsessed with the activities of a competitor, we could be facing unrealistic expectations. At the same time, it could also limit us to focus our resources for innovation in something that a competitor has already done - take the implementation of voice control for example. Many companies see the opportunity in it, they can read the Fintech UX trends in English-speaking countries pointing towards this, but they all think that it is no coincidence that the others in the domestic market have not moved towards that, so everything remains motionless.
Generally it is better to think about what our clients need, map their needs through deep interviews or ethnographic observations that reveal real problems, issues and situations - because it is far from certain that the solution for our situation will be identical to what works for our competitors (and we cannot even be certain that they have proven to be good for them in the first place).
"Push them down" - anger
There are business goals to be met, but if we place this above everything else it results in focusing too much on acquiring new clients by luring them from other service providers. It ultimately means that providing high-quality services to existing clients and selling value-added services to them will be put on the back burner. We will end up with no digital strategy and our portfolio will not be treated as a unified experience. It is worth thinking in a unified, comprehensive customer experience, not just in separate digital projects that can attract new clients. In addition, it is also worthwhile to make decision makers on the client side understand that good work requires not only time but also a more creative and in-depth work environment.
"We're not going to spend on this right now" - avarice
A very seductive solution to save money that has no immediate, demonstrable benefit - such as pre-measurement and research. We should, however, keep it in mind that these phases that can save huge amounts of money later, simply by seeing clearly and not spending a red cent on later developments that could prove to be unfeasible. Likewise, if we do not employ an appropriately trained designer, for example, we will later have to bite the bullet when investing in a product that does not meet the standards, but costing heavily in time and money. And although it seems to have changed recently, it is still typical that we are trying to save costs on the employee side, which may be worthwhile in the short term, but not in the medium- or long run. This is also true for trying out new methods and approaches: the quarterly framework may not be burdened if we do not spend on this, but in the long run, it will be more damaging if we fail to innovate.
It is worthwhile to plan your budget (Return on Investment, ROI) based on your expected future benefits, not just thinking about the resources you invest in, but also how they will make profit in the long run. If we are uncertain, we always have the opportunity to try new methods in small investments, so our risk is less. It is also rewarding to be reasonable with our finances in the HR area: if we want to lower the cost by employing inexperienced staff at the outset, we can easily regret this when we’ll have to hire a team leader who replaces them for falling short of expectations. A much more effective approach is to recruit capable, experienced workforce first, even if they cost more to start with, and let them build team up – thus avoiding running unnecessary circles and ultimately saving money. It is also true for the field of designing that a good professional is the cheapest in the long run.
"This will work out itself" – sloth
Digital transformation will not be done project by project. If we do not invest time and energy in changing the organization itself, the process will be hindered. This change has typically taken place in middle-management where the managers have more in-depth look at the projects, but top managers do not always understand the benefits at the get go. It is important that decision-makers are kept well-informed on the status of the project, but in a way not to make them feel overburdened. It is essential that managers understand what is happening and why, how much time it takes and at what cost, where the project is heading, and what the benefits are. Education in this area is essential.
It is also very important for all the people involved on the developer side to have full understanding of the processes. They need to accept that iteration is the key when designing and testing prototypes - that is to say, develop the specifications and specifications with the developers and do not expect to be available in the final form at the starting point.
When can we expect the coming of the digital Canaan in the fintech world? Well, if all interested parties are getting more informed on the goals of digitalization and the methods to achieve it and understand how it will help their business goals. Naturally, this requires continuous investment of time and energy and also education. The best Fintech UX experience can only be achieved in this way.
In my experience, the most effective structure is built like this:
- There is a small team on the client’s side managing the processes
- They are also in contact with one or more reliable suppliers who know and understand the values and products of the financial service provider.
However, there are some good examples in the application of UX Fintech approach to digital banking solutions from HSBC (London), Danske Bank (Copenhagen) or even ING (Amsterdam). Of course, external UX agencies need to have a broad set of methodologies and a framework that can be optimized for a given task. And if we don't try to save on research, understanding the needs of our users and gathering as much information as possible, because this is the foundation of everything.