Today we are going to jump into all the ins and outs of creating and using User Flows during your user experience process.
You’ll find these to be an extremely valuable tool for building out the information architecture of your site or digital product.
Let’s get right to it!
User Flows help describe the actions your user will perform to complete a specific workflow or task within your product or website.
They are typically shown in the form of diagrams, with one diagram equalling one user workflow.
For example, a user flow could detail the following user story:
“As a customer, I want to add this sweater to my cart for checkout”
User stories should be short, succinct, and not include too many workflows. You can notice in our example, we are saying FOR checkout, and not including the checkout flow. That’s because we’ve decided the checkout flow will have its own distinct workflow with a number of additional steps, so we’ll capture that on its own.
Every step is important, as it will dictate what screens and micro-interactions will be needed to successfully complete the task.
By creating the user flows as the first step, you can begin to understand how many pages, actions, and micro interactions might be needed at a task-by-task level.
Therefore it not only fleshes out the information architecture of your product, it can also be used to generate buy-in with your stakeholders so that they understand exactly how you’re building new workflows.
Presenting your diagrams (in a clean, easy to read, and paired down manner) alongside other UX documentation adds value and validation to your presentations.
Generally, you’ll create a user flow after gathering initial user information (interviews, personas) and before you get to site mapping. If you’re creating a user journey map (a separate diagram) it may be after that as well.
The difference between User Flows and User Journey Maps
Put simply, User Journey Maps are the end users holistic, full journey with a particular product, often starting from before they use it to after they are done using the product.
User Flows are much more micro in their scope – they detail each individual, detailed tasks within the product itself. Cause and effect of an action are important to note to understand all the possibilities.
The best part about User Flows is that they aren’t tool specific – you can use whatever is most comfortable for you.
Today, we’ll use Whimsical so we can get a running start.
For our project we have a persona. Jane Doe, a big online shopper, and repeat customer for our website. She’s the most typical kind of user we will have, and her workflow will capture the broadest category of customers.
Not every workflow will make sense for the general persona. User flows are meant to capture not only the happy path, but also error states, edge cases, and potential failures.
Basically, any kind of scenario you can imagine a customer running into.
First things first is to pick the workflow you’d like to represent in detail. This can come in the form of a user story. Let’s use the one from earlier:
“As a customer, I want to add this sweater to my cart for checkout”
Now, there may be no UI at this stage – just you, your research, and potentially an existing product. So really, the world is your oyster.
Keeping your project constraints in mind, what is the best way to think through this workflow, from start to finish?
OK, the user has landed on the ecommerce site. They want to buy a sweater, but they haven’t picked a specific one yet. They just know that’s what they’re looking for, and the site they want to shop from.
After the landing page, they’ll use the navigation OR the search bar to find the general category they’re looking for.
Once the customer has navigated to the sweater page, they may narrow their search further.
If they want to sort or use filters, and those features will exist for your product, it’s good to make note of them.
This is where the customer’s major action takes place. What we’re aiming for is for them to “add to cart”, so we’ve represented the action with a unique symbol. They might also take related but different actions, like bookmarking an action. It’s not the focus here, so we gave it a secondary treatment.
Typically, it’s nice to differentiate ‘positive’, ‘negative’, and secondary actions with different symbols and colors to highlight the main action being taken. ‘Positive’ in this case is adding the item to the cart – it’s additive in some way, and results in a success state.
A “negative” example would be having the user “remove item” from the cart. Or, “deleting item” from cart.
A secondary action is like “bookmark” in the image above. It doesn’t lead to a major workflow action, and just needs to be noted for documentation purposes.
Yay! The user completed the flow and the item is now in their cart, ready for check out. Is there anything else the user can do here?
We don’t want to continue the flow too far, but it’s OK to note the major actions they can take from here (which will lead to subsequent workflows). “Checkout” or “remove item from cart” are two examples.
There may be the case that your flow has a scenario that can go more than 2+ ways.
If we take our user story, we can add a new constraint. Perhaps the customer needs to be logged in in order to check out. If this is the case, it might look something like the above image.
Images or a combination of images and text are both great for user flows.
New projects with no existing UI or wireframes can do fine with just text. You might also have a workflow that doesn’t correlate to many screen changes, which might make images redundant.
You can also use iconography to break up the text without needing anything too specific.
If you have an established product that is being improved, you may have wireframes to work with to better represent your workflow. This can work great for stakeholders that need a little visualization to get the whole picture.
After you’ve created the meat of the work, including images, steps, conditionals, and connections, you’ll want to tidy up your work to make it viewer friendly.
The best case scenario is to do this from the get-go, but if you’re making a diagram for the first time, it’s OK to just get the rough idea down and touch it up later.
Style might be heavily dependent on your own projects branding and design guidelines – and that’s usually what I’d follow.
Each of my user flow diagrams has a different style to them. You can think of it as “theming”. However you’re always welcome to use the same design across your flows!
You’ve learned all the basics to start your user flows! From here, you can tailor it whichever way you prefer – the world is your oyster.
Check out these tools to help you get started. Happy designing!
