1. Goal setting
Sometimes management wants “like the competitors have”, forgetting that your users might need something different. Or the task might be defined based on the manager’s personal preferences – where they end up liking the product, but for the actual clients it is not appropriate. Therefore, the first step should always be user research – studying the specific needs of the clients. And only then you should write the technical specifications based on this study.
If the specifications are written without a research grounded on specific client needs, finding out the root of the problem later on will be extremely difficult. Then your application will be barely used, and you will have to guess what is at fault: the technology, your IT staff or your UX designers.
2. Excessive customisation
Chinese application WeChat is an app for everything. It is so overloaded that finding the right option takes ages. The other extreme is to create a separate application for each task from one service provider. For example, if I want to use online bank both as a legal entity and as a private individual, I do not expect to have to keep two different apps on every device. The right way to go here is to find a balance between the two extremes.
3. Functionality problems
There are two frequent problems – too many features or too few features of an app. Having too many features is also a bad idea. The mobile application should be able to do basic things. Integrating everything in an app will make navigation too complicated – a UI that works in a desktop browser can be terrible for someone using their smartphone. Therefore, you should know exactly what the client needs, and focus on that. This is where UX design comes in.
4. Implementation: native VS cross-platform
There are app development technologies that are in fact compatible with all systems, and those that are natively designed for each specific operating system. In the former case, a single code base should support both Android and iOS devices. In the latter, development and maintenance costs are nearly doubled. However, having the same code work across different platforms runs into the question of selecting the right cross-platform tool to use – a decision that will be guided by the tasks your service has to perform.
Many new frameworks and cross-platform developments can die out quickly. You should keep track of how a particular technology is growing and developing with the times.
5. Contracting or in-house development
Doing things by yourselves or outsourcing a project is a matter of resources. In-house development takes some careful allocation of resources. Then again, selecting an outside company is always a lottery – you never know how things will go. You might find a great contractor with some spectacular projects in their portfolio, but then have an unprofessional developer assigned to your development – turning your dream into a quagmire. A combination of factors is important: the professionalism and experience of your outsourcing company, the professionalism and experience of specific employees doing the work, and your own ability to monitor and guide the development progress.
6. Communication among teams
The ideal option is team-to-team relationship. Something to note here is the cost analysis and reconciliation of assessments on both sides. It is important that you assess your own technical readiness adequately – are you ready to do your part (the same API or some new functionality) to integrate the new software?
7. Security
We work with financial data, which makes security a priority from the start. Integration always begins with a software audit – we cannot rely on the good faith of the developers; professional penetration testers must verify their work first. Our applications must include certain technological solutions to protect them from malicious codes and data leakage. This is a must have – you are responsible for verifying the security of your product.
There are guidelines to help you with this, such as the OWASP MASVS, which is, in fact, a list of widespread vulnerabilities to avoid or eliminate in your development. Each vulnerability is easy to prevent as long as the developer is aware of it, but it’s too easy to overlook some of them as you go along. So always discuss everything at first, and always solicit an independent penetration test before the release day.
8. Store review
Once your app is ready, it must be uploaded to the store and submitted for review. Android’s Play Store does this automatically, while in the iOS App Store it is done manually – a specific person-reviewer downloads your app and checks its performance for compliance with iOS requirements. Any violations or dubious moments will require further development before the app is released. Each such cycle takes at least a full day. So always prepare everything in advance to avoid unnecessary delays.
9. Feedback
First, you should monitor the reviews that customers leave on the App Store and on Google Play. If you refuse to respond and make changes, your rating will worsen – dissatisfied clients mean scathing comments and spoiled first Impressions. Second, you may want to think of an alternative feedback channel: provide a phone number or support button in the app itself, preferably in plain view. If the client does not know where to go with the problem they are having, they will likely complain about it in the application reviews.
10. Activity monitoring
If you have 100,000 clients and just ten downloads, start looking for where the problem is. Perhaps your app has been downloaded a lot but is not really used. Clients just open it once and never come back. What could be the reason? User behaviour analytics can help you find the problem out. There are many services nowadays that collect analytics data for you. Find a way to analyse the data accurately and draw the right conclusions. This is something that needs to be considered at the start – so set the task and assign somebody to it early on.
