Explore navigation design for iOS

♪ instrumental hip hop music ♪ ♪ Hi, I'm Sarah McClanahan, and I'm a designer on the Evangelism team. Today, I'm going to share practical tips, guidance, and best practices for how to improve navigation on your iOS apps. When apps have great navigation, it's often unnoticed because people are able to focus on the content and experience. Navigation involves teaching people about how things behave, where things belong, and how things work in your app. The goal of navigation is to provide enough of a foundation of familiarity so that people can easily discover your content and interact with your app. When navigation deviates too far from our expectations or doesn't match our natural understanding of the world, we often feel frustrated and sense that an app is hard to use. But getting navigation right requires focus and intention. And although the concepts I'm covering today are not new, they are fundamental, and they're essential to having a successful app on iOS. So whether you're new to the platform or looking for ways to improve your app experience, then this session is for you. Today, we're going to discuss tab bars, a common form of navigation on iOS. Then we'll discuss interactions for moving between screens by exploring hierarchical navigation and modal presentations. As you can see, we'll only be covering a subset of the large topic area of navigation. But we'll start here because these core patterns represent a foundation which we often see misused, and understanding them can set you up for success as your app evolves or supports other devices. Let's get started with tab bars. Tab bars are a global navigation control that sit at the bottom of the screen, categorizing an app's content into different sections. Think of tabs as a control to reflect your information hierarchy. The UI control itself should translate an already-clear grouping and establish relationship between different areas of your app. So the Tab bar represents your top-level content, which should be the top of your app's hierarchy. Each tab communicates your app's menu of options, and these sections should be meaningful and descriptive. This likely sounds really straightforward, but in practice and for various reasons, it can be easy to lose sight of in your app. Let's look at some good examples. Without seeing any of the content of these apps, notice how the tabs hint at functionality. They tell a story about what the app can do just by displaying concise labels. Listen Now and Radio indicate that this is a content-based app with auditory media. For this app, Library and Albums hint at a content-rich app with a For You tab that signals strong personalization. This app has tabs that are so focused that their functionality is self-evident and tell me exactly what I can do in those content areas. What we see often is that the first tab of apps tend to be loaded heaviest with features. Try to create balance in your interface by distributing functionality throughout your tabs. Let's go through this with an example to explore how tabs can oftentimes be misguiding or confusing. Imagine I have a fake app that lets people discover curated routes in cities just like a local cyclist. And if you're traveling, moving to a new city, or just getting into the sport, then there's an easy way to save routes and create itineraries. Here it is. Since this app is about finding routes to bike, the first thing you'll see is a map view with filters for rides. Then, there's a section with an upcoming itinerary that I can interact with by editing the content or inviting friends. And then there are routes grouped together in collection views. It can be tempting to add all your functionality into one tab just like this, because it's available at a glance. Or maybe your app has evolved over time and you've lost sight of grouping your functionality into sections on the tab bar. Well today, I invite you to reconsider this in your app. In this design, people may have to scroll a lot for what they're looking for, and it takes effort to mentally parse unrelated, disparate features. Filtering a map view and editing an itinerary are two very different features -- and mindsets -- when someone opens this app to use it. Be cautious of combining your app's functionality in this way or doing it out of fear that people won't interact with the rest of your app. It's much easier to understand an app's functionality when it's well organized and clearly communicated. One way to do this is to take a step back and ask yourself, Why do people use your app? Remember, great apps have focused solutions. They aim to do a few things really well, opposed to trying to solve everything in one app. Let's reconsider the tab bar on this cycling app. People use this app to find routes in the places they care about, that are right for their level. This is one of the most important views in the app, as it represents the content that people care about the most. So let's take a step back and reassess the tab bar to understand how a route may be used and how that content can be represented in the app in a way that feels more balanced. This is a route detail. Someone would expect to see an overview, like distance and elevation gain, as well as access to the map and road surfaces throughout the route, like sidewalks or roads. Seeing specific callouts for steep climbs or descents could help me understand if this route is right for my level. And finally, food stops along the route are great for planning. OK. So, how do people make sense of this core functionality of viewing routes? Well, a route is only helpful if you know where it is located. Routes should likely have a relationship with the city they're associated with. That may lead me to have a city overview that tells me helpful information about cycling there. And if you scroll down the view, you'd have that list of all the routes you can ride. But this app also supports routes in different cities, which means each city should go back to a list of all places. Places can become the top level of the hierarchy when navigating to routes. As you can see, there's a lot of content in this workflow alone, and it's really key to the value that this app provides. This is great justification for a tab-bar item. Notice now how it's self-contained. It wouldn't make sense to put anything in this tab that isn't about a place. Part of designing great tab bars is organizing your content. Look for these natural ways to address relationships. I can go through this exercise with other key features in the app, like itineraries, and I can ask myself, What is an itinerary? How will people use it? And where can I dedicate a place for them in my app? Even if people are unfamiliar with the content of your app, and perhaps especially if they are, it's best to communicate your functionality and content clearly, assess where it belongs in your hierarchy, and how people engage with it. Then, this app can improve from having all of the features crammed into the first tab, to a much clearer and straightforward form of navigation. Now, the core functionality is more balanced on the tab bar because these sections hold up on their own. They are related, yet distinctly different content areas and workflows. This makes navigation so much more intuitive. Next, I want to discuss a slightly related topic, but we see it expressed differently. Avoid duplicating your functionality and consolidating it into a single tab. In content-rich apps like this one, a tab titled Home, may seem like an attractive catchall to showcase functionality throughout an app in a single place. For example, maybe it seems like people aren't engaging with the Itineraries feature, and you may be worried it's because they don't know the functionality exists.

So it may seem logical to encourage engagement by repeating actions in the tab bar for more visibility, such as New Itinerary on the Places cards and maybe creating a version of an itinerary view that has the features front and center, such as inviting friends; or listing the stops with an easy action to add. It might be tempting to do this out of fear that some functionality won't be discovered throughout your app. And to clarify, this isn't about duplicating content. In many scenarios, it can make sense to have similar types of content, like songs or photos, exist on many tabs, but organized in a different way. But when it's your app's functionality, which are the actions people can take to achieve things, the redundancy creates confusion. And in practice, Home tabs disrupt an app's hierarchy. If functionality from different tabs or areas throughout an app are duplicated and added to a single screen without sufficient context, it creates redundancy and confusion. Home becomes the tab where every feature is fighting for real estate, because the tab is trying to solve a problem of discoverability. But in reality, it creates a dissociation between understanding content and how to act on it. If this is your app, consider removing the Home tab altogether. The redundancy of features prohibits people from understanding where things belong and why. Another concern about Home tabs is that the repeated functionality may cause someone to tab-jump because the action exists in another tab too. Transporting someone to another tab by tapping on an element within a view is jarring and disorienting. Never force someone to change tabs automatically. Next, one of the biggest selling points of a tabbed navigation is access to multiple top-level hierarchies, so avoid hiding or removing the tab bar throughout your navigation. Persistent access to the tab bar gives someone the ability to toggle between different levels of your information hierarchy while maintaining context in each. For example, I can look at a new route I'm considering riding in the Places tab and compare it to an itinerary I'm building in the Itinerary tab with routes I've already saved that are two levels deep into my hierarchy. This only works well if tabs have defined purpose and represent specific categories of content. Finally, all of the work you invest in a solid information architecture should be honored with clear and concise labels. Let's look at an Apple Design winner from the Interaction category this year. This is the Slopes app. I think it's so great that when you launch the app, you land on the middle tab, which is your Logbook with your season stats. The other tabs are specific. They're easy to understand, and I have an immediate sense of what the app does and how to use it. At a glance, this is because the labels are representative of the content. Record a ski day, browse resorts, compare stats with friends; they all represent core functionality with a succinct label. Tab bars are a powerful control for navigation. Let's recap everything we've learned. Use tabs to reflect your information hierarchy. Organize your features in a way that balances them across your tabs. Avoid duplicating features and merging them into a single tab. Always keep the tab bar persistent throughout your app. Finally, use clear and concise labels for each tab. All right, let's dive into interactions. When it comes to navigating between screens of an app, there are two very common forms of transition: you can navigate through an app's hierarchy with a term we sometimes refer to as a "push," such as pushing into more detail. Or, you can transition with a modal presentation. These are nonintrusive and familiar ways to traverse an app's hierarchy and transition between views. Let me show you both. When you transition through hierarchical navigation, a view pushes, which means a person has tapped on an element and the next screen slides into view from right to left. A push transition is an expected default when drilling further into an app's hierarchy. Pushing is great because it directly reflects your information hierarchy. It's a literal representation of moving through content from a high level and drilling into more detail. On the other hand, a modal is reserved for a self-contained task in an interface. Modals work great for workflows that are independent, meaning someone has enough information in that view to make decisions and complete a task. Modals are unique because they create focus by separating people from the information hierarchy. For example, creating a new itinerary is presented in a modal view. Someone can make selections or input data such as a title, a city, a range of dates, and even invite friends. This is suitable for a modal because the UI is intended to be edited and completed before dismissing the view or navigating around the rest of the app. Since it's all user input, the rest of the app isn't needed as a reference to complete the fields. Now that you're familiar with these interactions, let's dive deep on both. Starting with hierarchical navigation. Here are a couple of guidelines to consider. Use a push transition to navigate between different levels of your app's hierarchy. Hierarchical navigation reinforces the relationship between top-level and secondary content. The top-level content is higher in the hierarchy. As I want more detail, I access the supplemental views by drilling into the hierarchy. As I make selections, I narrow my options and eliminate access to the rest of the hierarchy. This is how it should be. Content should become increasingly more specific and there should be fewer options as I push in and drill into detail. When using a push transition, it's really important that the tab bar remains persistently anchored to the bottom of the screen. As we talked about before, this is one of the biggest selling points of a tabbed navigation. It's consistent. It gives access to core areas of your app because it's always available. This means people can explore content at different hierarchies. As views push in, it feels natural to swipe left to right to go back to where you came from without losing access to hierarchies in other tabs where your state should be preserved. Next, it's important to use the navigation bar at the top of the screen with appropriate labels to orient people in your hierarchy. Let me show you. As I drill into content and move through my information hierarchy, notice how the back button in the navigation bar changes to reflect the title of the screen I just came from. This is helpful as I navigate further into an app by scrolling screens and drilling in, so I never have to remember where I came from or how to get back there, because the back button can indicate the level up in the hierarchy. The other place to use hierarchical navigation is in all instances when a disclosure indicator is used. A disclosure indicator, which is also referred to as a chevron, points in the direction you're expected to transition to. When a chevron initiates a different transition, there's a disconnect between what the UI represents and the interaction that follows. The concept of pushing maps to our mental model of progression. In western cultures, we read left to right, and that direction indicates progress. But in right to left languages, such as Arabic and Hebrew, the mental model of progress is flowing in the other direction. If your app supports right to left languages, then the transition of pushing is flipped to create an association with the flow of content. The last consideration for when to use hierarchical navigation is about the context of the workflow, such as when someone is navigating frequently between content. If you're presenting a workflow that you expect people to interact with frequently by toggling between views often, app switching during the workflow, or spending significant time in the view, then use a push. A familiar example is the Messages app. Even though the hierarchy is relatively flat, I can easily move in and out of the messages with a push transition. If each message wasn't a push, but instead a modal, it would be difficult to seamlessly move between different chats. Messaging should feel fluid, but dismissing a modal when it's not relevant makes people have to think about leaving the screen, and that feels overcomplicated. Pushing allows frictionless transition between core areas of an app. That is an overview of hierarchical navigation. Let's review. Primarily, push transitions are used to traverse an app's hierarchy. Always keep the tab bar persistently anchored to the bottom of the screen. Use the navigation bar of each screen to reflect a clear title and back label to orient people in your hierarchy. Use a push when a disclosure indicator is present. And when workflows require navigating frequently between content. Hierarchical navigation is a very common and a relatively simple interaction, so this transition is likely to be used frequently in your app. However, modal presentations are more about a context shift. It's about isolating someone into a focused workflow or self-contained task. When using modals on iOS, always present them from the bottom of the screen. A modal interrupts information hierarchy. It comes from the bottom of the screen to cover your tab bar. This prevents people from drilling further into your app. And it's an intentional disruption because the purpose is to reinforce focus. So now you may be wondering, what is a self-contained task? Let's talk about three broad examples. You can use modal presentations for a simple task, a multi-step task, or for full-screen content. I'll share an example of each. First, use modality for a workflow that requires accomplishing a simple task, such as creating an event or setting a reminder. Creating a reminder requires I edit and modify the entry fields. Locking in focus while doing this helps someone achieve this task without distraction. It also minimizes the possibility of accidentally abandoning the flow by tapping on another element or tab. Second, use modality for a workflow that accommodates a complicated task. This is potentially multiple steps such as adding a transit card to the wallet. It may seem counterintuitive to use a modal for a complicated task, but remember, the purpose is to reinforce focus by hiding the tab bar and preventing people from moving around the app before the task is complete or canceled. And third, use a modal when viewing an article, video, or full-screen content that requires minimal additional navigation. When in the Fitness app starting a workout, which is presented as a video, is a great scenario for a modal presentation. In the hierarchical section, we talked about the importance of the navigation bar to orient people. It's equally important with modal presentations. When looking at the anatomy of a modal, think about the navigation bar as a guide for wayfinding. The use of labels and actions can make people feel confident about where they are and what actions they can take to go other places. A title helps orient people to the content of the screen, such as "New Itinerary." The right label is intended to be the preferred action, so it's often seen in a bolder font to emphasize importance. The label itself is a concise, affirmative verb that tells me exactly what to expect when tapped. The preferred action dismisses the modal and the previous state of the app should be preserved. If there is not yet input or interaction on the modal, then having the preferred action be inactive is a good way to clarify that fields are required in order to save or continue. If you have a preferred action, then using the left action to dismiss the modal with "Cancel" clearly indicates that I'm abandoning the workflow. If I've entered any information before tapping Cancel, this is a good time to display an alert, or an action sheet as you see here. Letting someone know that they will lose the data if continuing to cancel. But if I haven't interacted with the UI, tapping Cancel should simply dismiss the modal. Use close symbols sparingly and only when modal presentations require minimal interaction and no text input. Sometimes, you'll see an "X" in a modal as the primary way to dismiss, such as this article from the Today tab in the App Store. The close symbol works here because there is no user input, so the subtle dismiss action helps someone focus on the content. Here's an example of how the close symbol can be problematic in a modal that requires input and interaction. After I select a filter, if I tap close, will the selections be applied or canceled? Without a clearly labeled action, people will wonder, "What happens if I tap close?" So keep in mind that using labels in the navigation bar is usually preferred, as it's more affirming and the actions are more explicit. Lastly, we try to limit modals over modals because it can feel jarring and overcomplicated. It's worth calling out, that a modal view itself can support subviews and transitions when relevant. I mentioned earlier that this is an edit view, meaning that the text fields and table cells have selections and input which are intended to be interacted with and not just viewed. For example, I can tap on a table cell of one of my friends I've added to the itinerary. You expect this to push because it has a chevron, remember? When I push in, this view may show information about Kate and give me the option to remove her from the itinerary. But the labels "Add People" and "Upload Photo" are in tint color, which indicates that these actions are tappable. In each of these scenarios, they're workflows within workflows. I started by adding an itinerary, now I'm adding a photo to the itinerary. Uploading a photo is a workflow that includes quite a bit of interaction, like scrolling through my camera roll and selecting a new photo. I would also define this as a self-contained task. Once a photo is chosen, that modal is dismissed and I'm back to the first modal of the new itinerary. Try to limit multiple modality stacks, but sometimes they're required to drive consistency and focus in subviews. That is an overview of modal presentation on iOS. Modals should present from the bottom of the screen. They can be used for three types of tasks: simple, multi-step, or full-screen. Use the preferred and cancel actions in the navigation bar. Use the close symbol for content with minimal interaction. And limit modals over modals. I hope this deep dive was helpful for you. When designing navigation for your iOS apps, think about how content is organized, how people interact with your functionality, and how best to represent it in relation to your hierarchy. This way, people can easily access and interact with all of your app's amazing features. Thanks for listening. ♪