Learning how apps can fail has helped Ingage succeed.

steve-jobs-ibm-finger.jpg

There is a famous photo from 1983, just before the launch of the Macintosh, of Steve Jobs in New York, standing under an IBM sign and gleefully giving it the finger. It's a great image, and a reminder of Apple's rambunctious early spirit. But by the time I was there, 30 years later, Apple was moving from a consumer-only focus to one that increasingly included the enterprise.

The rise of the App Store, after all, had shown us that apps undeniably sold devices. Yet from my job running the Enterprise App Lab, working with companies of all sizes, I quickly learned something crucial: Businesses are often just terrible at building apps.

So, in a spirit of "teach a man to fish," we hatched a plan to help them improve. We would find the best of breed across a whole spectrum of business categories, identifying the company with the best app of its kind, and then bring a team from said company to Apple HQ in Cupertino and help them bring their apps from good to great.

In the end I personally worked with about 100 partners, from good old IBM, to Cisco, SAP, and Accenture to a bunch of little guys (including Scrollmotion, where I am now CEO). We would typically do a User Interface (UI) review first, then crack open the app and review the code it was built from, then do performance reviews, and even walk through the underlying business model for how they were selling it. And after we had done this maybe 50 times, we started noticing some patterns. People were making the same blunders over and over again.

Here are the 6 most consistent mistakes app designers and coders make:

A bad start

When someone downloads your app, you have maybe three to five seconds to get them really engaged; you have to be extremely careful how you choose to use that time. That superfun splash screen you've been developing? Kill it. Get users into the experience ASAP.

Lost in space

App makers constantly fail the navigation test. At any given screen or place in the app, you should be able to immediately answer four questions: Why am I here?, Where did I come from?, How did I get here?, and How do I get back? You would be amazed at how often app builders violate this fundamental rule.

Breaking the rules

UI designers always want to out-Apple Apple. They want to believe that their totally reinvented superslick new slider or tab bar will be so awesome that Apple will notice it and put it into the next iteration of iOS. Guess what: It ain't gonna happen. Use the standard "Human Interface Guidelines" and common controls Apple has already developed. Users hate it when you change the rules of how basic features function.

Asking too much, too soon

Why are you asking before I have even begun using your app if I want "push notifications" sent to me? Why are you forcing me to go through a five-step on-boarding before I have any context about what your app is even like and whether I want to be there? You are turning people off before they've had a chance to learn to love you.

Out of tune

Apple has a really great performance-tuning tool called Instruments; unfortunately very few developers know how to use it well. But Instruments is the key to solving many of the problems in third party apps, including poor scrolling performance (that horrible shaky, jittery feeling), loading delays and long buffering times, inefficient battery use, and others. Force your dev team to learn to use Instruments like your business depends on it.

Falling behind

Every year, Apple releases a ton of new stuff--hardware, software, tools, etc.--many of which require adjustments to your code and best practices. One of the deadliest mistakes your business can make is failing to keep up with Apple. You might think this doesn't apply to your team, but let me tell you, it probably does: In my experience, only the top five percent of the App Store really get this and keep up.

Alan Braun