Skip to content


Tired of apps? There’s an app for that!

“The mobile browser is dead. Long live the app!” touts Forbes in a recent article. 86% of time is spent in an app instead of a browser.  What went wrong? Well, nothing really, this is just what was coming for a long time (like I’ve been saying for years as well).  While the mobile browser is perfectly suited for consuming information, there are a number of factors driving app usage:

  • Majority of app usage is gaming. Mobile browser gaming kind of sucks (do you even remember the name of one?)
  • Contrary to popular belief, designing a well functioning HTML5 with lots of navigation bells and whistles is not cheaper than making an app (search for the Financial Times case study on this site)
  • HTML5 is just not there, and even if it gets “there” it will always(!) play catch-up to native apps who can much quicker and much more efficient take advantage of new device features

Source: Flurry

And the “appsplosion” is happening faster, as even distinct services create multiple apps to separate user activities or have better performance in their apps.  Or the real reason is possibly just to take up space on your device to push others out.  Of course as the number of available apps go up, so does the number of sub-par apps, and soon we find ourselves in need of something that cleans up what we don’t use, like the app Aviate.  Google and Apple are not doing anyone any favors either, with overloaded stores making it near impossible for users to find good apps, and the top 25 dominating everything as users are time poor and can’t be bothered searching.

Rodney Byfield in an article entitled “Customer integration in the App world” puts it well though:

There is a real need to harness customer input while leveraging the selection process in App development, leading to the thought that greater customer input leads to more acute selection, with the intention of creating a customer-centric product.

This is not a novel concept, in fact it is something that has been driving successful businesses for years. Except now it needs to get done in 5 square inches or less, and that is a formidable challenge. Furthermore I have seen little evidence of leveraging users in the app selection process, a technique we used in MoConDi back in the days when apps were referred to a midlets and app stores were wap sites.  I strongly believe the app fatigue that has already set in will open up formidable opportunities for those who crack the code for user involvement in app development and discovery – and the beauty is I doubt they will have to be constrained by what Apple and Google tells them to do…

Posted in The Business of Mobile.

Tagged with , , .


Goodbye PSMS?

The US operators (except Verizon which will likely follow suit) have dealt a death blow to the single most important factor besides the ringtone that enabled the mobile content market: Premium SMS billing.  Companies made a fortune on this market, often using questionable tactics to attract users ($5/week for 5 games, when you thought you were buying 1 game for $5), keep them subscribed for at least until the user acquisition cost was covered, and move on to the next user.

On a positive note…

Well, most of the dodgy ringtone providers are gone, and content has concentrated around mega app stores and alternate app stores, with carrier stores hanging in there. Premium SMS has really just been replaced by other options, whether credit cards on Google Play or iTunes, or with mobile operators and mobile direct billing.  Also, due to excessive costs, PSMS has actually been a deterrent to uptake of content purchases in most markets.  In the US, PSMS rates costs ranged from 40-50%, while direct billing rates range from 18-20%, and as such should be far preferred by content providers.

Direct billing however is far more superior method when it comes to user experience. When paying on mobile, you simply need to click a button and you are done. No need to send or receive messages and type cryptic codes. Direct billing is a true one-click experience and as such far better than any other method on mobile.  While the cost is still high compared to PayPal and credit card, for in-app transactions that range from $0.99-$4.00 typically, the difference is less than for higher priced items.

The downside…

But while direct billing is better, with it – at least in the US – comes very tight control by the mobile operators in terms of who gets approved as a merchant. In the “good old” premium SMS days you could connect through a wide range of resellers. This number has now been narrowed down to a few, and in addition you typically have to provide a list of each digital item you sell and get approval.   The industry certainly wins by removing dodgy content providers, but it will surely hurt for a while until the onboarding process of genuine merchants and developers can become smooth.

So do you need billing on mobile?

So as a developer you may just not care, and go with Google Wallet, PayPal or Amazon and be happy with it. And if you distribute your app through Google Play and Amazon, you actually do not have much choice in the matter. But if your downloads are increasingly coming from alternative app stores, and there are several with traction in the US, not having mobile billing is a huge loss simply because the ease of use which is so critical when you try to convert a $0.99 purchase decision.

If this trend catches on to other countries, developers are best to align themselves with service providers who have good inroads with the mobile operators, and can facilitate quick onboarding and approval of your app, so you can keep going as wide as possible with the most appropriate billing options.

Disclaimer: The views expressed on this post are mine and do not reflect the views of any clients or companies I am currently working for or have worked for.

Posted in The Business of Mobile.

Tagged with , , , .


Why do companies not “get” mobile?

Zynga has crashed. Badly. Massive layoffs and shift of strategy, all because they did not “get” mobile.   Facebook is getting hammered, because Facebook Home which was set to “revolutionize” the mobile screen disappointed (although seriously, it’s just a shell app. Settle down people). Of course, investors are now happy with the mobile ad revenue Facebook is generating.

Why does company after company get hammered because they fail in their mobile strategy? Why do companies with seemingly the best and brightest in tech and product development fail over and over again when the screen goes small? The answer may not be straight forward, but I do think it comes down to three things.

1. The mobile value proposition is misjudged

The mobile phone is very different from any other web device. The main difference is not just in screen size (yes, they are getting bigger, but are still small), but the context for which they are used fundamentally changes the value proposition when you design services for it.

First, let’s agree on what value is.  Value = Benefits divided by cost. Period. You get benefits, and they have a cost, whether in a monetary sense, use of your time and more.  So how did for instance Facebook get this wrong with Facebook Home? Let’s look at 3 selected benefits of Facebook vs selected benefits inherent in a mobile phone:

Benefit Web Mobile
See what friends are doing X X
Message friends X X
Call friends X

 

At first glance, the value propositions look very similar, with the web not quite being there as a calling device (excluding Skype here). However, the use case changes drastically from platform to platform. On the web, you have more time to message, you have a full keyboard, and can type quick. If you are IM’ing, replies come quick, and conversations come quick. Not so on mobile, although they are reasonably quick but not near as fast. Moreover, on mobile, the key is to quickly send messages, and you may not even want a reply, hence the popularity of SMS.

GO-SMS-Pro-Popup

To see how one key task on mobile – replying to an SMS – is implemented differently, the best way is perhaps to look at GOsms, which is a mobile messaging app, and compare to Facebook messaging. GoSms works even if your screen is locked. Brilliant. You get a message, type your response and send. Not a second lost. For Facebook Messenger, you will need to tap the message, to then see that you need to tap again to go to messenger, unlock the screen, and then you get to where the messenger app finally opens and you can respond. Facebook has clearly misjudged the cost side of the value equation here: the cost of time spent. On mobile you need speed most of the time, and apps need to be designed for this.

So in this case, a benefit that seemingly is the same changes drastically, because you have to look at the value proposition as a whole, and realize the benefit has to be defined differently.

Let’s look at the next benefit, which is seeing what friends are doing. Here Facebook Home does a brilliant job utilizing the idle screen. If you are working on a computer, you don’t really want to be checking your Facebook page all the time, but with your home screen showing updates, and lying next to your laptop, you actually could (Note to my employer: Of course I don’t do this. I am just giving a hypothetical example of what someone could be doing).  So while Facebook may get an A+ on this feature, the customization options of this news feed are cumbersome and near impossible to adjust. I do not get the same updates that I do on the web, and I cannot see where I can customize them. Although some people may at a minimum like to see the same customization of their newsfeed as they do on the web, Facebook Home has a clear opportunity to be different. In a mobile context, the updates I want to see may not be the updates I want to see the web. How hard would it be to for instance analyze my last 50 SMS messages and calls in terms of who they went to, and use that as a basis for showing me updates?

2. Design really, really matters

The smaller the screen, the less forgiveness there is. It’s a simple fact. Even the most basic sites should be designed with a mobile purpose in mind.  There is no one guide that can help you do this, but the web is full of great articles on how to design for smaller screens.

Back in the pre-smartphone days, my company MoConDi implemented an on-device catalog for mobile games (i.e. an app catalog) for mobile operator 3 in Italy. We built an incentive program around the app, and called it MeYou. With mainly no-brand apps, we managed to increase the sale of mobile games by 30%, as users preferred the smoother in-app browsing experience to the HTML5 based app store at the time.

And platform limitations should not be an issue. Industry veterans will fondly remember how good YouTube’s J2ME app was, with awesome scroll bars, pop up video window, and more:

YouTube J2ME app 1 YouTube J2ME app 2

3. Context is everything

When designing an app for mobile and web, no mobile user expects the same experience as on the bigger screen. So don’t try to design for it.

When designing utility apps, you are more easily forced into considering how the mobile user case differs from the web. Take for instance the Yelp app. The mobile version starts with the ability to click ‘Nearby’, as location is an obvious starting point. Furthermore, the app is all about simple icons, no images or ads – it’s all about accomplishing a simple thing: Find a good place to eat/hang out.  On the web however, you will see a much richer interface, with a very different focus:

 Yelp web

 Yelp mobile

I am continuously surprised over how many companies fail to adapt their online services to a mobile setting. It is simply not a matter of squeezing the same information into a smaller format – the entire context for which a user is utilizing the service or information needs to be redesigned. The contrast cannot be more stark when comparing two companies with seemingly the same name/profile: Target Australia and Target US (with the Australian company ripping off the US brand, as they have no affiliation:

 Target AU mobile shop

 Target US mobile shop

Try typing in www.target.com.au. While the Australian site does have a mobile landing page, their shop is completely not targeted to mobile usage (unless you have really, really good vision and very, very small hands). Type www.target.com, and you’ll see the site redirect to m.target.com (the ‘m.’ prefix somewhat of a de facto standard at present), and the site is adapted to small screens (and they also plug their Android app). Comparing the two on what is a must for any physical retailer – the store finder – the contrast is quite significant. Target Australia has you clicking through a number of steps to eventually find the store, and then you see almost an entire screen of opening hours:

 2013 08 05 Target AU store finder 1

 2013 08 05 Target AU store finder 2

 2013 08 05 Target AU store finder 3

 2013 08 05 Target AU store finder 4

 2013 08 05 Target AU store finder 5

 

The two screens to the left are the same screen on the handset. You have to scroll to see all of the opening hours.

Target US on the other hand give uses the option of using GPS to use the current location (crucial context info), and also allows you to limit your search based on what is available in a store. Second, when the results come, they use visuals to show you what the stores have, and show you the proximity (again, more crucial context info). Then when results are displayed, information is condensed, and store hours are shown in just a few lines for instance (which Target AU could have easily done):

 2013 08 05 Target US store finder 1

 2013 08 05 Target US store finder 2

 2013 08 05 Target US store finder 3

What is the difference? The Target US site is designed for mobile users – The Target AU site is basically a squeezed down version of their web site.

Getting lazy while designing your mobile user experience is a sure fire way to lose users and customers. There is a clear difference between those who get it, and those who don’t, and the smaller the screen gets, the clearer this difference is.

Disclaimer: The views expressed on this post are mine and do not reflect the views of any clients or companies I am currently working for or have worked for.

Posted in The Business of Mobile.

Tagged with , , , , , , , , .