Ten best ways to fail a mobile project

This post was originally published on AIIM's Expert Blogs by Serge Huber, CTO at Jahia Solutions

********

Since summer is in full swing, vacation time is approaching and developer conferences are popping up everywhere, I thought it would be time for a little fun. I have been working with smartphone applications since the initial release of the iOS SDK, and I think I can pretty safely share my top ten list of the best ways to fail a mobile project. This list is by no means exhaustive, and I’m sure that there are other important points that I might have forgotten, but I think the ones below are already quite important, and hopefully will help you avoid some of the common pitfalls. Also the order is quite subjective, I’ve tried my best to order them in a meaningful way - but this is a difficult exercise in itself.

After all, maybe you have a good reason to fail a mobile project: maybe you hate your boss, or maybe you think people are becoming anti-social or dangerous drivers constantly manipulating these highly portable devices, so here are the best ways to achieve your goal:

10. Don’t make a mobile version of your desktop website. You think that all this nonsense about mobile devices is just a trend, and you really don’t see why you should modify your existing website that uses tons of Flash (or maybe it’s even entirely built out of flash) animations and videos just to satisfy these nagging (and filthy rich) iOS users. After all you don’t care or don’t know that even Android is dropping Flash in upcoming versions and that some projections indicate that by 2014 mobile browsing should overtake desktop browsing. Also, make sure that it is really hard to navigate your site using a mobile device by putting links all over the place and really close to each other. You should also generate very heavy pages, because after all you think that if mobile users have the money to buy a smartphone they can certainly afford the high monthly rates for 4G LTE unlimited data no ?

9. Don't put a link to the full site. Let’s assume you already have a mobile friendly website. Darn, who did that thing ? Well, it was difficult and expensive enough to do, so make sure that you keep your users captive to whatever was decided was most relevant to mobile users and that none of the other site content is accessible by not including a link to the full site. Also, make sure that if you do that you don’t use a separate domain for the mobile site and that there is no way they can escape from the vastly incomplete mobile version.

8. Don't release it on multiple platforms. Ok now some colleague of yours has managed to convince some company executives that developing a native mobile application was a good idea, and that for budget reasons they only decided to release it on one platform. Now it is your job to make sure that they will never release it for another platform, and it doesn’t matter that the smartphone market share is clearly divided at this point. If the executives decided to target only one platform, they probably have consulted fortune tellers who told them which platform will eventually win. And it doesn’t matter to alienate the rest of the market, it is not that big after all (only 6 billion mobile subscribers), so it’s not like 10% of that is still a lot of potential customers. And of course make sure to also ignore tablet users, because if they can spend that much money for a tablet why can’t they use the desktop or laptop they probably also have ? After all, there’s nothing like ignoring potentially 320 millions users by 2015 (according to Gartner).

7. Don’t use the device capabilities. Ok somehow you ended up directing the mobile project, and despite the fact that you were given a smartphone to get familiar with, you don’t see how this thing could be useful for business and spend most of your time with it playing games and searching the web. So you probably think it’s useless to integrate with native device capabilities such as the accelerometer, compass, gestures, cameras, voice recognition, because after all this is just a phone and it doesn’t need such features. Forgetting to use these features will make sure that your mobile application will in no way really stand out nor actually make the experience better for mobile users; for example by using location to help input, use voice recognition to avoid typing too much, use the camera to share pictures, videos, scan QR codes,... Building a mobile application that doesn’t stand out from a basic website is a safe way to make sure people won’t understand the value of installing the mobile application versus using your regular web site.

6. Don't budget it correctly and assume it's easy. Before even starting to implement the project, at the planning phase, make sure to budget it very tight and assume that it’s all super easy. After all, mobile vendors claim their SDKs are so powerful and developer productivity is so much higher on their platform versus their competitors’ that you can safely assume they are telling the whole truth and nothing but that and take their (marketing) word for it, can’t you? So if it’s easy to do it won’t take much to implement, and all those developers and analysts who say the most basic mobile projects start around $20,000 must just be trying to make a quick buck and are not talking from experience (who’s Forrester research to know anything about cost analysis anyway ?). Also, make sure you go mobile just because it’s trendy, and that you haven’t thought out how the application could benefit from going mobile.

5. Don't select a good back-end. If your mobile application requires a back-end server, in order to guarantee a perfect failure, make sure you don’t spend proper time thinking about selecting the proper tools for the job here. Resist the temptation to use proven software or hosting services, and always choose to do everything from scratch (this also means that you should avoid integrating with existing infrastructure such as using web services to interact with existing content management systems for example). This way you can be sure you’ll spend a lot of time and money maintaining not only the mobile application but also the software infrastructure, which will really sidetrack you if your core business area is not software development. This way you can make sure you cannot rely on support from anyone else to provide assistance should you have, god forbid, a huge success with your new mobile application and must adjust the back-end infrastructure to handle the new load. But thanks to your careful following of all the other points listed here you can make sure that never happens.

4. Don’t make it touch friendly. One very important aspect of a successful mobile application is its usability, so you should especially focus on failing this point. Here are a few tips: make sure that as many UI elements as possible are just too small to click with a finger (after all this will help stylus vendors that are now struggling, they will thank you !), you should also require double-clicking on objects since that is impossible to do with a mobile device, and most importantly you should make sure that users must input as much data as possible using the on-screen keyboard, because after all they need the practice to improve their typing speed.

Also, make sure that the only inputs that are easy to click by mistake are the ones that perform an non-undoable action, and that it is as publicly humiliating as possible. For example make sure you put send buttons right next to the on-screen keyboard, don’t ever-ever ask for confirmation for actions such as deleting, sharing with your complete contact list or Facebook friends, or modifying a text before sending it out to Twitter.

3. Don’t test it properly. Somehow despite your hardest efforts at breaking everything, your mobile developers have worked overtime in some developing country and managed to complete a first beta version of the application. My recommendation: ship it immediately, without testing it and let the end users help you test it by providing public feedback on the application store comments. After all the update process is so easy to use and since they all have a 4G LTE unlimited data contract they won’t really care if they have to download your application 10 times before they get a version that is barely functional. Also, whatever you do, don’t field test it. This could very quickly bring up problems you had never imagined possible such as losing network connectivity in the middle of an important transaction, or receiving a phone call in the same transaction, or running out of battery, or asking the user to type while he’s driving, and so on. Also remember to only test it on the simulator, and never on real devices, because after all it’s the hardware vendors job to design a proper simulator, and you can always use that as an excuse if users complain (but don’t worry you won’t have any as you dutifully respected all the points here!). A last point, remember not to test it on older devices, because you might then notice that the application is unusable because of older operating system versions, slower CPUs, less RAM, less storage capacity, …

2. Make it country specific and don’t translate it. If you are really serious and committed to failing your mobile project, you should use the possibilities offered by the various mobile application stores to limit your potential customer base as much as possible, by limiting the availability of your product to a single country. If you choose to do so, make sure that in your marketing you do not mention this fact in order to frustrate users from other countries as much as possible, who will think that they will be able to use it but then later discover it is not possible. Another point that helps failure is to promise that they will be able to access it in their country “soon”, knowing full well that that will probably never happen, and that it probably won’t even be your fault as you can also find some contractual excuse. For example the french TV Canal Plus is distributing some of their content worldwide on their website, using Flash, and they’ve made a mobile application to be able to access the same content on mobile devices that do not support Flash... only available in France. So it doesn’t matter that neighboring countries, that speak french, receive the TV channel and can access the content online using their desktop, cannot access the same content on their mobile devices. This is a really good way to scare off users and frustrate them, making it a guaranteed failure. Another similar problem concerns the availability of the mobile application in different languages. After all, as the majority of people in the world do not speak English (only in 3rd position according to Wikipedia), it makes sense to limit the potential users as much as possible as we are trying hard to fail. Maybe you should consider learning one of the languages at the bottom of that list ? More seriously, translating your application into different languages has proven multiple times to significantly expand the market for mobile applications, and that makes it a perfect way to limit the user base. If you are obliged to translate your product into other languages, I suggest you use an automated translation service such as Google Translate. Not only will that save you a lot of money, but it will guarantee that the translation will be subpar and as nobody in your company speaks those other languages they will never be able to check anyway. Customers are sure to be frustrated by the poor translation and will immediately be offended by the poor effort put into it, making sure they will never touch your app again.

1. Don’t make it easy to use and don’t make it look good. Finally, the main point that all mobile application project should respect to be as bad as possible, is to make sure that even if somehow the software does get in the hands of users, they will hate it as much as possible and not enjoy using: make it really hard to use and make it look awful. After all users that are downloading all these shiny “empty” mobile applications must be morons just going for eye-candy. What is the value of good looking and easy to use interfaces anyway? If it’s pleasing to the eye, they might want to use it more, and if it is easy to use they might be more productive using it. If it looks good it will also help promote the application since a lot of the application stores successes are partly driven by the quality of the in-app screenshots, which will usually be a deciding factor for triggering a download of a free application or a purchase of a paid application. Also, good design usually includes reflection on usability, ease of use and overall productivity using the application, all things we want to stay away from in order to make sure that we will never have to support the mobile application, because after all it was a stupid decision to start with.

There you go, following these simple steps should help you make sure that you won’t ever again have to work on a stupid and difficult mobile application project and can go back to playing Solitaire at work or write unix scripts. Of course, as I said in the introduction it is quite possible that there are important failure points missing here, others may have had different experiences in terms of mobile software development.

So, what others points would you add to this list ?

ps : enjoy the summer !

Serge Huber