July 14, 2014
Journey Maps and Personas as Interfaces
Personas and journey maps can be impactful tools to your UX design and development process. However, as UX professionals, we have to remember that a persona or journey map is an interface. As with any interface, we have to know the context of use and the user base in order to determine if a journey map and/or persona is the appropriate tool. If it is, we have to further understand the context of use in order for the journey map or persona to be useful, usable and desirable to its intended user base.
Personas typically provide user needs, goals, work processes, past experience and other relevant pieces of information about the users. Journey maps often augment personas and illustrate that persona’s experience at various touch points and interactions. However, typically, organizations create these without thinking of them as interfaces. They’re not a UI in a software context, but they are interfaces in that the designers, developers and other project team members must leverage them to make decisions – from key decisions at a product strategy level (i.e., what is the best technology to solve the problem? What features and functionality are appropriate?) to specifics of the fields and user flows of a given screen.
Just like with a software interface, if we’re going to craft journey maps and personas, they have to be informed by, tested with and even created with the “users,” and integrated within the organization to ensure:
• They’re providing the right information
• They can be integrated into the design and development work flow; they’re adopted
• There’s a governance strategy for the personas and journey maps
Without this understanding, personas and journey maps can fall flat, just like an interface that’s crafted without a holistic understanding of the user.
To push this a bit further, a team would be misguided to determine that a persona or journey map is the right output before understanding the context of use of this kind of tool. Before saying “we need personas,” we must articulate the problem that we’re trying to solve. Is it that the product isn’t working for the users based on the analytics and adoption data? If so, let’s take that problem on just like we would a design problem. We may start with, assessing how the product is being designed and developed: How are decisions made? Who is involved? How is the user included? Then we come up with a number of possible solutions. One solution may be a persona or a journey map, but another may be talking with a panel of users informally, performing guerilla testing internally at your organization or doing a proper “design crit.” The right solution will likely become quite clear, but don’t get attached to one, before you’ve assessed the true problem, its context, processes, and the user’s needs and goals.