Shortcuts are not my favorite thing, simply because they’re often forced out of necessity. More often than not, shortcuts are taken at the expense of other highly valuable resources and result in user experience and technical debt. Yet, as much as I often find them discomforting, they’ve taught me a lot about what it’s like to work effectively under documented assumptions and iterative schedules.
I recently worked for a client that wanted us to produce features sets for their web and mobile presence after a two day working session. In order to do that, I scheduled stakeholder interviews to gather business requirements and a three hour workshop to learn more about their targeted demographic. There are plenty of books on the topic of conducting user interviews, so I won’t get into that – I will, however, highly recommend Steve Portigal’s “Interviewing Users” to folks who want to get the most out of interviews.
The workshop I held consisted of two parts: persona development, and a customer journey post-up exercise. The personas developed for this particular workshop are to help direct the customer journey map and unlike true personas, are purely hypothetical. For simplicity’s sake, I’ll refer to them as personas; in reality, they are a way to focus the workshop attendees’ attention.
Customer journey maps* are the foundation for my workshop because they come with inherent reference points in the form of customer stages. These stages provide a way for a group of people to cumulatively build an experience based on each process in the journey. Customer journey maps also provide some relief from forcing workshop participants to recall all the steps a persona needs to take in order to achieve a goal since the workshop facilitator will have already defined the stages, and all the participants need to do is fill in the steps within a stage. What we get out of the maps are documented assumptions of what stakeholders believe personas do, what they are concerned with, and any stakeholder knowledge gaps. From this exercise, we’ll be able to prioritize technical features, flesh out requirements, and recommend solutions.
Group persona development can be tricky, but I’ve found a few ways to make them more manageable. I start by asking pointed, guiding questions. Since my final goal is to produce features for a MVP, I want the features I recommend to target the most frequent guests and their most pressing needs, not edge users and alternative paths. My first task for stakeholders is to have them define groups of end-users that come to their site the most frequently. Due to time constraints – I ask them to narrow the list down to two. For the most part, I find that these bigger effort workshops take around three hours, so just be aware of how long these activities can take. It may not seem like two personas is much work, these are emotionally taxing and intensive exercises.