What do I mean by “apps that work”? Well, the most successful apps – those that really work for users, those that are used time and time again – are apps that make the best of what a mobile device can do.
To make apps that really work, we need to answer three questions:
- Do we need an app?
- Will an app achieve what we want?
- If so, how can we do it well?
Do we need an app?
Fourteen years ago, I ran the production team for a fledgling web agency. Back then, clients would approach us saying “We need a web site”. What they meant was, “everyone else is getting a web site, we want one too”. Fast forward fourteen years, and the same thing is happening – but this time, it’s “We need an app”. As with web sites, there’s a question to answer first:
Do we need an app?
Certain types of content and functionality lend themselves to apps, certain types don’t. For this reason, we have three criteria that we apply to any app idea, to help decide if an app is the appropriate way to go.
1) Dead Time
Dead time is the time you spend commuting on the train, or travelling on the tube, or waiting for a friend, or faffing around when there’s nothing on TV. These are all chunks of time where your options for keeping yourself entertained are restricted by circumstance.
Because your iPhone or iPad is the device you always have with you, it’s ideal for filling dead time. Good examples of dead time fillers include:
- Angry Birds, with its short, self-contained, multi-try levels
- Comics, which means there’s always a comic there when you have time to read it
- The Guardian, with its offline news download feature
- Instapaper, which saves interesting articles for when you have ten minutes to read them
We applied the Dead Time criteria when Faber & Faber approached us to create an iPhone and iPad app for QI. Faber and QI have published several traditional books, which are perfect content for dipping in and out of, and are great for filling dead time. However, they’re quite heavy. They’re also large.
We looked at how people use their mobile devices when they have this dead time – and particularly how long they have available. Typically they have between 5 and 20 minutes of time to fill. So, we took all of the content from the books, and split it up into short, focussed chunks, each of which is the right length for filling dead time.
To reinforce this, we showed the books in our virtual library at different sizes – the smallest, thinnest books take 5 minutes to read, the chunkiest books take 20 minutes. By chunking up the content, and making the content fit the way people already use the device, users are more likely to return to the app next time they have some time to kill.
2) We Know Where You Live
Location awareness has become something of a buzzword for apps of late. There’s a temptation to use location in your app just because it’s available on the device.
Don’t.
But if location awareness can genuinely improve how users access your content, it can be a great way to make your app work more effectively.
Good examples include:
- London Travel Deluxe, which provides travel information appropriate for your current location
- The Good Pub Guide, for finding a decent pub anywhere in the UK
- Nosey Parker, for finding a car park by location, cost and capacity
- Rightmove, for finding and visiting houses for sale near to where you want to live
Another good example is Next Train Home, a feature we created for our UK Train Timesapp. Like many of the best ideas, Next Train Home was conceived in a pub, when a friend of mine said “This app needs to have one big button that will get me home, from wherever I am in the UK”. (He called it the “Have I got time for another pint?” button.)
The theory goes: we know where you live, or specifically, we know your home station. And in most cases, we know roughly where you are right now. Now, “roughly” turns out to be quite important, but with a bit of cleverness behind the scenes, we can work out your nearest train station in the vast majority of cases. It may be complex behind the scenes, but to the user, they have one large button that gets them home, wherever they are. In this case, location makes a big difference to how effective the app can be.
3) The App That’s Always There
This covers a wide range of apps, but all of them have one thing in common – they are there when you need them. People take their phones everywhere. For certain types of apps, this immediate, instant-on availability is at the heart of what makes them effective.
Good examples include:
- Guitar Toolkit, which means I no longer carry a chord book with me, and always have a guitar tuner to hand
- IMDb, for when I’m watching a film and think “ooo, what was he in?”
- Momento, the diary that’s actually with you when you have something to write and the time to write it down
- Hipstamatic, for taking beautiful, styled photos at the exact moment you find something worth capturing
If your content or services are useful wherever you are, or when you least expect to need them, then they probably lend themselves to a mobile app.
Once you’ve established that what you want to do lends itself to what apps and mobile devices do well, the next question is:
Will an app achieve what we want?
There are several reasons why you might want to create an app. The most obvious one is:
“I want to make money”
…whether through directly selling the app, or through advertising or in-app purchasing.
If your aim is to make money, then start by asking yourself:
- what do you have to sell?
- do you have a brand that people already recognise and trust?
- do you have content or functionality that no-one else has?
- if not, do you have the skills to do it better than anyone else?
If you want to make money from your app, but don’t have something that’s the best of its type, or the only one of its type, then it will be hard to convince people to part with their money to buy it.
There’s an extra question if you’re considering developing a game to make money:
- Are you existing and experienced games developers / level designers?
If not, there are plenty of people out there who are, and they’ll almost certainly design a better game than you will.
Reason number two:
“I want to build a new brand or community”
…by which I mean “one that doesn’t already exist”.
This time, I’m asking questions as a user:
- what’s in it for me?
- I don’t already know or trust you – what’s the reason for me to invest my time in your app?
- what do you have to offer that no-one else is doing better?
- is it going to be free?
In this case, I’m not giving up my money – I’m giving up my time. If you want my time, you’d better have something I’ll come to value pretty quickly.
Reason number three:
“I want to promote something”
This could be a sporting event, a band, a fashion label, or a real-world book launch. If this is your reason, ask yourself:
- what do you have that you can give away for free?
- more specifically, what do you have that you can give away for free, that people actually want?
Your app won’t be downloaded just because it’s free – there has to be something in it for me as a user.
There’s also a fourth reason, which we hear a lot:
“I’ve got a great idea for an app”
The problem is, everyone has a great idea for an app. Most people, when they find out what I do for a living, immediately tell me about their great idea for an app. Many of these genuinely are good ideas for apps – but very few of them are ideas that will actually make any money.
I’ll elaborate. The Sunday Times recently ran an article inviting readers to “Step right up and join the app gold rush”. It explained how “new software could make designers of us all.”
Let’s see if that claim holds up to analysis.
The article talked about a lady who had her own eureka moment. Her idea was to create an app showing pubs and bars in London, near to your current location, which have a late license.
Now, this ticks two of our boxes from earlier on: “we know where you live”, and “the app that’s always there”. It does indeed sound like a great idea for an app. However, as we read on:
- The app took three months of research and planning
- This included building a database of 350 late-night drinking establishments (which by my reckoning is four a night)
- The lady in question is not a developer herself, so she approached a company to build the app for her
- The app took a whole four days to develop and build
- It cost in the low four figures to develop
- The app has been downloaded a couple of thousand times, at a price of £2.39
If we make some assumptions about the numbers:
£2.39 x 2,000 = £4,780
Not too shabby. However: app sales are a 70/30 split with Apple, so it’s not really £2.39 per copy. And in the UK, once you take VAT into account, it’s not even 70/30 – it’s more like 60/40. For every copy she sells, our developer actually only gets £1.45.
Let’s try the maths again at the new rate:
£1.45 x 2,000 = £2,900
If we take off the cost of development (which was in the low four figures), this app is hardly part of a gold rush, especially if it took three months of research and planning to get started.
Like many of the “good ideas” we hear, this idea is just too niche to ever really take off. It’s only of use to iPhone users, based in London, who drink in bars late at night, who are aware that there’s an app to help them. It’s a good idea, and it’s suited to the device – but it’s not an idea that’s going to lead to an app gold rush for this particular developer.
So by now, hopefully you know that your idea fits what apps are good at, and suits what want to achieve. The final question is:
How do we do it well?
Actually, I’d change this round:
If you’re going to do it: do it well
The default approach to building an app is to develop a native app for each platform you target. So, you’d develop a native iPhone app in Objective-C for iOS; a native Android app in Java; and so on. The downside to this is that you’re effectively building the same app lots of times.
There is a temptation to develop your app for multiple platforms in one go. There are plenty of toolkits to enable you to do this, but all of them suffer from the same problem – an iPhone isn’t an Android phone, which isn’t a Windows phone, which isn’t a Blackberry. I don’t mean the development language you use – I mean the fundamental way each device works. Every OS has its own approach, and its own peculiar idiosyncracies.
To put it more succinctly:
If you try and develop once for every platform, you’ll end up with a rubbish app for every platform.
To put this in perspective – if you build an app that doesn’t work the way people expect, you’re going to end up with a lot of one-star reviews next to your company name. We’ve seen big-name brands launch apps, and then pull them a month later, because they were actually doing more harm than good to the company’s brand. If your app says “we didn’t take the time to do this properly”, it effectively says “we’re not bothered about our customers”. It’s better not to do it at all than to do it badly.
So: the approach we recommend is to develop a native app for one platform, and then to expand on to other platforms based on the success of the first. The choice of your first platform will differ based on your audience, but as a development company, we find this usually means iOS first, followed by whichever secondary platform best fits the target audience.
Why iOS first? For us, it’s three things:
- It’s the most consistent platform in terms of what you can do – all iOS devices do the essential things we need in a consistent way
- Because it’s been around longer than other platforms, and has a larger developer community, it’s better supported and has a larger range of experience to learn from
- Perhaps most importantly, it’s the one platform where users actually buy apps. Okay, they expect to pay 59p for them, but they still expect to pay. For us as developers, the single biggest thing Apple have got right about the App Store is the payment approach. I don’t even have to enter my credit card details, so the actual payment method is disconnected from the purchase. I’m spending iTunes money, not real money. This makes all the difference when asking users to purchase an app.
So our advice is: if you’re going to build apps, build native apps, and do it well. To make this easier, there’s one final rule you should always remember when developing apps that work:
Keep it focussed
Do a few things, and do them extremely well. For version 1 of our UK Train Times app, we deliberately left out a whole bunch of stuff – fares, tickets, station information – to keep the app focussed on doing its core task (providing real-time train information) really, really well. We wanted the app to be useable with one hand when you’re running to catch a train. Keeping your app focussed not only makes it quicker to develop, it also makes for a better app experience.
Summary
If you want an app that really works for users, before you even think about starting development, make sure you’ve asked:
- Do we need an app?
- Will an app achieve what we want?
- How can we do it well?
This doesn’t guarantee that your app will be a success – this still isn’t the gold rush some would claim – but it means you’ll be doing it for the right reasons, and your app idea will have the best chance possible.
Best of luck with making apps that work!
This is a transcript of a presentation I gave at Planet Of The Apps 2010. It’s based on my experience as MD of Agant, creators of UK Train Times and upcoming apps for QI and The Thick Of It.