As of this post, the Apple App Store has over 500,000 apps and the Android Market has close to 300,000. That’s a lot of apps! But what does that really mean? Secretly, I have always wondered why this was an advertising pitch for Apple and Google. Is 200,000 apps any better than 100,000 apps? When was the last time you heard Microsoft say there are over ten million software programs available for Windows? (note: I made that number up. I have no idea what the real number is!). The more important question should be – how many apps are actually useful and functional?
The average smartphone owner has perhaps a few dozen apps on their phone. And by and large, the majority of phone owners are downloading the same mainstream apps – Angry Birds, Google Maps, YouTube; plus some ancillary ones that are interesting to them and their hobbies (like a golfing app or bartender app). There is a very high signal to noise ratio in these marketplaces. Fortunately, through rating mechanisms and various aggregation / review sites, you can sort out the best apps. But there is still a ridiculous amount of horrible apps that are really just big pieces of shit. All developers should strive to build better apps, on any platform.
What makes an application high quality?
It’s difficult to describe exactly what makes an app crappy. In taking a statement from the Supreme Court, it’s like pornography: you know it when you see it. Long loading times. Resource hog. Unintuitive user interface. Having to sign in every time you launch the app. A million other things. Basically, an experience that ultimately leads to a quick uninstall.
Quality is important for all products. Even ice cream.
There are many reasons why there are so many bad apps. One problem is that many developers building mobile apps came from the web world – and usability is completely different on a mobile device. You see this when an app uses text links, or links that are so close together on your phone you hit the wrong button. We’ve all done it, and we have all wanted to chuck the phone across the room when this happens. Especially if it means data re-entry, which is tedious on a mobile device.
Many other developers are simply building apps that serve no purpose. Apps are no different from any other product or service – they should fulfill a need. So do some research and business planning!
What kinds of things should you consider when designing and building your apps? This certainly isn’t an all-inclusive list, but some obvious considerations include:
- Have a purpose – Seriously. It sounds obvious, but have a purpose!
- Intuitive - You shouldn’t have to hunt for what you want to do. A back button should go back a page, not exit the app (unless you are on the apps home page).
- Functional – Crashes, force closes, and broken functionality destroy a user experience. If it’s in the app, make it work. This goes hand in hand with user interface design.
- Engrossing vs. Enabling - Sometimes apps are intended for your attention, like games or a reading app. Other apps (like TotalTab) should get out of your way. Don’t mix these up!
- Big buttons with proper spacing – A user should never hit the wrong button by accident. Think about the thumbs!
- Minimize data entry - Software keyboards suck. Don’t make anyone use them unless absolutely necessary.
- Consider the use case – Where is a user going to be using this app? In a restaurant? While walking across the street? While running?
- Auto-login – Don’t make your users log in again when they re-enter your app. Phones are for multitasking – make easy to switch in and out of the app.
- Security – Respect the data your customers give you by handling it securely.
- Implement features that enhance, not distract – Does your app really need GPS? If yes, include it. But don’t include it just because it makes it look cool.
- Tie in to other services – If you store phone numbers in your app, let users dial those numbers without needing to memorize or copy the number.
- Speed - Make sure your app is fast. A parking app that takes twenty seconds to boot up and show you available spaces is too slow when you are parked in the road.
- Keep it simple – Lightweight apps are easier and more friendly than bloated ones with obscure features users might never touch. Plus it complicates the interface.
Again, certainly not a comprehensive list – but some of the more obvious ones. Bottom line: use common sense, and while building your app, do your best to think like a user! Even better yet – get your product out there and get feedback from your users!
Minimum Viable Product
How much does quality increase for each additional unit of time?
We are still building TotalTab, but we are considering all of these things, and many more. We don’t expect to get it perfect out of the gate; and you shouldn’t, either. The best validation of your apps quality is the feedback that comes from users. The tech startup world has a concept called “Minimum Viable Product” (MVP) – the lowest level of features and polish necessary for a product to be released. Many entrepreneurs say they wish they had released their app earlier; since the validation and feedback from the user base is critically important. After all; these are the people using your app!
Now, this is a bit of a gray area – and again, common sense applies. You don’t want to release an app that doesn’t work. If there is a button on the app – it should work. Your user interface should work and be reasonably clean. The idea of MVP is about getting out early so you can get feedback from users - such as what features should go next, and what bugs they discover. Some books even suggest that if you weren’t embarrassed of your app when you released it, you waited too long.
This doesn’t mean you should release garbage – simply that you don’t need every feature in the book. If the app were a car, it just needs brakes and an engine (that work!) – it doesn’t need leather seats and power windows. Our first iteration of TotalTab probably won’t have a “About Us” page in the menu. It’s just not needed in the beginning. Take a look at the graph on the left – you have to strike the balance between quality and time. There comes a point where an additional unit of effort only results in a marginal increase in quality. That path goes on forever – it’s an asymptotic curve, since 100% quality is really only theoretically achievable. Don’t get caught trying to hit that elusive 100%.
80% is probably good enough! Especially if your product is in Beta!
Use beta liberally and release often
Beta – Use it!
Going into discussion on agile methodology is beyond the scope of this post (look for it sometime in the future!), but there are a few things to consider when it comes to app quality. First, use the Beta tag! Beta means you get a break, because you are setting the expectations of your users. If something is in beta, it is understood that things might not work right. More so, users are encouraged to report defects and will often work with you on resolutions. Beta can feel like an “exclusive club” to early adopters of your product. Try that with a product you claim is 100% market ready!
When your beta users do identify issues (and they will!) get a fix out there and release updates to the app often! Quality can be a perception issue. A stagnant app that works OK can have lower perception of quality than an app with a greater number of bugs but a development team that is on top of deploying fixes and releases that address issues active users are identifying. So releasing often assures your users you are actively involved with improving the app and making it better.
How do you build quality into you work?
Needless to say, this is a topic that can cover an entire book – so please chime in in the comments with your thoughts on quality, usability, and ease-of-use! I’d love to hear about what you love and hate about the apps that are out there today!
