Figuring out the flow of your mobile app is tough but it’s key to the experience. Without good app flow your app will be tough to use and users will get annoyed with it. Annoyed users tend not to use the app that annoys them. In fact, there’s a statistic that only 1 in 100 apps downloaded by a user actually gets opened a second time – those aren’t good odds, so anything you can do to entice the user to come back will increase its chance of success. A way to help drive a positive app experience on Windows Phone is to follow the guidance provided by the Metro design language. This post talks about what Metro can do to help you create a great navigation experience for your app.
Even before you do layouts for each screen of your app, chances are you are charting out the navigation of your app. Which screen goes where, how to determine under what conditions the user may go to the next step, etc. It certainly sounds trivial as it’s written, but in truth it’s one of the hardest tasks to do right in app design.
The flow of your app very much defines its character, more so than any screen.
Metro navigation guidance comes from 5 separate areas, each of which are related but focus on separate components of application flow.
Hub and Spoke Model: The intent behind the hub and spoke model is that you have a home screen for your app that basically all other screens are navigated to in a linear fashion. That is to say, you get to each screen in your app by following a line. There are no short-circuits in your navigation structure. If you take a look at the image to the right, the main screen is the one that is green. As you can see, the correct navigation structure for the app follows the black lines to the other screens (also black). A “short circuit”, the line in red with the “x” through it, creates a loop that can confuse navigation (and even potentially break some of the Marketplace certification guidelines on back button functionality).
It’s also important to note that the structure found in the image above can be recursive in nature. What I mean by this is that one of the black screens may even be replaced with a copy of this diagram (or another hub/spoke structure), with the green screen being one of the black screens. That being said, I caution you on making navigation structure between screens as simple as possible; complexity breeds confusion and confusion creates frustration, leading the user to abandon your app’s use.
Trust the Hardware: You may have noticed that every single modern Windows Phone device (i.e.: any Windows Phone 7 or higher versioned device) has only 3 hardware buttons on the front. Yes, these devices may have various other hardware buttons on the sides of the device, but only 3 appear on its face. These 3 hardware buttons (shown on the right), are the Back button, the Home button and the Search button. Each are easy to understand – “Back” sends you to the previous screen or out of the app if you are on the app’s first screen. “Home” sends you to the home screen of the phone, regardless of what screen you’re on at that point in time. “Search” invokes the bing search app, regardless of where in your current app you’re in.
The reason this is important is because the first two buttons in particular provide a consistent understanding of navigation to the user regardless of which app he/she is using. You must adhere to their functionality in order for your app to pass certification. In other words, do not create your own soft key back buttons or soft key home buttons. Use the hardware for the purpose that it has been built for.
Avoid Traps, Loops and Phantom Pages: As I stated before, each of these guidance areas are separate but related. This area of guidance actually is a sum of the two points above. Traps are described as getting to a screen without a natural way to get out. You can fix this by implementing the back button functionality in your app properly. Loops refer to avoiding short circuits (the red line and x in the Hub and Spoke Model diagram) that may create loops in your navigation. Phantom pages refers to making sure that there is actually a natural way to get to every screen in your app. If there isn’t a natural way to get to that page, it is extraneous and should be removed. It also refers to pages with little-to-no purpose. In reviewing the content of each of your screens, ask yourself if the content is better served as part of another screen, thereby eliminating that phantom page altogether (and reducing complexity in the process.
Be Predictable: Try to make your application flow predictable enough that your user can anticipate what the next screen will be. Conversely, make your app easy to understand with the back button. If you have to press the back button of your app more than 4 or 5 times to get to the main screen of your app, your app is likely too complex or the flow of the app could be better architected. Also, always implement the hardware back button functionality properly in your app; as discussed above in “Trust the Hardware”, the back button is how you should get to the previous screen if no action is taken on the current screen.
Being predictable also refers to maintaining a consistent experience for your app even when its use is interrupted by events such as a phone call, low battery, the user pressing the Home screen or other event that causes the app to exit. Your app should exit gracefully by saving state as appropriate (including tombstoning techniques). This will increase the chances of your app being able to return the user back to the screen and state the app was left at before its interruption.
Integrated Experiences: Some of the more interesting features of Windows Phone are its hubs. Hubs are areas of the phone OS that collect common information so that the user does not have to go to multiple locations or apps on the phone to get the information or content he/she is looking for. The great thing about these hubs is that you as an application developer can integrate features of your app to make use of hubs. The reason why this is important is twofold:
- Hubs contain functionality that allows your app to use features without recreating the wheel. For example, reading information from a single contact that may come from multiple sources like Exchange, Live Mail, GMail, Facebook and LinkedIn. Your app can read this information from the People hub. Another example, like the one in the image to the right, is integrating music media into the music app (Slacker in this case).
- By integrating your app with these hubs, your application experience feels even more like an experience that is native to the phone OS itself. Studies have shown that the adoption of an application is increased when the application feels like a true extension of the operating system, as if the app was always part of the OS.
By managing the flow of your application through these points of Metro guidance, your app will feel more natural and native to Windows Phone. This in turn will create a more enjoyable and productive experience for your users while in your app!
UPDATE: Arturo Toledo has just published an in-depth view of Hub and Spoke design (and linked to this post as well!) in his 31 Weeks of Windows Phone Metro Design series (a MUST READ for any Windows Phone dev or designer). I strongly encourage you to take a look at it!
This post is the fourth in a series of posts on Metro found on this blog. The first post (“Unlocking the motivation of your mobile app user”) can be found here. The second (“My app has principles – understanding the Metro design principles”) can be found here. The third (“Isn’t “tile” just another word for “icon”? Infography vs iconography explained.”) can be found here. The fifth and final post (“Making users awesome in the moment”) can be found here.