What To Consider When Developing A Mobile Application

0
46

The availability of technologies creates the illusion that their development is an easy and fast process. However, any wrong decision in this matter can be costly. Yuri Meitalov, head of the IT department of the British fintech platform Bilderlings, spoke about what requires special attention when creating a mobile application.

Several banking applications were released under Yuri’s leadership, and he is sure that the worst thing that can happen to a mobile application is if it is not used. A number of mistakes can lead to such a scenario at every stage of work.

Formulation of the problem

Sometimes, the management wants “like the competition” Mobile Application, forgetting that your customers need something different. Or the task is set based on the personal tastes of the manager: in the end he likes it, but the client is uncomfortable. Therefore, the first step should be user research, studying the specific needs of the clients. And only on the basis of this study, it is already possible to write the terms of reference.

It sounds corny and obvious, but you still go through it every time. When you constantly monitor your competitors, you involuntarily forget that you have a non-symmetrical audience with them. For example, we were tempted to do a lot “like others”, but our audience is primarily a business, therefore, “mass-market chips” are irrelevant for us.

“If the technical specification is written without analysis, without relying on specific client needs, then it will be difficult to find the root of the problem. The Mobile Application will not be used, and you have to guess which side of the problem is: technical, IT, design.

User research is a team task, not just a marketing department. For example, to create a banking Mobile Application, you need to study the business profile of customers, the flow of transactions and their types, the tools that people use. It is important not only to know what actions the client is doing, but also to understand why he is doing this: for what purpose a person wants to view the balance, receive a statement, make a transfer between his accounts, and so on. To do this, you need to analyze the data that is in the company, or conduct interviews with clients.

Ideally, people from different departments should work on this in order to see the whole service and move in different directions at the same time.

Excessive customization

We made the functionality the same for all clients, regardless of their profile. Many banks customize their Mobile Applications. We decided that for us it would already be overengineering, or over-complication. In addition, there is a risk of making a mistake: some function will become unavailable to someone, because the client’s needs were incorrectly identified.

Here is the Chinese WeChat – this is one Mobile Application for everything at once. It is so overwhelmed that try to find the option you want. The other extreme is to create 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, then I need to download several Mobile Applications. In an amicable way, you need to find a balance between the two extremes.

Functionality problems

The choice of how to customize the Mobile Application is the first stage, where there is a risk of going into redundancy or, conversely, insufficiency. The next one is the choice of functionality. Two common problems – some have a reduced functionality application, while others, on the contrary, have too much. Congestion is also bad.

The mobile application should be able to do basic things. Trying to inject everything there makes navigation harder. And in a mobile application, it is impossible to make navigation in the same way as in the web. Therefore, you need to know exactly what the client needs, and only do that. And this is already a UX task. Even for us, although we did everything in a minimalist way, then the feedback came: what is difficult here is difficult, but here there is a lot of functionality, which is not a fact that is needed – we were too smart.

There are times when a client asks for a feature: “I need it to be like this.” Doing something for two out of a thousand clients is wrong. We must first figure out how necessary it is for others and whether this functionality can be somehow deployed to be used. As a rule, you have to choose what is more convenient for the majority.

“The most important thing for a mobile application is that all the main functions are in plain sight. And if you have something deeper, you can hide it so that a person can find it if necessary.

Technologies: native VS cross-platform

Mobile Application development technologies can be cross-platform or native. The first option is when one basis is for Android and iOS at once, the second is a separate application for Android, separate for iOS. The native version is much more expensive: the cost of the development itself practically doubles, and it will be more expensive to maintain. And if you choose cross-platform technologies, then the question here is what exactly to do them on – it already depends on the details, tasks, and the service itself. We have chosen for ourselves a cross-platform option and a relatively new technology that appeared only last year. Since the technology is new, this is also a kind of risk: we do not yet know at what moment we will run into something.

When choosing this or that technology, you need to think ahead and figure out how you will develop – whether the selected technology will be able to cover all the needs, whether it will be possible to implement whatever you want on this platform.

The ideal option is a highly scalable technology that is not geared towards specific options, which already has some history and which, presumably, will be supported for the foreseeable future.

What seems simple today may become so outdated tomorrow that there is no one to support this technology. Here is something new, and the smartphone supports it. And then a new iPhone comes out, and there is something so innovative that only native applications can use it, and cross-platform ones will have to adapt for a couple of months. And this must also be taken into account. Many new frameworks and cross-platform developments are dying fast. Therefore, you need to monitor how this or that technology develops.

Choosing a contractor or own development

Doing it yourself or outsourcing it is a matter of resources: you just need to calculate everything carefully. It is another matter to choose the contractor himself.

Here you never fully know how it will go in the end. It happens that the company is cool and its projects are excellent, but it is not very professional developers who will be put on your project, and everything will drag on. A combination of factors is important: the professionalism and experience of the company, the professionalism and experience of specific employees and a lot of work on your part, in particular, control of development.

Communication between teams

Ideal when there is a “team” – “team” connection. For example, I had a project when we only talked on the phone with the project manager, we discussed all issues only with him, long and tedious. And there was no feedback from the team itself. It turned out to be such a damaged phone. It’s good when teams communicate with each other without the participation of managers.

Another point to check is to analyze the costs and check if the estimates are the same on both sides. In addition, it is important for your part to adequately assess your own technical readiness: to what extent you are ready to provide your part (the same API or some new functionality) necessary to implement development.

Safety

We work with financial data and think about security already at the development stage. First of all, we audit the application so that everything is not only on the conscience of the developers, but also checked by professional testers who are involved in security. The application must be implemented with certain technological solutions that protect it from malicious codes and data leakage. This is a must have, but it is you as a customer who must check how reliable your product is.

There are guides – for example, OWASP MASVS. These are, in fact, the top vulnerabilities to consider when developing. These vulnerabilities are easily closed, but if the developer does not think about it, then he may not close the weak points. Therefore, firstly, it is important to discuss everything at the start, and secondly (trust, but verify), you need a third-party penetration test.

Passage of the review

When the application is ready, it must be uploaded to the store and sent for review, i.e. For checking. In Android, this happens automatically, and in iOS manually: a specific person-reviewer downloads the application and checks how it works and whether it meets the iOS requirements. If he sees any violations or something is in doubt, he rejects the application and sends it back for revision. Each cycle takes at least a day. Therefore, to avoid such a scenario, everything must be carefully prepared in advance.

It is necessary that both the pictures and the description meet the requirements. In the case of banking applications, it becomes difficult with demo access. Imagine: the reviewer comes to the login screen – and that’s it. You will not force him to open an account. He writes “unable to verify functionality” and rejects your application. And you need to either give demo access, or write answers that access is impossible, since we have financial and customer data, but here is a link to a video where you can see how it works. And all this takes time if you don’t think it through in advance.

As a result, we made two in one: a demo access, and a video on how the application works.

Feedback

First, you need to follow the reviews that customers leave in the App Store and Google Play. If you don’t answer or change anything, then the app’s rating will fall: the client is unhappy, the comment is bad, the impression is ruined. Secondly, it would be good to think over an alternative communication channel – that is, the phone or the support button should be in the application itself, preferably in plain sight. If the client has a problem and does not know where to complain, he will write in the application reviews.

Activity monitoring

Let’s say you have a hundred thousand customers and only ten downloads. We must look for a problem. Or there are a lot of downloads, but after that the client comes in and immediately leaves, does not use the application. What is the reason? We need to collect user behavior analytics. There are many services that collect such data. The problem is to properly analyze them and draw the right conclusions. And this is also a point that should be taken into account at the start – at least, single out such a task and appoint a responsible person.

Check list

What to consider when creating an application so that customers can actually use it:

  • analysis first, then TK;
  • work on TK with the participation of all departments;
  • customization without fanaticism;
  • balance between basic and additional functions;
  • careful selection of the appropriate technology;
  • choosing a reliable contractor;
  • the possibility of direct communication between the teams of the customer and the developer;
  • security control (tests);
  • preparation for the review;
  • collecting feedback;
  • monitoring user activity.

LEAVE A REPLY

Please enter your comment!
Please enter your name here