Recently I read that Scott Jenson, Creative Director at Frog Design, believes: 'Mobile Apps Must Die' (http://designmind.frogdesign.com/blog/mobile-apps-must-die.html).
Hmm, I was chewing on this article quite a bit. Frog Design is a well known industrial design company I respect, they have influenced SAP for the better, for example with EnjoySAP and in the history of web design. Hasn’t SAP’s strategy moved from ‘UI first’ to ‘Mobile first’? Aren’t these beautiful mobile UIs the best way to overcome the sometimes painful log-on-to-a-system-first-and-then-use-a-complicated-screen-just-to-do-xyz? I really enjoy using all these mobile apps everywhere I am, it is just much better to join an Adobe Connect meeting, enter a vacation request, check StreamWorks and so on using a mobile app.
But looking closer, I notice Scott from Frog Design is very specific and talks about native apps. For him the issue is about the pain related to native apps vs. their value.
Imagine this: Saturday evening at home, the power goes out. It’s dark, the first time this happens since you have moved there a few months before. You light some candles. Then you look the dinner your family just started to cook and the big question is: How can you now contact the utility company? Do they know of the problem already, can they tell when the power is back on? Can they update you when they know more? Or just stick the head in the sand, drive to the next city, hoping there is power and a restaurant? You decide to contact the Utility. Your landline does not work thanks to your great idea to switch to an IP based phone service requiring a modem and router. But you got a smart phone and/or a tablet with wireless data service. That will do the job, but how painful will it be?
Your options are: 1. Call the utility, 2. Contact the utility via a web browser or 3. Use a mobile app.
Scott from Frog Design says: ‘As long as value is greater than pain, you’ll be ok’.
1.
1. Find the phone number. You don’t even know the name of the utility company. Try to find the meter, or maybe there is a sticker close to the electric panel, then find a phonebook. The wife finds a bill in the unpaid drawer, now use the automated voice system, then wait in line, …, possibly forever. Hang up after 10min. Painful.
2. Use the web: The bill has the web address. But on the phone or tablet, the browser is quite slow now over GPRS data service. First it loads all the useless banners, and by the time you can display an outage map specific to your area or report a problem, it times out several times. Give up after 10min, painful.
3. Use an app. Where do you start? There is no such app available on your phone or tablet. Do you search iTunes now? Or go back to the web page of the utility and find it there? The app might be several MB, just the download might take a long time (and money). And the remaining battery life is precious and the family is getting impatient… also painful.
Do you see the problem with the app? Only a few of the Utilities’ customers will already have it installed und running when they need it. We realize that a nice and shiny app alone is not the entire solution. The opportunity is definitely there to create a mobile service channel which is less painful than a call or a website visit.
Create and integrate a slim app that is easily accessible, advertise the app for example with QR codes on your bill, the meter or a fridge magnet for a simple download link. Let the app determine via the location services or the phone number who you are and where you are and you offer a superior experience.
And whether the mobile access to the utility is a native app, a hybrid app, an HTML5 app, or something else, let the architects figure that out. You only need to worry about how painful or convenient the user experience is during these 1-5 minutes.
So I agree with Scott from Frog Design: ‘You have to know what you want before you can build it’.
