Site Map, User Flow, and Flows
Quick and Easy
I noticed that it’s quite common for professionals to get a bit confused about some concepts of information architecture tools, flows, and interactions. I decided to create a quick and didactic guide about these tools. And most importantly: when, why, or at what moment should they be used?
Site Map
It helps you visualize the entire information architecture of a site. (Every site or application has one, or should have.) It originates as the visual organization of all IA. What we often see is the site growing frantically without any kind of planning, consequently not having an official Site Map, nor any kind of update either.
Important: Site Map does not indicate interactions between pages but rather the structure of all content, which pages relate to each other, and their navigation levels.
Navigation Levels
When defining the Site Map, establish navigation levels (primary, secondary, etc.). More important pages? Primary navigation. This promotes the hierarchy of information (always with reference to your User x Business). From the main information to the least visited, such as Legal pages (footer information).
In Practice
Detail of a real-life sitemap. In this product, I needed to organize the IA of a dashboard and also visualize all meeting points of the pages. This visualization contributes to the experience, indicating where interactions in the interface should be made, as well as for the Dev-team, making it clear which information should be addressed.
User Flow
User Flow shows us the steps that the user takes to achieve a defined goal. It validates these steps, making it possible to identify possible gaps in the journey.
Different from the site map: Pages are shown in the order in which the user comes into contact with them according to their goal, thus representing their decisions and system feedback.
One of the coolest things about User Flow is our first contact with the experience of our user trying to complete a task. Here you also have the possibility to map various objectives and all their possibilities.
It can be in the form of a diagram, like the image above, or evolve into a more visual prototype (low, medium, or high fidelity), both are still User Flows. The way to use it will depend on your objective at the moment. We generally use the diagram for a first validation of the flow or to test various objectives, and the prototype when we want to validate interactions directly related to the interface.
Keep in Mind:
- For which personas is this User Flow?
- Which “user story” or goals do you want to validate or document?
- Where is your user coming from? Another site, a landing page, a platform?
In Practice
Here, I validated some main user objectives. With the flows, I could clearly see some Gaps, possible decisions, and desires. At this point, it becomes much clearer which flows need to be in the prototype, their levels of detail, or which interactions we should be more concerned about.
Run Tests
I know it can be a challenge depending on your company or position to get prototypes to move on to tests and be validated with real users. But I’m here to make sure you don’t give up! Everyone only stands to gain from tests, identifying problems in their early stages (great article to prepare for convincing tests in your team: Tests Go First. Usability Testing in Design.)
Without a doubt, the best way to validate your final user flow is to test. Test even in the prototype, observing a few points:
Did your user easily achieve the objectives? What were their barriers? Could we add something or remove it? Is the mental model correct?
