For the experienced designer there’s a fair amount of noise in the iOS Human Interface Guidelines. As I work through the Guidelines I collect the most relevant information and present it in this multipart series. The section covered in this article can be found here at Apple.
Phew! The User Experience Guidelines section is one of the longest in the HIG. Let’s jump straight in.
Maintain the focus
Back at art college someone said:
When sculpting an elephant from a stone, take away everything that isn’t the elephant.
And that’s what Apple keeps harping on about in its guidelines. Get rid of anything that isn’t absolutely necessary to achieve that singular idea you set out in your original Definition Statement. Be conscious of this when assessing minute details of your app as well as when you stand back to look to consider it as a whole.
Get out of the way, button!
Making your UI subtle, specifically:
- Minimise the number and prominence of controls (without forgetting that 44x44px is the comfortable minimum size for a button).
- Consider replacing native controls with custom controls if it prevents them from being a distraction.
- Temporarily fade controls away after people have stopped interacting with them, like in iOS Photos.
Give people a logical path to follow
In most cases, give users only one path to a screen.
Apple wants you to provide an experience that’s as linear as possible – put your user on train tracks where their options are to move forward or in reverse – because its the simplest way for them to know where they are and feel comfortable. If your app doesn’t work within a linear architecture, you may need to think about simplifying it.
Avoid forcing a user to move between screens. Using a modal view rather than a new screen is a good way to prevent the user from having to navigate away from their current screen.
Humans hate surveys
Avoid asking the user for lots of information before anything useful happens. Balance any request for input by users with what you offer users in return. If you need to ask for information from a user, make them feel like they will be getting something in return. Don’t force people to give you information when you can easily find it yourself, such as their contacts or calendar information.
Downplay file-handling operations
…people should not be asked to interact with files as they do on a computer.
This is characterstic of the iOS architecture and one of the key features that distinguishes it from a desktop OS. Store data within an app, don’t rely on external file structures. Users shouldn’t be shown an open or save dialog that exposes a file hierarchy.
If your app allows people to create and edit documents, provide a document picker. Ideally a document picker should:
- Be highly graphical. Let users easily identify documents with visual representations on screen.
- Browse docs with ease. They suggest a horizontally scrolling carousel.
- Don’t make users go somewhere else to create a document. The document picker should allow them to tap a placeholder image to create a new doc.
Quick Look Preview
You can use the Quick Look Preview feature to allow people to preview documents within your app, even if your app can’t open them. More on this in the Technology Usage Guidelines.
Be socialable
When appropriate, make it easy for people to interact with others and share things like their location, opinions, and high scores. People expect to be able to share information that’s important to them.
For iPad, keep in mind that it’s possible for two people to use the device at the same time.
Avoid using settings, provide configuration options instead
App settings are relegated externally to the Settings app in iOS. I’ve always though this was a somewhat clunky aspect of iOS. Apps don’t tell you if they create settings, and often I’ll use an app without ever knowing settings were available. Apple’s not crash hot on the feature either. The guidelines clearly state: design your app not to include settings. If you have to provide them, see The Settings Bundle in the iOS Application Programming Guide.
Instead, offer configuration options in the main user interface, or on the back-of-view, if it’s an iPhone app. See the Weather app’s back-of-view configuration option to see this in action.
Obviously options that are used constantly should remain in the main user interface. Options that will be used occasionally should be moved to back-of-view on the iPhone. In the ongoing battle to keep your app simple, see if you can’t kill off those options altogether.
Make search quick and rewarding
- Build indexes of your data so that you’re always prepared for a search.
- Live-filter data when users start typing. Always with local data and when practical with remote data.
- Search bar should be at the top of the screen.
- Display placeholder content immediately, and partial results as they become available.
- Consider providing a scope bar (shown below) if the data sorts naturally into different categories.
UI elements
Use well-understood symbols in place of words where possible. Use the built-in buttons and icons described in System-Provided Buttons and Icons. For designing your own icons see Icons for Navigation Bars, Toolbars and Tab Bars.
For an app that enables an immersive task, such as a game, it’s reasonable to create completely custom controls.
Consider adding physicality and realism
Often, the more true to life your application looks and behaves, the easier it is for people to understand how it works and the more the enjoy using it.
Apple goes as far as saying:
Consider replicating the look of high-quality or precious materials.
Handling orientation changes
- Launch your app in the supported orientation.
- Avoid using a UI element that tells people to rotate the device.
- Support both variants of an orientation, whether the device’s home button is on the left or the right.
There’s a rather long section on handling orientation specifically related to the iPad. If you’d like to read more on this, refer to the Handle Orientation Changes in the Guidelines.
Button size
Give tappable elements in your application a target area of about 44x44px. The iPhone Calculator is a good example of fingertip-size controls. Here’s a 44px black square:
It’s not always possible to adhere to this. The iPhone’s keyboard is a good example.
Use subtle animation
Use animation to:
- Communicate status
- Provide useful feedback
- Enhance the sense of direct manipulation
- Help people visualise the results of their actions
Also avoid animation that seems excessive or gratuitous that can get in the way, and use the built-in animations where possible.
Swiping to delete
It’s recommended that if you include the convenient but not so visible swipe to delete feature, you should also include a more literal variation as well.
One way to achieve this is to include an Edit button in the navigation bar, which when pressed reveals a delete button for each deletable element on the screen.
Ask people to save only when necessary
In a nutshell Apple states that it’s your app’s responsibility to keep a user’s document saved and up to date. If you do need to ask people to save their changes provide an Edit button to initiate editing of a document, which when tapped is replaced by a Save and Cancel option.
Don’t go over-modal
Modality is appropriate when:
- It’s critical to get the user’s attention
- A task must be completed (or explicitly abandoned) to avoid leaving the user’s data in an ambiguous state
Always provide an obvious and safe way to exit a modal task. People should always be able to predict the fate of their work when they dismiss a modal view.
Start instantly
When starting, iOS apps should:
- Display a launch image that closely resembles the first screen of the application.
- Avoid providing any type of start up experience that prevents people from using your application immediately.
- Launch in the appropriate default orientation.
- Avoid asking people to supply setup information
Always be prepared to stop
You have to expect a user to exit your app at any time, so save user data as soon and often as possible. Save the current state when stopping at the finest level of detail possible so people don’t lose their context when starting again. For example, if your app displays scrolling data, save the current scroll position – the App Store should take it’s own advice here.
What to do when it all goes wrong
Never quit an iOS application programmatically because people will interpret this as a crash. If external circumstances prevent your app from functioning as intended, display an attractive screen that describes the problem and suggests a correction. If only some of your app’s features are not working, display a screen or an alert only when people activate the non-working feature.
EULAs
If you provide an end-user licence agreement, it gets displayed on the App Store, not within your app. It is possible to include an EULA within the app, but only if it’s absolutely necessary, for example due to legal requirements.
For iPad
Don’t just add features, enhance interactivity
When transitioning your iPhone app over to the iPad, try to enhance existing interactivity rather than adding features. Preserve the simplicity of your iPhone app, but take advantage of the larger iPad to provide a more compelling experience.
Full screen transitions are discouraged
Try to limit transitions to the elements within the UI that need it. Entire screen transitions and flipping the entire screen is discouraged. This allows people to keep track of their task and enhances the perceived stability of the app.
Restrain your information hierarchy
Try to keep people on the one screen without trying to cram too much information on the screen.
Popover Use to provide additional tools or actions.
Split view Use to flatten hierarchy.
Segmented control in a toolbar Use to filter content.
Tab bar Use to display different information categories or different application modes.
Use popovers rather than modals where possible
They’re less intrusive. A popover can be used in two ways:
- Modal popover, in which case the popover dims the screen area and requires an explicit dismissal.
- Non-modal popover, in which case the popover does not dim the screen and people can tap anywhere outside its bounds to dismiss it.
Migrate toolbar content to the top
If your iPhone application has a toolbar, consider moving that content to the top of the screen. With the additional width of the iPad screen, you should be able to provide all of your toolbar functionality in a single toolbar at the top.
And that’s the end of Part 4. Next is iOS Technology Usage Guidelines. Once that’s out of the way we get to the good part, UI Element Usage Guidelines.
