- Too much functionality
- Ignoring the differences between iOS and Android
- Bad backend architecture
- Designing for yourself, not for users
- No marketing strategy
- No organized testing
- No customer feedback
- No set goals
- Lack of flexibility
- Aggressive monetization
Developing mobile applications, like building a house or designing a new car, has many nuances.
In our experience, the following ten errors are the most common.
1. Too much functionality
At the beginning of development, the functionality of a mobile application should be simple. Starting with a large amount of functionality is counterproductive.
We have customers from Germany that we work with this way:
- Define an idea ;
- During the first week, they collect all the possible functionality that could be implemented;
- The following week, they delete all unnecessary functionality;
- Start the development process with one or two remaining points.
The selection criteria is very simple. If the answer to the question “Can the user still solve the main problem without this function?” is yes, then the functional point is instantly deleted without any second thoughts.
There is a constant temptation to add something else as new ideas come regularly – thinking up new things is addictive. For example, thinking over the product’s architecture, after a while, the initial functionality doesn’t seem so spectacular and even sufficient.
But the more features a product has, the more difficult it is to develop. It means more time, slower development, with a greater separation from the market.
A mobile application should be on the phones of users as quickly as possible. The sooner you begin to receive feedback from customers, the higher the chances of success. Once this goal is achieved, it will not be difficult to refine the functions.
2. Ignoring the differences between iOS and Android
iOS and Android are different operating systems. They have different approaches to design, conforming to different design principles, and have different navigation systems, opportunities for monetization, and other aspects of the user experience.
Cross-platform solutions or native development is a serious issue, our thoughts about which we will described in detail in another article.
However, in addition to mobile development technologies, other aspects must be taken into account:
- Android devices have physical navigation buttons, iOS devices don’t;
- The Android interface is built on the deep concept of Material Design. The principles of the iOS interface, which are described in detail in the Apple Human Interface Guidelines, are worked out by taking into account the hardware features of the devices. They are completely different principles than building for UI/UX;
- These operating systems have different audiences that need to be analyzed for each niche. For some applications, the distribution of OS types will be 50/50, for others 10/90;
- Monetization is built in different ways. It is difficult for an Android developer to sell a subscription, while advertising is much more effective. In iOS, deep sales are developed when a subscription is sold several times with increasingly advanced options;
- iOS devices are updated massively, while Android versions are highly fragmented, with more than 30% of devices using Android 5.0 and earlier, released before 2014.
3. Bad backend architecture
Often, design focuses primarily on what is visible. This is understandable and natural.
However, the backend — server logic, database structure, and its set of connected external services — is equally important.
Don’t forget that the rationality of the server architecture is important, no matter how boring and unnecessary it may seem.
4. Designing for yourself, not for users
A common mistake is to design an interface for your own tastes.
We do not make the product for ourselves. We make it for users.
Mobile app design is worth developing for users, not for yourself. You may like your design, but users may not.
That means you need to understand the audience: their emotions, tastes, principles of perception of the products, and the services that are interesting to them. With that, we can offer them a good solution and test how efficiently it works.
When choosing an icon for an application, the Japanese, for example, invite three to five designers to do the job, including audience analysis. Next, they purchase advertising leading to the landing page for the upcoming application using all these icons. The one that is more clicked on is the chosen one.
5. No marketing strategy
Think over a marketing strategy, at least in general terms, before writing a technical task. It is important.
A mobile application is a tool. The tool is always made for a specific task. Marketing is just a way to use it. Ways to promote the application, options for interacting with the audience, channels for communicating with users, and the analytical and advertising tools to be used should all be included in the initial version of the technical task.
It’s bad development planning to think of ways to promote after the mobile application is already in the store.
6. No organized testing
This is not about testing for errors in the code – this is to be taken for granted. Rather, it is the hypothesis testing methodology that is often missed.
After the mobile application is published on the App Store and Google Play, advertising is created, and, after some time, conclusions are drawn based on it. When developing mobile applications, special attention should be paid to product testing as an essential element of development.
Correct testing includes the following steps:
- Based on the marketing strategy, small cohorts (groups) of users are purchased that have clear differences but still fall within the target audience. For example, men aged 22 to 26 and 27 to 32 years old, interested in sports and having a family, from three different cities with populations over one million;
- The behavior of users in each cohort is analyzed: how often they use the application, how much it costs to attract them, whether they bought the goods or services provided, and whether they solved their problems;
- Work then continues with the liveliest cohort: necessary changes are made to the mobile application to refine it further;
- We go back to step 1 until either the cost per user is less than the profit made during a given period of time or the hypothesis is not recognized as failed.
The publication of mobile applications is only the very beginning of the path to creating a product.
7. No customer feedback
Both during the testing stage and during the early steps in development, high-quality and convenient feedback from users is crucial. Often this connection is either poorly organized or completely absent, even though, from the very beginning, it is vitally necessary.
Any person who has a question should be able to ask it in an instant. The answer should be quick and solve the problem. Organization of feedback when developing mobile applications is needed.
Positive and negative responses should be challenged: on the one hand, directing the reaction in the right direction, as constructively as possible, on the other, delivering information to you as quickly as possible with detailed context.
8. No set goals
Everyone wants their application to be popular and in demand, but without more clearly defined goals, it is impossible to effectively organize your work and the activities of the team.
Goals should be specific. What exactly should happen three months after launch to consider the mobile application successful? Perhaps this is ten thousand users, or a monthly turnover of five hundred thousand rubles.
Often, specific goals are missing, preventing the team from focusing on the result.
9. Lack of flexibility
When developing mobile applications, you need to be flexible. There is a fine line between persistence and stubbornness. The difference lies in the arguments used to explain why we continue to stand our ground. If they are logical and reasonable, then it is the first.
The market often changes, being a product of the emotions of people who, by definition, are unstable. We also change: we look at something differently, receive additional information, and change our minds based on experience.
If, at some point, you realize that you need to change direction, it’s not easy to accept – the idea is our brainchild, on which great hopes were pinned, which caused us to spend effort, time, and money.
However, to move forward it is necessary to adapt. Some functionality of the mobile application may need to be thrown away, some completely redone. It might be possible to change the entire direction of the application.
10. Aggressive monetization
As we often write in our articles and news releases, the main asset of the modern IT market is the attention of users.
If you have an active audience of one hundred thousand people, which does not bring a penny now, it is already valued at a significant amount – from $200000 or more, depending on demographic.
That is the price of attracting and retaining user attention, which can later be converted into profit in many ways.
To maximize the value of the asset, you must first gain an audience. To do this, you need to quickly and effectively meet the needs of as many people as possible, not in the width of the audience but in its depth.
A mobile app should not be intended for everyone. It should be for a specific group of people, but, as soon as you have established a connection with them, you should acquire as many of those users as quickly as possible.
Often, you want to earn as much as possible from the first users. Of course, the desire to see a return on investment as soon as possible is understandable, but that greatly inhibits the growth of the application, reducing the ultimate value of the potential asset.
Also, for development, a product needs to gain a critical mass of users, and aggressive monetization does not allow this. This does not mean that you shouldn’t make money from the start, but you need to do it as carefully as possible to maintain a balance between growth and profit.
There are many difficulties in developing mobile applications. They are comprehensive, complex, multifaceted products. However, according to the Pareto rule, the causes of 80% of failures will be from the most common 20% of errors. The preceding list of ten mistakes is just that 20%.
The preceding list of ten mistakes is just that 20%.
So, let’s make game-changing products together.