Charting User Waters: How Maps and Flows Help with Usability




Dr. Brian Still

This is a guest post by

Dr. Brian Still, Director

 Usability Research Lab

 Texas Tech University. 

Doing effective discovery, or understanding just who is using your product and what they need to be successful, is always challenging. Ultimately, going into the field where they live and work is an irreplaceable method because of the realism it offers and the depth of data it returns about what they are actually doing.


However, if you just go out into the field without a clear purpose and expect to see something happen that you’ll know is significant while it happens isn’t, most of the time, going to lead to a positive outcome.

There’s just too much to see, and so very often we report back with too much data to make sense of. This, unfortunately, can lead to picking off only the most obvious observations and incorporating them into task development or even product design.

We need better focus when we’re out in the field, which is to say that we need to know why we’re going out there, and what we’re trying to find out. That doesn’t mean we want users to confirm to us what we think is right, but it does mean that if we don’t have a game plan for the observations we carry out in the field, we’re just going to see a forest, not trees.

I’m teaching a user-centered design course right now. It’s different from user evaluation because we want to make something for the users. We still need them to evaluate what we make so we can insure that we’ve built in the affordances and requirements necessary for them to do well with what we’ve designed.

But we have to make a lot of decisions early on and, in fact, we want to make a lot of decisions early on because we have something we want to produce, and we have goals, design ideas, etc. that we want to see carried through. Because of this, when we do interact with users, we have to spend a lot of energy on understanding who they are and what we want from them as part of our overall design process.

That places, therefore, a lot of emphasis for us on discovering, even before site visits in the field, critical things related to users:

·         Who are they, what do they use right now, what’s their experience, what can they handle?

·         What do competitors do, or previous products we’ve made, that works to satisfy user needs?

·         What limitations do we have in time, money, materials (web site, mobile both?) that will impact the design and use?

There are a number of methods we can employ, metrics, other data resources we can gather, that will help us answer much of this. But if we want to go into the field and watch users use our new product and then use that as feedback to improve the design, eventually transitioning into full-blown user testing, we need to try different approaches to gather knowledge about users that will tell us more clearly what goals they need and what features are required to allow them to achieve those goals.

Often we’ll brainstorm, we’ll even do card sorting, affinity diagramming, but those tend to help us as designers organize our thoughts and goals. We can do cognitive walkthrough, interviews, and surveys, but all those imply that we know who to interview or survey. What if we’re still not sure? What if we need a little more clarity about our population but lack the data and focus necessary to go into the field right away and know who to watch and what to watch for?
I want you to consider, beyond surveys and interviews, a couple of other approaches that might serve as useful stepping stones to building a better sense of key user characteristics and use requirements.

User Flow

Let’s say you can describe your user with a few defining characteristics: Bob is 14-18, attends a Catholic high school, has used St. Mary’s products before, has an affinity for electronic devices, and enough experience with information on mobile devices to know his way around the interfaces found there. That’s great, but how does Bob go about using information on the mobile interface, for example, information related to Catholic education? You’ve got enough maybe to recruit people like Bob, but you don’t have at this point enough knowledge to look for particular things as you visit Bob on-site, or you construct tasks for him to do when you test.

A User Flow chart can help with this. Pick a process, such as Bob wants to edit his profile in the application. Now the first thing you do, illustrated below, is have Bob start where he would naturally start. Understand, this isn’t where he has to start but where you expect Bob would want to start, which already helps you start to think about how the user will flow through. If your application is intuitive, it will allow Bob to flow as he expects to flow through it.

From Bob’s start you then create squares for every other page Bob would expect to encounter along the way to achieving his goal. Whenever Bob has to make a decision, surround that with a triangle.  If multiple pages are available for Bob to choose from, put those into the flow, and also indicate where, if any, files have to be accessed.

This flow can get complicated, but understand that if a complicated flow is required, you’re most likely designing an interface that will have problems. But once the flow is down, and you can create as many as you want to allow Bob to complete his goals for using the application, you then have a better sense of what Bob is doing so that when you go into the field, you’ll have the focus necessary to look for the bottlenecks, problem spots, or navigational pathways that you noted when you created your user flows.

A sample user flow:

User Journey Map

There is a great online article, http://www.uxmatters.com/mt/archives/2011/09/the-value-of-customer-journey-maps-a-ux-designers-personal-journey.php, that effectively illustrates how to perform a user journey map. Duplicating here would just be overkill. But in a nutshell, the user or customer journey map is a visual depiction of what a user needs and what steps they take to fulfill those needs as they interact with your product. Simply, you create a visual that allows for you to display, together, what the customer is trying to do, what steps they want to take to do it, and what emotions or thoughts they experience as they carry out these steps.

Now what I like about this mapping is that once you create a map, you can continue to revise and/or add to it as you gain more data about users, and it serves as a nice reference tool for prepping folks for doing site visits, or explaining how, ultimately, your testing of products, as well as your design of them, resulted in creating an experience that was successful in allowing people to take the journey they wanted. Or if not, what needs to be done to help them do that. And, as the article notes, it is a tool that resonates understandably across an organization. You can remind stakeholders of what Bob wants to do, why, and what he thinks/feels as he does it, or cannot do it. This helps compel support for product design changes, helps recruitment of Bob for testing, and, of course, helps refine at the earliest possible stages of discovery your goals for determining who Bob is and what he does. This, in the process, naturally leads to less murkiness when doing field analysis, or when creating/evaluating products.