Use user pathways to find gaps in your architecture

pathways If you were ever walking along a sidewalk and see a dirt path through the grass, that is a user pathway. A user pathway is not necessarily the intended user flow, but the way the user wants to move through the system. Discovering user pathways is crucial to finding gaps in the design. If the user finds a pathway that is not desirable, that path should be fenced off or rerouted to get the user to the intended destination.

Pathways are best when paired with a User Persona. It is the persona that helps the architect to assess what assumptions and what goals that particular user has in mind.

Pathway was can be used for three essential purposes:

1) Gap analysis. Finding the direction that user will seek to flow through the site and discovering the assumptions the user has can help to find gaps in the design. Example 1 below show how the user is trying to get to a list of saved artist. At many steps along the way, the design is incomplete.

2) Check the math. Creating user pathways during the process (or right before) can help to discover the user assumptions as they use the system and assure that the planned user flow is correct.

3) Explaining. Often clients will get confused over a complicated user flow. Creating a pathway can help to explain the process. Often, a pathway is much easier to read and understand that a process flow chart diagram– although several may need to be created to cover the same information as a flow chart diagram.

Scenario 1: NGA

The National Gallery of Art hired us to develop designs they had done from another agency. The first step before beginning the development process was to perform a gap analysis of their designs to make sure that the designs we well architected and met standards for consistency and requirements. Analyzing on a page by page level was simple enough, but the real way to show that the user would be able to move through the site to accomplish multi-page task was to do a user pathway.

The Gallery had some fabulous personas put together by their previous agency. Their goals, as well as their back stories, were perfect to help construct different ways that their users would be assessing the site. I decided to use the persona of Henry to examine the pathway for the bookmarking mechanism. Henry was a school teacher. He had been teaching the students in the class about particular artist. He decides to take his class on a field trip to the Gallery. The pathway scenario I set up showed Henry preparing for his trip to The Gallery. In preparation he had bookmarked favorite artworks that he wanted to see. The pathway document examines how Henry returns to the site to find his bookmarked artwork to find out if the art was available to view.

As I traced the steps that Henry would make, I was able to find many gaps in the experience. Full pages were missing that would make it impossible for Henry to have a bookmarked experience. And the greatest gap happened on the first step. There was no login or identification process for the system to identify Henry, so he was not able to retrieve the bookmarks he’d previously made.

The pathways document helped to identify these gaps and allowed the gallery to fix the design.

Scenario 2: TWC

Another team that was working on a very complex checkout system for Time Warner Cable. I was asked to create pathways to show the users progress through checkout. The initial request came up because team members were getting confused about how the different user types moved between the pages. I was asked to show how the users moved through the pages and any potential path changes — for instance if a user decided to follow a package promotion, rather then continuing with their single service purchase. The biggest assumptions and complexities came from examine how a current user would go through the buy flow and retain or upgrade current services.

I chose to represent the two flows with two of the three personas. Unlike with the pathways I created for The Gallery the back story of the persona was not as important for this particular section of the website. But showing them (using them) made it clear the distinction of which customer pathways I was presenting. Isabella was to represent the new customer while Frank presented the the current. It was then easier for the team to talk about how Isabella’s experience was different from Frank’s.



The discussions that followed the pathways were interesting because the team had only talked about one main entry to the checkout process. That was from the product pages through a login form that would identify new and current customers. When I created the pathway for the current user, Frank, I had him go through a link from his account page instead. What this showed was two main things that had not been considered. First, current users may already be authenticated by the system and wouldn’t need to login again. And second, more importantly, there were purchase pathways set up in more places than just on the product pages. It opened a discussion about other places that user could be coming from including: promotions, share links, and their own bookmarks. How would the system handle these entry points? What if they were coming to the checkout process and the system no longer remember what products they had wanted? It was clear that some intertitial pages would have to be added to allow for these circumstances.

In the end, I found that persona based pathways help to both clarify use cases and to find gaps in the architecture. And this technique works whether you are evaluating a system of some one else’s design, explaining your design to a team or clients, or… simply… checking your math.

Leave a Reply

Your email address will not be published. Required fields are marked *