The worst thing that can happen to a mobile app is if it is not used. This scenario can lead to a number of errors at every stage of the operation.
Sometimes, management wants “like the competition,” forgetting that your customers want something different. Or the task is set based on the manager’s personal tastes: in the end, he likes it, but the client is uncomfortable. So the first step should be user research, a study of specific customer needs. And only on the basis of this research is it possible to write the terms of reference.
It sounds banal and obvious, but you go through this every time anyway. When you are constantly watching your competitors, you involuntarily forget that you do not have a symmetrical audience with them (finance mobile app development).
If the TOR is written without analysis, without reference to specific customer needs, it’s hard to find the root of the problem later on. The app won’t be used, and you’ll have to guess at which side of the problem: technical, IT, design.
Table of Contents
Excessive customization
We have made the functionality the same for all clients, regardless of their profile. Many banks customize applications. We decided that for us it would be overengineering, or overcomplicating. In addition, there is a risk of making a mistake: someone won’t be able to use some function because they have misidentified the client’s needs.
For example, the Chinese WeChat is one app for everything at once. It is so overloaded that it is hard to find the right option. The other extreme is to make a separate application from one service provider for each task. For example, if I want to use Bank “X” both as a legal entity and as a private one, I have to download several applications. In a good way, you have to find a balance between the two extremes.
Problems with functionality
Choosing how to customize the app is the first step, where there is a risk of going into redundancy or, conversely, insufficiency. Next is the choice of functionality. Two common problems – some people have a feature-poor app, others, on the contrary, have too much stuff. Overloading is also a bad thing.
A mobile app should allow you to do basic things. Trying to put everything in there makes it difficult to navigate. And you cannot navigate in a mobile app the way you can on the web. This is why you have to know exactly what the customer needs, and only do that. And this is the task of UX (android application development services).
Technologies: native VS cross-platform
Technologies for developing an application can be either cross-platform or native. The first is when there is one framework for Android and iOS, the second is a separate application for Android and a separate application for iOS. The native variant is much more expensive: the development cost almost doubles, and it is more expensive to maintain. And if you choose cross-platform technologies, then the question of what exactly to use depends on the details, tasks, and the service itself. We have chosen for ourselves a cross-platform option and a relatively new technology which appeared only last year. Since the technology is new, this is also a kind of risk: we do not yet know at what point we will run into something.
What seems simple today may become so obsolete tomorrow that there will be no one to support the technology. Something new comes out, and the smartphone supports it. And then a new iPhone comes out, and something is so innovative that only native applications can take advantage of it, and cross-platform applications will have a couple of months to adapt. And that has to be taken into account as well. Many new frameworks and cross-platform developments die quickly. So you have to keep an eye on how a particular technology develops.
Choosing a contractor or in-house development. Doing it yourself or outsourcing is a matter of resources: you just have to calculate everything carefully. Choosing the contractor yourself is another matter.
