This is the last in a series of blog posts where we examine some of the processes and deliverables that we generate for our projects in an effort to gain some refreshing clarity into why we do them and to hopefully provide some insight to our clients.
When describing our process for a project, we often find ourselves giving clients broad timelines for steps and describing how these steps will overlap and change depending on what we begin to uncover. This is because every project is unique and the needs for each step in the process vary greatly for each client. With this, we also find that the deliverables themselves have a certain amount of flexibility.
For us, some of this flexibility came in terms of how we define a deliverable. For a while now, we’ve been providing User Flows to clients after we’ve defined their personas and goals. We found that this worked great for projects where the goals were transactional. How does a user get to a product page, search, and checkout? How do they edit their profile or change their avatar? But for many of the project we work on, specifically something like a B2B marketing site, goals are much more abstract and may not even occur in the context of the site.
For instances like these, we’ve taken to using what we refer to as a User Journey. Now, doing any amount of searching will show that the terms User Journey and User Flow are nearly synonymous. However, we took the liberty in differentiating them. To us, “flow” indicates a user moving in a predetermined direction. While there may be a little bit of variation in their course, they’ll get to the goal.
Journeys serve as a bridge from the abstract parts of the discovery and research process into the more concrete IA and wireframing.
But “Journeys” don’t necessarily have a predetermined beginning, middle, and end. They can be quick or they can take months of starting and stopping. They will get the user to the goal but for the user, it’s much less about following directions and more about letting them forge their own path.
But here’s the big question: why bother with a Journey to being with? If they’re not describing a discrete action, what’s the point? Trust us. The first few times we did these and presented them to clients, we got the same questions. Internally, we found them helpful to begin the conversation about how we envision users navigating the site and various marketing tools the client offers. This got us thinking more deeply about our IA, the navigation, page templates, and wireframes as we were beginning to put the personas into the context of the site. So this made sense to us, but our clients sometimes had a hard time seeing the gears that were turning in our heads.
The way that we explain it now is that these Journeys serve as a bridge from the abstract parts of the discovery and research process into the more concrete IA and wireframing. Using hypothetical Journeys, we can think about how we might expect a persona getting to their goal. This begins to shed light on what pages we might want to have, what’s contained on those pages, and how they’re organized.
We will walk the client through a Journey to help put them into the frame of mind to evaluate our decisions and to see how they’re useful both to them and to us as the designers. We’ll often leave the deck with their homework to go through each Journey and tell us if it “makes sense.” Nothing more. Could you see this persona getting to this goal through this path? Yes, great! No? What seems off to you?
We find this last part about is a hugely helpful piece of the design relationship. Since this point of the project can get a bit dry for most clients (speaking constantly of hypotheticals using language that feels foreign) having a series of actions that they can wrap their heads around and criticize is empowering. They may begin to feel they’re contributing to the project as well as starting to gain focus into what all this planning has been about for the past few weeks.