iOS Human Interface Guidelines
As a class, we’re going to be dealing with Apple’s mobile operating system often, so it’s definitely worth looking into how they suggest you build for their platform, if only to avoid the embarrassment of being rejected from the App Store in the future.
To no one’s surprise, Apple has put quite a bit of thought in how they design not only their mobile operating system, but in how they design the manual that tells you how to design for their mobile operating system. It truly is quality design all the way down.
As it tells you right at the very beginning, design for iOS embodies three key traits: deference, clarity, and depth. While most of the guide is dedicated to showing you how to use the various standard UI elements present within iOS, it always refers back to these traits to justify Apple’s reasoning behind every element they use.
For instance, Apple defines deference in terms of deferring to the user’s content and wishes. The user wants to see what they asked for, not what the developer wants to show. A developer could show their logo persistently throughout the interface, but Apple encourages developers to instead change the color scheme to subtly remind the user of their brand, rather than take away valuable screen space from the user. Similarly, while Apple does define how words should be presented and when title casing should be used, they do not define a specific vocabulary for use in apps; it is recommended that the developer choose a vocabulary that their users are comfortable with, to make sure the app is neither too condescending nor too complicated.
Clarity is also one of the major elements of Apple’s iOS design, and while I thought I understood what that meant initially, it actually encompasses a lot more that I did not initially think about. While clarity does encompass ideas such as making the most important information prominent and unambiguous, it also touches on how negative space and key colors can indicate interactivity and areas of importance. One great example of this is the Notes app for iOS. Notice that there are no outlines or gradients to indicate that anything on the screen is a button. All interactivity is indicated by a key color, while content is relegated to various shades of grey.
Finally, depth isn’t just about the translucency and parallax that plays a major part of the iOS aesthetic. It also refers to the display of hierarchy of information in all of the subtle UI touches present within iOS. For instance, within the Calendar app, cycling between year, month, and day view all involve zooms that show where the selected date lies in regards to every other time. When an event is added with the top right button, it shows as a popover on top of the date, to show that the details of the event need to be decided before the user can return to the calendar view. Even the date picker relies on depth, since it assumes the user knows the order of months and days without having to show everything at once.
What I have mentioned above doesn’t even begin to scratch the surface of all the possible UI elements available to iOS developers. There’s still the 44 x 44 pt requirement for touchable objects, defining how audio should mix with other sounds from other apps, how multi-tasking should work, whether apps can accept actions, etc. The list goes on and on. However, all of these elements go back to the most basic principles Apple states on the very first page: defer to user content, provide clarity of action, and use depth to show hierarchy. If you design with these key concepts in mind, you can probably guess the rest of the guide without reading it, which in my mind is the best proof that iOS has thought its design through from every angle.
