Skip to Content
Author's profile photo Robert Straubinger

Are mobile apps already over?

Recently I read that Scott Jenson, Creative Director at Frog Design, believes: ‘Mobile Apps Must Die’ (

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. 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’.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hello Robert

      I like your article and thought process. I have often wondered about this same issue.  With regards to the app I think a push strategy and marketing campaign would be best.  Now days before I do business with anyone I get their app.  I think the app should have SMS, a link to the website, and phone number.  As far as reporting an outage it should be as simple as pressing a button and the phone number and geo code should be enough to start a notification of outage.  Also the phone number should be integrated into an IVR that explains the reason for high call volume and that an outage can be reported for that address by pressing a number so no long hold time. Also when these reports start coming in and Field and Customers Services gets this data they should start triangulating the problem to see where the root cause maybe and if they are in a smart grid of some sort they should be able to do a route trace (or ping) the grid for non energized assets.  This of course would automatically flow to an algorithm based router and scheduler so that the trucks can hit the road ASAP.  Keeping in constant contact with the truck would be important so that ETA at the outage area can be reported and as the power is restored push out this info to customer service and the customer base via SMS, App, and Web Page.  I guess I got carried away from the original topic slightly but an Omni Channel approach is best and one that is pushed to the customer at inception is the most effective when combined with a coordinated marketing campaign high lighting the things you said when the power goes out or your bill has arrived showing someone left the pool pump running last month its too late.  The customer should be aware monthly, weekly, or daily depending on preference what their bill amount is.  This can be via text with a download link to the app. But in conclusion the app that is installed prior to being needed will have much greater value than one that is downloaded after the event.


      Joe Reed