Research and Rivers, Design and Navigation

Photo source:

Working with user “flows” got me thinking about rivers. That must be where the term comes from anyway, right? So, the metaphor is obvious, but sometimes it’s the obvious metaphors that allow us to best understand abstract concepts. I wanted to dig deeper into this connection between user and river. That sounds ridiculous when I write it down, but bear with me.

The first question: How do rivers happen?

This is my user, Fig Stickman. I gave Fig a task: Start at this point here and go to this other point there. Fig has no map and has never been to this destination point before. I just want to see how he gets there, if he can, and what challenges he faces along the way. I’ve attached a device to Fig that allows me to track and record Fig’s entire journey — though I make sure to follow him myself and ask questions along the way, while the decisions are still fresh in Fig’s mind.

I’m not allowed to direct Fig at all. If he starts to meander toward a destination that is not in line with the task I presented, I simply sit back and continue to observe as I have done. Deviation provides us with insights we wouldn’t have obtained otherwise.

In the end, I have a map of Fig’s “flow” and some additional observations based on Fig’s answers to my questions.

Fig didn’t quite make it to the end point.

But there’s a problem.

We know that rivers don’t appear out of thin air. Their paths are forged repeatedly and over a long period of time. On its own, Fig’s path is like the rain that runs down your street one afternoon and evaporates by the next day. To see the river in the research, I need more input. And hopefully users who do achieve the end goal.

So, I find a few more people to follow through the task. Like with Fig, I record the paths and only ask questions about why they perform certain actions and their general thoughts through the process.

Data collected from all users compiled to find similarities and pain points.

Now, I have a map for each user’s path, which I can compare to find the most frequented paths. This is also where the insights from asking questions is most useful. Patterns begin to form among the data, places where the users struggled or had no trouble at all. The individual users begin to blend together and I step back to see the bigger picture — the river.

The second question: How do we navigate the river now?

This is where the real fun starts for a designer. Through this part of the process, I’ll want to consider the context in which my user will be navigating the river in the future. What devices do they use to travel through the water? What time of year is it? Are they riding the river for pleasure or business? These answers should align with the overall patterns from my initial user testing. If I realize that my target users are not in the same group as the people I tested, then I’ll need to start over or else reevaluate my intentions with this river.

As long as I have my user personas set, I can move forward in redesigning this system. Maybe I have an optimal path that I would like users to follow when accomplishing the task I’ve tested, so I’ll make note of that. I know my end users won’t always be at the starting mark when coming into the river, so I leave certain secondary flows open.

What about the paths that proved to be least useful for the user — and which I may not even want the user to go down anyway? These points are where I build dams in the river. Stop the flow of water. Block the user from coming through.

An ideal path, alternate flows, and the areas I don’t want users to go through.

And there we have it, a fairly solid looking river. The next step is of course to test the river again with new users. Over time, the river may evolve on its own as users begin to find or to suggest new alternate flows. I can find additional opportunities by making note of those places users enter the river if not from the start point.

Photo source:

But let’s organize this topic in a more concise fashion. Here are the correlations I made between rivers and research, design and navigation:

  1. The flow

The river is what your users do. You place them at the start, give them a destination, and off they go. They don’t get to see a map and they have to deal with the terrain that already exists, but otherwise they’re free to go wherever they wish. Sometimes the river will fork off into all of these streams you never imagined. Each user creates their own river, but these flows will eventually overlap.

2. Some forks are better than others

Your job as a researcher is to map out the entire river. See where your users went, which paths were easiest to navigate, which were most common, where they lead to. Notice where the rocks are, the areas where the water is too shallow. Your end users will be navigating the water with your help.

3. Context matters

Are your users flowing through the river on a boat or a raft? Are they swimming through? Do they at least have a life jacket? Make note of what tools your users employ to navigate the river. And consider outside forces, too. What’s the weather like?

4. Improve the flow

Design the best river for your user. Keep some paths if they’re useful. Build dams to block the others. Streamline the process so that your user gets where you want them to with the least amount of effort — but make it a place they want to go, too.

So, I started by thinking about user flows and ended up with nearly the whole research and design process. It fascinates me how often we can find similarities between systems that seem completely unrelated. Truthfully, this helps when working in design. The universe has already provided us with incredible material from which we can draw inspiration. All we need to do is look a little closer to find the connections.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.