UX Shortcuts: Creating requirements from a workshop

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.

Persona Development

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.

During workshops, I make sure to stress that we’re just documenting assumptions about who we believe these users to be, so it’s okay to be unsure. We want to capture an approximation. It’s perfectly all right if we don’t know exactly how many children Persona A has (two? three?) as long as we know that Persona A is a parental figure and would have kids. If the group gets hung up on a fact like this, I simply write down a number and move on. I also allow these qualities to be “negotiated” — that is, if in the midst of developing Persona B, stakeholders realize that they are just too similar, I go back and negotiate numbers and traits as needed. One of the most helpful helpful tricks I’ve used to create the voice of a character is simply to ask the audience to provide quotes of what the persona might say. Instead of limiting it to one, as I would usually do when creating a persona based on interviews and research, I list as many as get called out. I also try to gauge domains of expertise and how savvy the personas are with a particular service or product the organization is offering, and if there are any translatable skills or mental models.

Although this is generally a fairly messy exercise with scribbles over a piece of butcher paper, I’ve doctored one up to show major groupings of information I gather. As a note, I try to document the quotes last as a way to summarize the information the group has gathered and to make sure we’re all on the same page.

persona journey-01

Figure 1. An extremely cleaned up and digitized version of the chicken-scratch I usually do on a piece of butcher paper.

persona journey-02

Figure 2. Categories of interest in this version of persona development.

Remember, the purpose of this first part is really just to set ourselves up for the collaborative customer journey map.

In summary:

1.  Ask participants to select two of their largest (or most urgent, etc) groups of end-users to focus on. They should know that this exercise is to create requirements based on the personas they choose to workshop.

2. Brainstorm together about major qualities of the persona: demographic details, their domains of expertise, salient facts and representative quotes.

Collaborative Customer Journey Map

A collaborative customer journey map requires a bit of prep work. Mainly, the stages of the map need to be pre-defined. If you’ve never created a customer journey map – sometimes known as an experience map – here’s an excellent primer by Big Door. The article also covers how to create the map’s stages, which is critical to this exercise. In general, however, the stages of a customer journey do not drastically differ from this:

  • Discovery: How does someone find out about a service?
  • Research: How do they compare this service to another?
  • Purchase: How do they invest (financially, emotionally) into the service?
  • Experience: What do they do within the service? How do they feel?
  • Return: What compels (or doesn’t compel) someone to develop a long-term relationship with a service?

I try to cap the number of stages at four since it can get too granular for participants; time may also be a constraint since I try to leave about ten minutes for each category (more on that in a bit) and too many categories can make for an overwhelmingly long workshop. I’ll generally set up my butcher papers across the wall like this:

Figure 3. Set up for persona experience map.

Before I ask the workshop participants to start brainstorming, I go through and explain what each stage of the journey means. If Stage 1 is “Discovery,” I first define what Discovery is: the way(s) someone might someone find out about the organization’s services. I then ask the stakeholders to write down one method of discovery per post it note and give them a concrete example: “I read about puppies in my Facebook Newsfeed.” I specifically note that if there are issues the persona might come across, or questions the personas might have in any of the stages, they should also be documented on the sticky notes.

The next step is to explain the rules of the exercise. In direct contrast with the persona development component, this portion is run silently and participants have about ten minutes per stage to produce ideas and post them. Silent collaborative exercises prevent any particular idea (or person) from overpowering another, and allows individuals to work more quickly, and in all truth, more selfishly. The onus on feature compromises should be coming from me; the stakeholder’s job is merely to provide me with what they consider their priorities. I ask participants to place their stickies on the wall once they’re complete. We do each section in succession until the wall looks somewhat like this (not really, it’s usually a mess):

persona journey-04

Figure 4: Everyone puts their comments up! Or as Beyonce says, “Post up, flawless!”

Once all the stages of one persona is completely filled out, I facilitate the team in collaboratively grouping similar ideas into categories for at least one of the stages. Although there are many ways to label the groups, I ask participants to come up with “I” statements to describe these groupings. Creating direct statements helps differentiate how someone might feel or interact with an object or service. For example: “I find coupons online,”  and “I use online coupons,” both deal with online coupons, but one is more concerned with the action of searching, while the other deals with use. In terms of creating requirements, the former tells us that we need to make coupons available online, potentially for download, saving to a personal shopping account, or even printing (!). Although these statements are up to be vetted for validation, this grouping would let us know that multiple stakeholders believe that coupons must be searchable on their site, and so would be prioritized and recommended as a feature.**

Another benefit of working with stakeholders on groupings is buy-in: they see a little bit of how this information will be processed, and to actively claim a stake in the identified patterns. Additionally, grouping reveals a bit more about the analysis and helps focus the next persona’s customer journey a little better, in case there were outstanding questions about the purpose of this exercise. Once we’ve grouped all the post-it notes for one of the stages for Persona A (generally Stage 1), I’ll run the same exercise with Persona B and do the groupings at a later time on my own. I do take time, however, to read out all the post-it notes for each stage so everyone has some understanding of what their team members are thinking.

In summary:

1. Pre-determine the stages of the customer journey map.

2. Define what each stage means for stakeholders.

3. Explain the rules of the workshop: one idea per post-it note.

4. Determine an entire persona’s journey through the post-up exercise.

5. Collaboratively Identify patterns for a persona’s stage.

6. Run exercise with second persona (or as many as you can fit within your workshop).

Synthesizing the Results

A few tips:

  • Document knowledge gaps. When I see a lot of post-it notes phrased in questions (ie: “Where can I find a place to rest?”) I immediately make a note that this is probably an area that the stakeholders don’t know very much about. Had they known what the current workarounds are, they would likely have noted it as a fact (i.e: “I couldn’t find a place to rest, so I sat on the floor.”) To acknowledge these gaps, I create a list of future research areas to explore and better understand the current state/workflows of hypothetical personas.
  • Use stakeholder interview analysis as a complement. I compare the findings from the customer journey workshop to the stakeholder interviews. For the most part, I have found them complimentary – interviews give me the chance to understand the complexities of particular categories among the stakeholders. I surface any differences between them in my final deliverables so these contrasting opinions are presented as early as possible to circumvent surprises later. Another crucial aspect of stakeholder interviews is understanding the spirit of the company being represented, and prioritizing features to support their mission.
  • Cite best practices in the field. What this sort of UX exercise allows stakeholders to do, of course, is self-design. It’s not ideal, but it happens for many reasons. When there’s no time for a full discovery process, I often spend time doing research on what I’ll be designing for. A good way to do this is comparative feature matrices and/or analysis, and by documenting observations of UX analogs in the wild.
  • Presentation. I curate both a short-form and long-form version of my recommendations: one presentation meant to complement a conversation, and an in-depth deliverable.

Due Diligence

This method of workshop and interviews is what works for me when I’m tasked with creating requirements directly from business owners. Other workshops have yielded similar results, but I really enjoy being able to reference personas and their journeys during presentations since we all have that common understanding from building that together. This workshop is a way of compensating for a constraint of resources: time, belief in the discovery process, money, etc, and it does require building out features based on assumptions and possible back-tracking for validation purposes. It also provides a foundational starting point for what business goals are, and a closer look at what stakeholders believe their audience to be, both very precious assets.

*Experience maps. Customer journey maps. Call them whatever your heart desires! Is this technically an experience map since we’re taking personas through a journey? Probably.

** Right, I don’t like always letting business goals drive feature development either, but it happens, and I was hired to do a job to the best of my ability, and this is how I make sure I’m incorporating business goals into my recommendations.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s