To keep user experience consistent across apps, the major mobile platforms provide guidelines for app design. Both Google and Apple have documentation available, but they can be overwhelming for those new to app design. In part two of this series, I’ll break down these guidelines into a more digestible format.
At a high level, there are four major types of navigation models in mobile apps (we’ll keep it focused to the big two platforms: iOS and Android). Understanding these models will help you determine which best suits your application.
Scrolling Pages & Cards
Ideal for apps that provide organized and focused sections of content, pages (iOS) and cards (Android) are scrollable items displayed in a flat navigation structure.
In iOS, a page is an individual screen of content that can be accessed by swiping (usually left-right). For example, the iOS weather app uses a page for each city displayed.
Page controls allow for easy navigation between content. Be sure to use the page control to give the user orientation within the app.
Android uses cards, which show concise information and act as an entry point to more details. Unlike iOS, cards only scroll vertically.
Cards display high-level so the user can decide whether to tap. Don’t overload pages or cards with extraneous information. Use a navigational hierarchy (see below) to direct users to more information.
Bars & Drawers
Apps with multiple sections of content or functionality are good candidates for this model. Bottom navigation bars (Tab Bar on iOS, Bottom Navigation on Android) are anchored to the bottom of the screen and should be limited to five items.
Two to five mutually exclusive sections are perfect for tab bars
The Navigation Drawer is a scalable alternative when the section count is larger than five. The drawer slides in horizontally and displays a list of selectable items which represent various sections or functionality within the app.
Utilize Navigation Drawers to scale up your section navigation. This model is also fairly common in iOS, but is not explicitly named in the Human Interface Guidelines.
Sections within tab bars and navigation drawers should contain mutually exclusive types of content and functionality. It’s important to keep these menus concise, since too many options at the highest-level of navigation can add unnecessary complexity to your app.
If your app contains a large number of features, categorized items, or content, it a good candidate for a tree structure. iOS and Android both have clear notions of this model, which allows users to ‘drill down’ into increased levels of detail. Trees also cut down on interface design, since the operating systems provide standard elements for this navigational model.
Apps like Spotify provide a lot of content that needs to be traversed easily
As the name implies, this type of navigation is defined by the content or app experience. Most common in games and other apps with specialized interfaces, this navigational model is more free-form. Of course, you’ll want to emulate a common user experience and make user interactions obvious so the user feels at home navigating your app.
Best of both worlds
Sometimes a single navigational model doesn’t suffice, in which case you can mix and match. For example, the Facebook Messenger app combines a navigation bar and a tree structure. It’s up to your app how to best utilize the standard models, but be careful not to confuse the user by switching models without purpose.
Tab bars mixed with tree views are a great way to traverse multiple sections of complex content
User Interface Components
As an app maker, it’s tempting to create custom controls for your app. However, usability needs to be prioritized over aesthetics so it’s best to stick with standard controls. Standard components are familiar to users, who need to understand and interact with your app without a second thought. Apple and Google have detailed guidelines for the most familiar components, but here’s the tl;dr summary.
You are here: Navigation Bars and App Bars
Navigation Bars (iOS) and App Bars (Android) display the current location of the user within the context of the app. If it’s a tree structure, the left hand side may contain a back button – indicating that you are at least one level deep in the content. Navigation drawer buttons (aka hamburger buttons) may also be found on the left, and are usually only accessible from the ‘root’ view.
A title in the center indicates the name of the screen. Placing a logo here can clutter the interface, so avoid it when possible. If a logo is required, only display it within the home view.
One or more buttons can be stacked on the right hand side of the bar to provide access to additional functionality. This is the least-accessible corner of the app, so avoid placing buttons here that are frequently needed.
Keep your Navigation Bars clean so the user can understand where they are within the navigation
Taking Action: Buttons & Toolbars
The primary method to perform an action in an app is with a button. These can be anywhere on the screen and should have at least two states: default (before the button is pressed) and highlighted (when the button is being pressed). These states allow you to give visual feedback to the user. A third state, disabled, indicates to the user that the button is ‘turned off’ and won’t perform any action.
If you’re designing for iOS, there is also the toolbar (not to be mistaken for a tab bar). This is a row of small buttons anchored to the bottom of the screens, perfect for views with 3-5 actions available on the main content. Make sure you don’t go bar-crazy; it is not recommended to stack a toolbar on top of a tab bar.
Found in Safari, tab bars help traverse or act on the current view
The Android guidelines include two button types worth mentioning: the floating action button and persistent footer buttons. The floating action button is a button that represents the primary action with an app; only one floating action button should be used per screen. Persistent footer buttons are similar to the iOS toolbar: they’re a row of buttons anchored to the bottom of the screen. A key difference is that persistent footer buttons have full text labels whereas toolbars are typically icons only.
Floating action buttons allow the user to take action from anywhere in the app
Both iOS and Android provide the concept of lists (also named Table Views on iOS). These components display a collection of related items made up of text, images or a combination of simple subviews. These components are used when presenting a large number of items, and should be optimized for readability so the user can find what they’re looking for efficiently. As for item design, the majority of the row should be dedicated to its primary action, with any additional actions positioned on the right side of the item.
Making Choices: Pickers and Sheets
It’s often easier to quickly tap a button instead of typing out a response. Fortunately, both iOS and Android provide simple and standard components for making choices without a keyboard. These help the user save time from typing by picking an option from a pre-determined set of items such as dates or time.
Pickers provide a simple way to select a single value from a pre-determined set, such as dates or time. iOS handles these in a consistent way with dials that allows people to spin to the choice they’re looking for. Android pickers can vary and use either dials, calendar or clock face layouts. iOS users will recognize the following picker for choosing a date:
Multi-selectors keep the user from having to type out structured data
Sheets (Action Sheets in iOS) are best when the user needs to choose between several possible actions. Sheet are also a great option for confirming a tap or gesture. For example, when tapping “Cancel” the app might confirm the user’s intention with a sheet.
With a limited number of options, sheets are great for confirmation screens
Lists (Table Views in iOS) are the best option if the choices are less familiar and/or the number of choices is very long. Additionally, unlike pickers or sheets, lists allow you to choose multiple items.
Working with Gestures
Thoughtful gestures can make the difference between an average app and an exceptional app, but it’s important that they’re easy to discover and use.
Not all gestures are created equal
Some gestures are very obvious as the interface conforms to our real world expectations: tapping buttons, scrolling pickers, and swiping cards. Other gestures are less obvious. Most importantly, gestures should never hide functionality. You should ensure that there’s another way to accomplish the task since users may not discover these gestures naturally. (A great example of a hidden yet very powerful gesture is within Google Maps: try double tapping the map and slide up and down to zoom with one finger.) In general, if the gesture is something that easily translates from a physical object or desktop computer interface, it’s more likely to be discoverable and understandable.
Use standard gestures first
Similar to controls, it’s good practice to utilize standard gestures before adding or extending the user’s natural behavior. For example, swipe to delete, double-tap to zoom, shake to undo, tap and hold to copy are commonly used across the operating systems. Keep in mind that it can very confusing to change the behavior of standard gestures. They’re called “standard gestures” because most users will understand how they work. If you change their behavior, they’re no longer standards.
When standard gestures aren’t enough, before inventing a new gesture, consider extending standard gestures. For example, consider the “pull down to refresh” gesture., which emerged from the standard gesture of scrolling to the top to see the latest information. It used to be non-standard and is now embedded within the iOS SDK.
Provide visual feedback to gestures
In real world, every action creates a reaction. For example, pushing a key (action) moves it down (reaction). The reaction helps us understand our action and make sense of the world. Similarly every gesture should provide immediate feedback, communicating to users the effect of the gesture. Just as every button should have a default and highlighted state, every gesture should have a default and active state.
The Need for Speed: How Fast is Fast Enough?
As you build and test your app, it’s important to ensure that the interface is responsive, but how fast is fast enough? Usability guru Jakob Nielsen said that for the user to consider the app as “working” an operation should take no longer than a second.
I hope you’re enjoying the Design for Mobile: App UI Best Practices series. In the final part of this series, we’ll discuss communicating with people, creating your visual identity and onboarding new users.