Tuesday, February 12, 2008

Some questions to guide mobile development

Quite often when thinking about new mobile solutions I feel people are somehow getting lost and forget both their target audience and target devices. Continuing solution development in a situation like that will lead to end result that is neither successful nor something to be proud of. Below is a short list of questions that I feel might be worth asking from your project group and customer.

Is solution needed regularly or does it contain information that changes frequently?

This question relates to a very primary requirement - the solution must be available in the phone when user needs it. If user cannot understand that he might sometime need the mobile solution, he will not install nor bookmark it. If solution is not available when user's need arises, it is very difficult - or even impossible - to find it while on the move. Finding the solution with mobile terminal is still something that rarely happens, typically you find the solution with desktop and then deploy it to terminal. Give user an actual and understandable use case about the solution so that he will deploy the solution to his terminal. If user has a feeling that solution is not really needed in a mobile device - using the solution with desktop will keep user happy - he will not install it.

Do technical requirements match with target group?

It is very easy (and sometimes also fun) to design a solution that runs only on the latest and greatest high-end terminals. What is even more fun is to design the application to run only on those devices that "will be available later this year for selected market". If your target group is technology savvy early adopters then this approach can be OK but if you try to reach the wide consumer market then some rethinking is needed. Try to find out what are the minimal technical requirements and build solution to depend only on those; save the 3D effects for future releases, please.

This question can also direct your development efforts to another direction: for example when creating a browsing solution you should ask whether old WML terminals should be supported or not. If your target group doesn't use such old terminals you can put more development power to xhtml-pages.

Can you make it any simpler, please?

If there is a current solution available you can start with a simple test: take the most important feature from the application and think how would you implement that if you remove 90% of all the available features. If that seems possible then creating a mobile version from that solution looks promising. This acid test is justified by following reasons:
  • mobile devices have very limited input mechanisms and screen resolutions
  • mobile applications are used in situations where user cannot concentrate fully on the usage of the solution 
  • mobile application use cases are very task oriented; something needs to be done quickly and easily. Users will not navigate through different menus or screens

However, remember that creating a mobile solution is not only about cutting features away from the "original" solution. A winning mobile solution also adds value to its desktop variant - what that might be in your case?

How to publish the solution?

This is a major paradox in publishing mobile solutions: you will use the solution with mobile device, but you will get to know the solution's existence by desktop browsing. You must get your solution deployed to terminal before there is actual need for that. When user is on the move and wants to use the solution, it is already too late to find it. Any mobile terminal has a very limited screen estate and different solutions are competing on the same resources. Make your use case very clear and tell potential customers an emotional story why your application matters. What is the target audience and what is the right channel to reach those?

Is it visual?

On the surface this is simple item: make your solution visual so that you all the time give user visual clues where he is and where he is going, what is mandatory and what is optional, what will cost money and what is free, and so on. In practice you should consider consulting professionals to help you in this.

Well, how much does this cost?

In the desktop world users feel safe when using different applications because network connections will not cost you any extra. In mobile world situation is worse. If you target consumer users, you should remember that they are very afraid of usage costs and vast majority of them will not have a flat-rate data plan. So, make it very clear how much the application will cost to user. If you do use data connections, send SMS's, make voice calls or whatever make that very clear to users so that they feel they are in control when using your solution.

//Harri

No comments: