by Leah Buley
Average Time
4–8 hours total
• 2–4 hours to plan
• 2–4 hours for the workshop
Use When
• You have a product that feels like a loose collection of features but doesn’t stand together as a cohesive whole.
• When the team is having trouble prioritizing.
• When you don’t know what differentiates your product from its competitors.
• When you need to develop a shared vision with the team on the product’s direction and future.
Try It Out
1. State your goals.
Decide on your goals for the workshop. Are they to:
• Articulate what makes the product unique?
• Create an inspiring picture of the future of your product that can unify and motivate the team?
• Prioritize features and areas to focus on?
• Determine what your team should be focusing on now, next, and later?
2. Make a plan.
Once you have identified your goals, think about how you need to structure the workshop to achieve them. A stakeholder workshop can include a hodgepodge of different activities, depending on your needs for that particular project, team, and time. A range of activities is described further in the sections that follow.
Triads
Triads help you explore the identity of your product, starting with a simple word-listing exercise. For this activity, get the team to brainstorm a list of keywords that they would like the product to embody, as shown in Figure 5.11.
FIGURE 5.11
The first step in triads is to brainstorm words that you want to describe the product.
The second step is shown in Figure 5.12. Pick three words that you’d put together to describe the core of the product experience. Work with the group to identify combos that are interesting to them. Then, for that particular three-word combo, brainstorm related nouns, verbs, and adjectives that might go with a product built around this triad:
• Nouns help you think about actors or objects that you might have in the system.
• Verbs help you think about actions that the system should support.
• Adjectives help you think about the more fuzzy and abstract parts of the experience, like how it should feel, how it should look, and what design principles should be evident throughout.
FIGURE 5.12
Next, pick out three words that you think work well together to describe the core of the product experience.
It’s okay to reuse keywords in multiple combinations. Figure 5.13 shows another triad that is built on a different three-word combo. As you might expect, different word combos lead to different nouns, verbs, and adjectives. If you create a few different triads, you can use them to spark a conversation with the team about which direction feels more appropriate for your product.
FIGURE 5.13
Try creating a few different triads and exploring how those product experiences would be different.
For each combo, discuss what an experience that is characterized primarily by those three words would look like. Talk about what would be the most important parts of the products and how the product would function or behave. What would users use the product for, and how would they feel about it? How would it fit into their lives? Capture the conversation on flip charts or a white board. Allow at least 30 minutes for this discussion.
Elevator Pitch
An elevator pitch helps you align around a shared description of your product and what’s special about it. For this activity, you can use a template to create a succinct statement of what distinguishes your product from its competitor or comparator offerings.
To do an elevator pitch, provide copies of the template you see in Figure 5.14 and, working as a group or broken into teams, have participants fill in the template. The elevator pitch can help you understand what differentiates the offering, and hence, which features and characteristics should serve as the defining elements of the product. It can also help you prioritize by shining a light on what matters most in delivering on the core value proposition of the product.
FIGURE 5.14
A variation on the elevator pitch template from Geoffrey Moore’s Crossing the Chasm, this simplified template comes from Adaptive Path’s User Experience Intensive Training. More information on this training can be found at http://ux-intensive.com/.
Artifact from the Future
This is a technique for getting a team to think beyond specific features and functions and help them envision what impression the product will make, in its entirety, when it is complete and live in the world. An artifact from the future can take many different forms: a press release, a blog post, a newspaper article, or a customer testimonial (see Figure 5.15). The key here is to invite people on the team to create their own version of an artifact from the future.
Ask people to imagine that the future is now. The design of the product is complete, and it’s out in the world. What does the press release say? Or what does a blog post say about it? Ask people to share their artifacts to understand their vision, and then discuss what still needs to be built, what kind of personality the product will need to have, and how it will fit into their customers’ lives for this vision to be realized.
FIGURE 5.15
An example of an artifact from the future. In this case, the artifact is a made-up blog post from the website Lifehacker.
Storyboards
Storyboards are usually a tool for later in the process, once you start developing product concepts and transitioning into a detailed design. But in a strategy workshop, they can be an interesting activity to get the whole team (even stakeholders whom you might think of as too high up to be participating in detailed design) to start thinking about the user experience. Often, it’s good to do a storyboard exercise after spending some time thinking about customer needs. Then the storyboard becomes a fun, visual way to explain how an offering can address those customer needs.
The example storyboard in Figure 5.16 digs into the discovery and first-use experience. In a strategy workshop, you can break people up into teams and ask each team to make their own storyboard. You may find that people naturally dig into different aspects of the experience, which is great. That gives you more breadth in discussing options and priorities with the group. Reassure them that it doesn’t matter how it looks, and that even stick figure sketches will do.
FIGURE 5.16
An example of a storyboard.
Mood Boards
Similar to a storyboard, the mood board is a tool traditionally reserved for later in the design process. But when turned into an up-front and collaborative exercise, the mood board can get the whole team to discuss their individual visions and begin to get excited about a shared vision.
Mood boards are essentially large collages where visual inspiration is carefully assembled to represent the feeling, appearance, and impression that the finished product should make (see Figure 5.17). The mood board typically brings together colors, photos, catch phrases, and other visual stimuli to create visceral impressions that the team agrees will be the direction the product should aspire to.
FIGURE 5.17
An example of a mood board.
Like an artifact from the future, a mood board can serve as a touchstone throughout product design and development to allow the team to check back in and assess whether the product is coming together in a manner that is true to the team’s vision. As you can see in Figure 5.17, you can bring in a range of pictures for participants to choose from, or ask them to bring their own images and then work together to create a curated picture of how the experience should feel and function.
2 × 2 or Kano Model
A strategy workshop has two goals: vision and focus. When you get a team together, often all the good ideas far outpace the team’s capacity to develop them. For a team of one, it’s important to manage expectations about how many of the items on the team’s wish list can be done—and done well. T
his is important not just because teams of one are operating under resource constraints, but also because it impacts the user experience. Users almost always prefer a simple product with fewer features executed extremely well over a feature-bloated product with a lot of capabilities that are executed only marginally well. Establishing a focus helps you do this (see Figure 5.18).
FIGURE 5.18
For either a 2 × 2 or a Kano Model, step 1 is to list the features that the team believes should be included in the product.
If you generated a lot of ideas in your discussions, do a team-based prioritization using a 2 × 2 structure. A 2 × 2 can be used to plot cost versus impact, as shown in Figure 5.19.
Another alternative use of the 2 × 2 is the Kano Model, as shown in Figure 5.20. Originally developed to support the product specification process in product manufacturing, a Kano Model is a handy tool for plotting the value of features from a UX perspective. The Kano Model helps you identify three categories of product features: those that are considered “basics” (think of these as tables stakes), those that are considered “performance” attributes (you’ve got to do at least some of them to remain competitive with the market), and those that are considered “delight” attributes (people don’t expect them, but they love you for having them). Note that in the traditional use of the Kano model, you would get this feedback directly from customers or users. In this adapted approach, we’re using it as a tool for facilitating a discussion with a cross-functional team.
Both structures can be used to facilitate a useful discussion with the team on which features and capabilities should be the focus.
FIGURE 5.19
If you’re doing a 2 × 2, step 2 is to plot each feature on the cost versus impact axes. The plotting of features should be a group activity, with everyone out of their seats and talking about where they would place each feature.
FIGURE 5.20
If you’re doing a Kano Model, step 2 is to plot each of the features on axes corresponding to satisfaction and achievement.
Tips and Tricks for Strategy Workshops
• Pick and choose your methods. Certain activities are optimal for answering certain questions:
• How we’re unique: triads, elevator pitch exercise, design principles
• Our vision for the future: artifact from the future, storyboards, mood boards
• Priorities: 2 × 2 or Kano Model
• If you work remotely... A strategy workshop should be done in person and is worth making a special trip for. If your whole team is remote, see if you can arrange a time to meet in the same city and to commit to this important vision-building exercise.
If You Only Do One Thing...
The methods in this chapter cover a range of activities that you can use to get a clear understanding of project goals, opportunities for improvement, and how to go about getting started. But at its heart, this chapter is about discovering the expectations that your colleagues have for your product and giving yourself the time and space to think about your own expectations—what you really believe needs to be done to create a satisfying user experience.
So if you only have time to do one method, focus on the one that best lays bare other people’s ideas and hopes for the product: the “Listening Tour.” Even if you do nothing else, the “Listening Tour” will give you valuable background on team dynamics, and will help you discover the assumptions and conditions you’ll be working with as you set out to change and improve the user experience.
CHAPTER 6
Research Methods
METHOD 7
Learning Plan
METHOD 8
Guerilla User Research
METHOD 9
Proto-Personas
METHOD 10
Heuristic Markup
METHOD 11
Comparative Assessment
METHOD 12
Content Patterns
If You Only Do One Thing...
When you work on a product day in and day out, you can start to become too familiar with it, seeing and accepting all the pragmatic trade-offs that have been struck to make a complex thing possible. To take an uncharitable view, that perspective can make you an apologist for a product’s shortcomings. However, users have no incentive to apologize for your product. In fact, they usually have quite the opposite: a wealth of alternatives and the ever-constant option of voting with their feet. Put simply, if your product doesn’t support users in what they want or need to do, they can usually just go elsewhere.
The best way to provide experiences that satisfy users is to design with them in mind. The practices in this chapter can help you investigate what it’s like for users when they use your product. These methods enable you to learn directly and indirectly what users need, want, and experience—and then build products that are optimized toward delivering on those needs. In this chapter, we’ll look at the following methods and the questions they answer:
• Learning Plan. What do you know, what don’t you know, and how are you going to learn it?
• Guerilla User Research. What concerns are top of mind for users? How do they really behave? How are people using your product today?
• Proto-Personas. How can you think empathetically about your customers’ needs, goals, and challenges when using your product?
• Heuristic Markup. How does a user experience the product from beginning to end?
• Comparative Assessment. What are the standards and best practices that customers are likely to expect in a product like yours?
• Content Patterns. What content and capabilities do users have access to in your product, how is it structured, and what is the overall quality?
METHOD 7
Learning Plan
What do you know, what don’t you know, and how are you going to learn it?
A learning plan sounds like a formal concept, but really it’s just about taking the time to ask yourself where the gaps are in your current understanding of users’ needs and experiences, and how you can fill in that understanding. A surprisingly large number of people claim to practice user-centered design, but fail to ever actually speak with or spend time with users. Don’t be like them. One of the core tenets of a user-centered philosophy is that you respect and learn from your users’ sometimes-unpredictable lives. A learning plan is a simple tool that you can use by yourself or with a team to map out what you know and what you need to learn (see Figure 6.1).
FIGURE 6.1
If possible, make this sample learning plan glanceable. A table is a great way to format all this information into an easy-to-scan, one-page plan that you can stick up on your wall or drop into a presentation deck as needed.
Average Time
1–2 hours
• About an hour to assemble
• Ongoing discussions after that
Use When
• You’re first bringing a user-centered mindset to an organization (whether in an official or unofficial capacity).
• You first start out in a new job as a UX team of one.
• You’ve started a new project, and you need to know more about your product and your users.
Try It Out
1. Start with what you know.
Set aside 30 minutes or an hour to free-list everything you think you know about your users (see Figure 6.2). What are your working assumptions? Think about things like the following:
• What are your main segments/types of users?
• What motivates them?
• What frustrates them? What delights them?
• What features and functions are most important to them?
• What considerations are key in their purchase and reuse decisions?
• Do they use your competitor’s products? When and how?
• What other products do they use?
• How much time do they spend with your product in a year? In a month? In a week? (You may discover that the number is surprisingly low.)
• What else compete
s for their attention?
• What frustrates them about your product?
• What do they like best about your product?
• What parts of your product do they use the most? The least? What parts of the product do you want them to use the most?
• What is the main goal your audience aims to achieve, and which parts of your product/areas of your site help meet this goal?
FIGURE 6.2
Give yourself 60 minutes in a conference room and invite a few team members to simply talk through your assumptions, capturing the discussion on the whiteboard.
2. Separate certainties from assumptions.
For each assumption, indicate how confident you are in that assumption. While you do this, look for any questions that can be grouped together and simplified.
3. Brainstorm research methods.
Now, for each of your questions, brainstorm how you might go about getting more data or info in this area. Also think about what resources will be required to actually answer these questions (for example, face-to-face time with users, a Web intercept survey, access to server log data, etc.). Note that not all research questions will require direct and immediate access to customers. Some answers can be derived from tools or processes that users touch—for example, call center transcripts, search analytics, and so on. Be creative in thinking about where and how you can gather data to answer your questions.