Navigating Mobile Apps – Flowchart



Part 1 of 3

Illustrations by Lana Milinovic

Illustrations by Lana Milinovic

I've seen quite a few mobile applications struggling with the navigation topic. When to use parent-child navigation, when to use modal, when to use bottom navigation, hamburger, tabs, and other options?

I could easily jump straight to the explanation, but to be able to make the right decision when designing app navigation, let’s first understand how we navigate the world.

 

Simplified Navigation Theory

In a nutshell, my differentiation starts with two navigation types based on the space. We navigate through the 3D or 2D world.

By taking a quick look from the first-person perspective in a 3D world, and when designing for AR/VR, navigation consists of x, y, and z-axis:

  • X = left, right

  • Y = up, down

  • Z = forward, backward

Disclaimer: I use the X, Y, Z axes for the above directions of movement. In some literature, you can see axes used for different directions than mine.

When looking at or designing flows in a 2D world, the navigation consists of x and y axis:

  • X = forward, backward

  • Y = up, down

3D and 2D world

3D and 2D world

Let's imagine that we are driving a car. How this would look like when you are driving in both worlds:

  • 2D driving would feel like a top-down perspective in the early days of GTA II

  • 3D driving like in the GTA III and new releases

It could also be like navigating Super Mario OG vs. Super Mario 3D World.

2D world in GTA II vs. 3D world in later versions

2D world in GTA II vs. 3D world in later versions

In this article, I will focus only on 2D world navigation in mobile apps. By looking at the Material Design guidelines, you will see the use of the 3D world to explain elevation. You need to know that too. If you are more interested in 3D world navigation, there are some nice designing tips here

Okay, now that we have a feeling of space, let's navigate further.

 

Start with the flow

Before you start choosing the right navigation pattern for your wireframes, you should be aware of the app's information architecture and know the path or the flow (the action or fact of moving along in a steady, continuous stream) of your user. You need to have a zoomed-out image of user movements across the app.

There are various forms and options on how to visualize the (user) flow. Here are my favorite diagrams and their interpretations:

  • Flowchart – zoom out

  • Task Flow – zoom in

  • User Flow – zoom in 10x

Flowchart – zoom out

Browsing online, one could find a lot of different fidelities and explanations for flowcharts. I define it as a diagram of the whole app (or part of the app if you have a really really large beast of the app). Usually, it's a complex thing and that's why I like to simplify it a bit. Rules that I follow:

  1. Every rectangle presents one screen

  2. You are not allowed to connect backward

  3. Never draw the same flow twice

When drawing a flowchart, I start by asking myself “If I tap on something on this screen where would I end up?”. In 90% of the cases, users can go back, so there is no need to draw that. If that’s not the case, you’ll describe that in later stages. If the part of the flow repeats, write the name of the first screen in a rectangle and add an arrow (→) that means the flow is already created before. This way you reduce complexity. In addition, always have a legend with explanations so that everyone can understand it.

By looking at the structure, you can see how complex it is for a user to finish a task. At this point, you already can see if you need to cut some steps. A flowchart is never done, so don’t try to perfect it.

Flowchart of the whole app (the simple example)

Flowchart of the whole app (the simple example)

Task flow – zoom in

Task flow is usually described as a single flow completed similarly by all users. And it's a good definition. I usually use them as a starting point in drawing the happy flow (with the least amount of friction, no branching, no actions, just screens) for one user and then check if it's the same for others. When it's not the same, then make a separate one. 

Creating a happy flow shows us which screens are needed if everything works perfectly. Then from this point, zoom into the details and understand actions with the User Flow.

Happy path for a single flow also known as the task flow

Happy path for a single flow also known as the task flow

User flow – zoom in 10x

This flow type helps you to stretch your thinking and ask yourself "What else could happen?". Take a happy path (task flow) and branch out to all possible cases and decisions. Go into details and document all the things (include your cross-functional team for the best results).

Be aware all the time that your user flow is a part of the whole app. That's why it is good to have an app flowchart overview close to you.

All possible cases visible in the user flow

All possible cases visible in the user flow

The creation process is never linear. Sometimes I start with the task flow and then connect it to a bigger flowchart, sometimes it’s the user flow workshop and then we simplify it to the task flow and so on. After having flowcharts, the next step would be to draw wireflows – also known as wireframe flow where you need to decide on navigation interactions.

By visualizing all the flow types, you can understand the information architecture and feel user movement in your app. This will enable you to make the right decisions on how navigation should behave. Before you jump into wireflows, let’s see in the next chapter, what kind of navigation types you can use.

 

Previous
Previous

Navigating Mobile Apps – Patterns

Next
Next

Contextualizing N26 Colors