If your company has an app (and what company doesn't these days?), I know something your designers and developers don't want you to know. It's a document right on Apple's website that contains the keys to the iOS kingdom. But because many, even most, designers haven't read it--and because they have probably violated the rules it lays out time and time again--they'd rather you didn't see it. The document goes by the dry-sounding title, "Human Interface Guidelines." It lives here. And it could change your life, or at least the life of your business.
The HIG, as it's fondly known, is a series of rules and examples for developers and designers derived from the years Apple has spent studying the ways humans use its tools. It explains, feature by feature, how you should develop your apps from a user interface point of view. It is Apple's cheat sheet for all the best UI practices, a map for building the best iOS experiences.
The HIG covers everything from what size tap areas and screens should be, to how screens should interact with one another, to the best standard controls for a given purpose. If you want to integrate Apple Pay into your app, the HIG shows you the best way Apple has found to do that; if you're going to integrate iCloud, there's a section that will help you avoid all the mistakes others have made and clue you in to what Apple considers to be the optimal solution. (Android has its own version of the HIG; it lives here.)
Whether you are a CEO, a CTO, or a design or engineering lead, the HIG puts down some critical knowledge. When I was running my team at Apple, I made people reread it seven times a year. It gets updated a lot; staying current is key. But the HIG's a pretty simple, visual document. Here are four ways you can use the HIG to make your business stronger:
For the most part, your operating rule should be "follow the HIG." For reasons I have written about here before, reinventing a wheel Apple has already designed is, usually, a sucker's game. The company has tons and tons of user research; take advantage of it! Even if you don't follow the HIG to the letter, at least get grounded in how Apple thinks things should be designed and built. If nothing else, sticking close to those principles will help you avoid getting rejected by the App Store.
Don't know what a "segment control" is? How about the difference between "table view" and "collection view"? Exactly. Until everyone on your team speaks the same tongue, communication will suffer. And so will your product. But those terms can also be a great bs detector with potential hires, especially designers and engineers. Take it into the interview, open it up, and start asking your candidate to define the terms you call out. If they don't know the answers, you're talking to the wrong person.
Here's a fun little dare: Sit down with your lead engineer(s) and a bottle of scotch. Open up the App Architecture section of the HIG. Now, hold your app in one hand and compare it with HIG best practices. As you go through the rules and features, ask yourselves, "Do we do this?" If the answer is yes, you drink; if it's no, your engineers do. I can almost guarantee who's going to be more than a little tipsy. (Then, while they're down there, ask your tech team to explain why they strayed from Apple's recommendations. The answer is that most of them have never read the HIG in the first place.)
One of the most often overlooked audiences is the roughly 15 percent of people around the world who have some form of disability. Part of Apple's HIG, found here, are what's known as "accessibility features" that can do everything from reading content aloud to users with the swipe of two fingers to providing closed captions and audio descriptions for the visually impaired. Not only do these features represent a great example of inclusive technology, but they can also put your app in front of millions of people who might otherwise not be able to engage with it.