It is commonly understood that mobile apps should have a clear focus and designed for that particular task. I wanted to say single task, but some require the ability to support more than this.
Apple are very good at making this distinction, so for example the email is separate from the calendar, which is seprate from messaging, calls etc. Each are dedicated task based apps.
However most people who are commissioning apps are more familiar with web sites and with web sites and other “channels” this clarity and focused task is not the case, indeed web sites often have a wide range of features. Leading to the famous 80% of users only use 20% of the web site.
Thus it can be hard to shift your thinking from software / web sites gluttony of features and functions, and downsize into an app.
Keeping the focus is hard.
And then there’s the “Feature Creature” whispering in your ear, ohhh it could do this, and that, and the other too… and it’s siren calls are seductive.
[ed’s note: this is something I struggle with as my job is to come up with ideas]
So when the time comes to sit down and decide the next round of features for your app you need to have some hard facts at your disposal that will drive the decisions based on those facts, and help you keep the additions meaningful.
For example:
Does anyone use this screen / section of the app,
Who uses it
When is it used most.
Should we add this section to the app.
Should we change parts …
These are normal questions to ask, and if you rely on guess work it can become a bun fight as what gets changed, and this can lead to a poor user experience, and your app not getting used as you would like.
To measure the usage of an app, native or hybrid, means you need to collect the data of who visits which part of the app, and ship this data back to your server.
Web sites have been doing this for ages, and there are some quite simple schemes you can use to start with. Firstly look through eh app and create a name or tag for all the important places or actions you would like to record for users. For example you may want to record the times people select an area from the burger menu, or even the activation of the purger menu itself.
I would then consider using a scheme such as Google Analytics or, if like IBM’s Mobile First Foundation, your mobile middleware has a method for collecting the data, then use this. In both of these cases it is just a few lines of code to collect the data and forward it to the server.
The advice here is not to necessarily collect everything the user does, but to focus on areas that are likely to be under review or a candidate for change.
This allows for simpler better focus on the outcome of the stats.
If appropriate, sending back not just a page/action tag, but also a user ID so you can separate the or identify the users, then this is wise. As you can start to think about your user’s demographics, as you may find that there are wildly different usage patterns based on the age, and location of the user.
So in Part one: recognise you should have data to help back up your decisions.
Get the data from your real user’s behaviour, and concentrate on collecting data to inform the up coming decisions.
Keep it simple and cheap, use Google or something like Mobile First Platform’s extended logging.
Then analyse the usage of the app and properly understand what your users actually do with your app.
Next part: why MVP is so named, and considering roadmaps
