"For those who didn't catch it, this is a steal at $250 ... especially with the cheetah statue thrown in."
Jeremy Wilt, LXA
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.
Thx for sharing – Good job
Personas and customer journey maps are great tools – both cover two important facets …
Gaining empathy and clarity on exactly what our customers go through when they interact with the application, task or service. And identifying key capacities where we can improve customers’ expectation and experience.
Improving the experience is often dictated by their emotions. So, the key is to identify the right moment and situation when the customer is feeling good, bad, anxiety, unhappy, frustrated – those are signals where an improvement must be made in order to improve the customer experience.
Perhaps this article might be helpful for one or two …
Good job on the swim lanes article.
These kinds of process maps are indeed another helpful artifact in documentation. Especially, since user/customer experiences and processes tend to span across the way an organization organizes itself internally.