Making the mobile app simple, easy and fun

What can I say, I love trying out new apps, and I especially enjoy trying out new love location-based service (LBS) apps – except it is, when they get it completely and horribly wrong.

There’s little doubt that in the coming years location based services and augmented reality will shape the way we interact with our surroundings, search for products, and share information, and apparently a lot of other people think the same, which is why you tend to hear more and more these days about what’s hopping in LBS on your everyday tech blogs and in even more traditional media, i.e. the WSJ.

But this post isn’t about how great LBS is, it’s about how horrible some people make LBS. Forget Key Success Factors, let’s talk about Key Failure Factors or KFF’s.

What I mean by this is that mobile devices function in such a way that you have a need and then you use that device to fulfill that need. In the example of a photo, you see something cool, you snap that photo, and that need is fulfilled.

A few applications do an excellent job of fulfilling these needs, these applications are simple, they’re intuitive, and sometimes they can even even boas to be fun, and are growing at the rate of the plague in medieval europe. Unfortunately there’s only a handful of these at best, and the rest of the so-called LBS apps fall short of usability, they are in fact – painful – to use.

One such monstrosity is Whrrl, when started by Amazon veterans in ’07 was a forward thinking product indeed, but one that succumbed to what can only be explained as horrible execution. Why? Well it doesn’t make sense. It’s convoluted, it’s complex, it utilizes it’s own jargon that any new user has to learn, and best (or worst) of all, it has – get this – tutorials. Yes, tutorials.

Any phone application, or for that matter website that needs a “tutorial” is inherently flawed. Imagine – a google tutorial. You don’t need one because it’s just that simple to use. Remember web directories. They were fun to navigate weren’t they? And so now they’re done.

The user needs to “get” what’s going on from the moment they load the app / land on the page, if that user doesn’t “get” it within the first 15 seconds, chances or a repeat use / visit are slim to none. So ask yourselves objectively, if I were your regular tom dick or harry, how would I see this app. Would I get it?

If not, there may still be room to save the concept so fear not, here are a few simple ways to ensure that neither you, nor your product winds up as a jargon filled monstrosity understood only by the people who created it. :EXAMPLE:

The most important is. KISS – keep it simple, stupid, and the second is use design thinking, get everyone involved in the initial stages, but ensure there’s a goal and objective. Nothing worse than 40 cooks in the kitchen, and remember, the product should be understood by the technologically speaking lowest common denominator. In my case – my parents. If they get it. We’re good.

Knowing your customer – the key to successful design

More often than not you will see features and ideas developed and implemented int0 products that serve no purpose whatsoever, they may be nifty little things such as a fingerprint scan to bypass the password on your mobile app, of they may be a peripheral port on an some electronics that serves absolutely no purpose other than being there. Why do we put them in? To make the product cooler? To make it future ready? For 5 years down the line? Most of the time, all these extra features are useless, and here’s why.

Let’s look at it this way.

  1. What real purpose do these extra features serve? And
  1. How do your customers, or how will your customers engage your product and/or service.

Often times when designing your product or service you’ll want to add in additional “doo-babs” because they’re cool, or will make your product stand out from the competition, or will allow for the eventual possibility of expansion five years down the line. But in reality, will any of this provide an added benefit or is it just some kitsch that cost you time and money to develop? And how do you know if a feature is necessary, well this second part comes down to knowing your customer.

Who is your customer, how does your customer engage the product or service – what is the value that your product or service offers your customer.

Let’s look at the mobile fingerprint concept which recently came up in conversation at an entrepreneurship meeting that I attended here in Barcelona. Sure, it’s a nifty little feature that substitutes the login/password combo of a mobile application, but what does it add in terms of functionality. Not much. But what does it take away in terms of time & resources?

Implementing a traditional login/password combo takes about 5 minutes worth of work, fingerprint recognition, in all likelihood a bit more – in fact probably a lot more.

The time that it took the programmer to develop the fingerprint recognition would have been better spent working on a core function of the software or making sure that the software is bug free, and if that had already been completed then time to market would have been decreased. Lower time to market, the quicker your company starts earning ducats.

Just because a feature may seem “cool”, it’s not necessarily a key component. Will something like a fingerprint password scan make the customer use your product over your competitions? Personal privacy issues aside, probably not.

What will make them use it over the other is the value it offers. Software developers often go beyond themselves and develop really cool but really useless technologies – i.e. aforementioned fingerprint login. But logins and fingerprints aside, they’ll often develop feature heavy applications where the end user will simply want a stripper down version. Meaning, the end user will typically not engage a phone for more than 15 seconds – aside from a flight, a bus ride, or a few hops on the metro. They want their info, they get their info, and they exit the application.Wham, bam, thank you ma’am. A good example of a stripped down version of a software is 37 signals – all they provide are the basics, and leave the hoopla out of it.

By developing 50,000 features into that application that are for the most part an unnecessary expenditure, you’re wasting money, resources, and time, but more importantly you’re not thinking how the customer will use your product.

At the end of the day successful design is not about “cool” but about “functionality” and that applies to anything from mobile applications, to chairs, and cars – and once that functionality is in there, well then you can add in the cool.

Monetizing the mobile application.

monetizing mobile applications

People have downloaded your mobile app, great but you’re not making any chips? Well here are a few reasons why, read them, and turn those frown into upside downs.

Mistakes Companies Make when Monetizing Mobile Apps

Mistake one. You decided to go for advertising. But who on earth will click on a mobile ad that will take them to “cheap flights to Rio de Janeiro” – mobile advertising as a whole does not currently work. No one in their right mind will want to go to a new website to spend time looking over A,B,C,D,E when they want the app to give them their info there and now.

Mistake two. App sales. While putting a price tag on your application may seem like a good idea, you’ve got to think, will anyone actually pay for it? As the app developer you think your app is probably better than it really is in actuality, and a 2.99 price tag on it may be too much. Now if you’re app is something like an internet updated timetable for trains on the London Underground, or something that helps hack life and make it a tad bit easier, then great, you can charge, but be sure that the price you’re asking is worth it.

Mistake three. Giving away value added services for free. You sold the app, and now you made a few bucks, great, but that’s a one off sale, and your cash flow is limited to how many people buy your products how many times. Instead of selling the app, give it away and charge for value added services. What do we mean?

Look at TapTap Revenge, a silly guitar hero type music game for the iPhone, some songs are given away for free to the consumer and are typically promotional songs that the record company pays Tapulous to publicize, the consumer wins by recieveing more content, the record company wins by increasing awareness of the new album / artist, and Tapulous wins by getting a few bucks.

But the buck doesn’t stop there, the company also offers the consumer premium content that they have to pay to download, these being known artists and new chart topping songs. The price is equivalent to iTunes, but again, everyone wins.

Again, when we say free we don’t just mean the end user, free may also relate to a B2B service. Say you plug into an augmented reality (AR) app that you download for free as a user, that app should have a strong B2B model where hotels/restaurants/stores can purchase a listings in the AR.

Mistake Four. You business model doesn’t allow you to monetize. More often than you would think people develop applications that simply cannot be monitized, how does this happen. The value proposition is not there, and it has a weak business model. Read all about it here. Always remember, a broken business model is a lot harder to fix when there’s a product, than to think of a good business model and build a product around it.

Mistake Five. You’ve thunk like an engineer and developed for the wrong platform. Every mobile developer I’ve ever spoken to loved Android. It’s open, its flexibile, it’s easy to develop for, it’s based on Linux, and has great overall functionality. Great! but who uses it? Currently the iPhone leads the global bandwith game globally, it’s app store offers the most products and is easily accessible and available, and is currently the market leader.

So, do you develop a pay to pay software product for a platform that is not the industry leader in terms of consumer apps, or do you go for the big market, where you will have more potential clients. The answer seems obvious, yet engineers are developing for the wrong platforms because they think those platforms are better. Was Beta-max a better product than VHS, it sure was, but who won out in the end. VHS. Consumer acceptance is key.

So how do we monetize an application.

Don’t go for advertising, it’s broken. Price your app accordingly, or give it away if you rely of B2B sales. Sell add on/value added services with your app. Think about your ideas business model before devoting resources to it. And finally offer your products to those that can actually drink from them, meaning, high consumer acceptance, and penetration.

Getting the mobile app business model right

mobile business model

There is no mobile business model.

A few years ago it was “social networking” before that it was “dot coms” and before that, well… betamax. But jokes aside each new hot technology trend is subject to the same problems when it comes to business model, there are none, so let’s invent one. .

We’re still experiencing the lack of business model in the mobile marketplace – now we’re not referring to the sales of handsets, nor the fees covered by mobile operators, what we’re referring to is mobile application development, and it’s monetization.

We have to remember that the fundamental difference between a mobile phone and a laptop, desktop, netbook, or even the iPad is the way in which they are used. Mobile use is best described as coming in bursts.

You need info, you pull the phone out, look for whatever information you need and put it away. You don’t spend hours surfing the net, you don’t stream last night’s favorite shows, and you definitely don’t edit your excel spreadsheet or write the next chapter in the novel you’ve been working on.

The mobile is a device that is meant for burst use. Even such applications as iPhone games, are used typically in bursts. You’re on the metro, the bus, etc… you’re bored you play a game for ten minutes you put it away.

So what about the business model? Aside from application sales via i.e. the Apple App Store, you’re pretty much in the dark. And even there the majority of applications that people will use are limited to what is “top rated” or “recommended”, individuals simply will not spend hours searching for an app to install on their mobile device. So as you see we have a problem.

Non-Efficient Application Delivery

As previously stated – application delivery is not efficient, and even if you have an amazing application how will you get people to pick it up and try it.

One of the better ways is to have bloggers review your apps, if they like them, the next level of users who are 1st adopters will try those applications out, if they like them, they will use them, and they will publicize them. And when speaking of publicizing, it’s imperative that you implement a facebook API into this application.

Why? Well since everyone and their mother is now on Facebook, what better way to get free publicity than through status updates.

What is the application’s Value?

It’s one thing if the application in question augments the use of a current product, i.e. TripIt, LinkedIn, Imdb.com but it’s a whole other ballgame when you’re developing a new product from scratch. Meaning, the value to the user of the application has to be there.

The Bad: An example of a bad execution is VoiceFree, the application basically allows you to post audio messages to your friends on facebook. But why on earth would anyone want that. It’s quicker to go to facebook mobile, and post a quick message to a friend than to record something, and then have someone listen to it. After all, we read quicker than we speak, and mobile information delivery needs to be

  1. Quick
  2. Instant
  3. Provide what you’re looking for

Does this app do it? The short answer is no.  What is it’s value?  Not much albeit being a nifty idea. But nifty ideas don’t always make good business sense.

The Good: On the other hand you have another app, bump – that allows you to exchange contact information by simply bumping your phones together. This app’s value is clear from the onset, and it’s a great little app, that all truth be told should be included in the iPhone OS. Yet, how do they monetize? By offering 3rd parties access to their technology, PayPal for example uses bump technology in their application which allows users to send money to each other by bumping their phones together.

Great application, clear value proposition, great execution.

Think about it

When thinking about development of any product, be it mobile, internet, physical, you always have to consider what value it will offer the customer, simply devoting resources to a great idea is for the most part an exercise in futility if you don’t know how you’ll monetize it, be it today, or tomorrow. At the end of the day, what really differentiates the mobile platform is it’s delivery, and use, remember it’s busts, but aside from that, a product is a product and needs to have a business model behind it.

Pin It on Pinterest