by Jeff Gothelf
The team assumed that most CSA consumers were women who liked to cook. They spent about an hour creating a persona named Susan. But when they went out into the field to do research, they quickly learned that the overwhelming majority of cooks, and hence potential users of their app, were young men. They returned to the office and revised their persona to create Anthony.
Anthony proved to be a far more accurate target user. The team had not wasted any more time refining ideas for the wrong audience. They were now focused on an audience that, while still not perfect, was far more correct than their initial assumptions.
Persona Format
We like to sketch proto-personas on paper using three hand-drawn sections (Figure 3-9). The upper-left quadrant holds a rough sketch of the persona along with her (or his) name and role. The upper-right box holds basic demographic and behavioral information. Try to focus on information that predicts a specific type of behavior—behavior relevant to our product or service. For example, there might be cases for which the persona’s age is totally irrelevant, whereas her access to a specific device, like an iPhone, will completely change the way she interacts with your product.
Figure 3-9. The persona template
The bottom half of the proto-persona is where we put the meat of the information. Here we capture the high-level needs of the persona along with the obstacles that keep her from achieving these needs. Remember that users rarely need “features.” What they need is to attain some kind of goal. (It’s not always a concrete goal: sometimes it’s an emotional goal, an unarticulated desire, etc.) It is our job to decide how best to get them to their goals.
The Persona Creation Process
As with the other elements of the hypothesis statement, we like to start the persona creation process with a brainstorm. Team members offer up their opinions on who the project should be targeting and how that would affect their use of the product. When the brainstorming is complete, the team should narrow down the ideas to an initial set of three to four personas they believe are most likely to be their target audience. You should try to differentiate the personas around needs and roles rather than by demographic information.
After you’ve narrowed down the list of potential users, have the team complete the template for each one. Review this internally and, upon agreement, share with your colleagues beyond the team for their initial input. At this point in the process, you can begin to validate some of your early assumptions. Use your personas as recruiting targets to begin your research. Immediately, there are three things you can determine based on your proto-personas:
Does the customer exist?
By recruiting for the personas you created you can quickly determine how realistic your team’s assumptions are. If you can’t find the people you sketched, they probably don’t exist. Learn from that and edit your personas.
Do they have the needs and obstacles you think they do?
In other words, are we solving real problems? You can gauge this simply by observing and speaking with the individuals you recruit. If they don’t, you’re building solutions for problems that don’t exist—and that rarely ends well.
Would they value a solution to this problem?
Just because a customer is real and has the pain points you’re solving for, this doesn’t actually mean they’ll value a new way to solve that problem. In other words, just because they eat bananas on their cereal every day and they don’t like slicing bananas, it doesn’t mean that they’ll buy your banana slicer (Figure 3-10). It’s important to understand how your customers are currently solving these needs and how likely your idea is to displace the incumbent solution. If you’re trying to displace long-held tools like email or spreadsheets, you might be in for a tough fight. It’s good to get that information sooner rather than later.
Figure 3-10. The banana slicer
Many teams we’ve worked with and heard from over the years run this proto-persona exercise; however, far fewer of them actually go back and adjust their thinking after the initial creation exercise. It is important that you consider proto-personas to be living documents. Each time you conduct customer conversations or usability studies, ask yourself how many of the team’s current beliefs about their target audience are still true. As new information is revealed, bring it up for discussion and adjust the personas so that future research efforts can be more targeted and more successful.
Running the exercise: user outcomes
Despite the proliferation of Agile techniques like user stories, the user and their goals often become lost in the lengthy debates over features, designs, and implementations. Empathy is at the heart of great products and services. Designers often have been responsible for advocating for the user from an empathetic point of view. As we now know, this is not uniquely a designer’s responsibility. To achieve broader shared understanding of users and a deeper sense of empathy for what they are trying to achieve, we ask our teams to declare their assumptions about what users are trying to do, in the form of user outcomes.
To do that, ask your teams the following:
What is the user trying to accomplish? Example: I want to buy a new phone.
How does the user want to feel during and after this process? Example: I want to feel like I got the phone I need at a good price and that I’m keeping up technologically with my peers (i.e., I want to feel cool).
How does our product or service get the user closer to a life goal or dream? Example: I want to feel tech-savvy and respected for it.
Note that not every user outcome exists at all three levels. But thinking about outcomes in these terms can help you to find important dimensions of your solution to work on, from the functional, task-oriented outcomes to the more emotional experience-oriented outcomes.
User outcome brainstorming process: Again, sticky notes and whiteboards are our preferred tools here (see Figure 3-11). Allow individuals on the team to generate many ideas in silence and then organize those ideas with an affinity mapping exercise to drive the team toward convergence.
Figure 3-11. A team brainstorming together
Running the exercise: features
After you have a list of business outcomes in mind and have set your focus on a group of users and their needs, it’s time to begin thinking about what tactics, features, products, and services you can put in place to achieve them. This is typically the part where everyone on the team has a strong opinion—after all, features are the most concrete things we work with, so it’s often easiest for us to express our ideas in terms of features. Too often, though, our design process begins when someone has a feature idea, and we forget to investigate whether the feature will create meaningful results for the business, or for its customers and users. In Lean UX, features exist to serve the needs of the customer and the business.
Feature brainstorming process: Employing the same techniques described earlier, we like to create feature lists by brainstorming them as a team. We’re looking for features we think will help users achieve the user outcomes they seek. If the feature is just a cool idea, but not in service of a user outcome, it’s unlikely to create value. For example, if you’re trying to drive greater collaboration between users of your product and the team comes up with the idea of using a scan to match people with similar eye color into collaboration groups, that is unlikely to achieve the desired outcome and instead is simply an excuse for the team to solve for new technologies.
Have each team member write each idea, using a thick felt pen, on a sticky note. When time is up, ask everyone to post their notes to the wall. Finally, have the group arrange them into themes.
Running the exercise: assembling your feature hypotheses
With all of your raw material created, you’re ready to organize this material into a set of tactical, testable hypotheses. We like to create a table like the one in Figure 3-12 and then complete it by using the material we’ve brainstormed. If you’ve been creating all of this raw material in a workshop context, you’ll need a lot of
material on sticky notes. Physically move your notes into the appropriate boxes to make rows of related ideas.
Figure 3-12. A hypothesis table
You’ll find during this exercise that there are gaps in your initial brainstorms. Some business outcomes might have no features created for them, whereas some features might not drive any value for the customer or the business. That’s the point of this exercise: to make sense of your initial round of thinking. After you’ve identified the gaps in your brainstorms, fill them in with new sticky notes or leave the less relevant ideas off the chart, as depicted in Figure 3-13. This will help make sense of the undoubtedly large number of ideas your team generates.
Figure 3-13. Working on the hypothesis chart
After you’ve completed the chart—7 to 10 rows are a good initial target—begin extracting feature hypotheses from it. Use the hypothesis template shown in Figure 3-4 to ensure you’re including all the relevant components of the hypothesis statement.
As you write your hypotheses, consider which persona(s) you’re serving with your proposed solutions. It’s not unusual to find solutions that serve more than one at a time. It’s also not unusual to create a hypothesis in which multiple features drive similar outcomes. When you see that happening, refine the hypothesis to focus on just one feature. Hypotheses with multiple features are not easy to test. The important thing to remember in this entire process is to keep your ideas specific enough so that you can create meaningful tests to see if your ideas hold water.
What’s the Difference Between Hypotheses and Agile User Stories?
We’re often asked to differentiate between hypothesis statements and classic Agile (or Scrum) user stories. The difference is subtle but powerful. Traditional Agile user stories look like this:1
As a
I want
so that
You’ll notice that the user and user outcome are present in this story. Most teams we’ve worked with replace “some goal” with “this feature.” After the user story is written, most teams discard the pieces around “some goal” and begin implementing the feature. The user is quickly forgotten as the team works diligently to drive up their velocity and deliver the feature. The team’s acceptance criteria (i.e., their definition of success) is that the system allows the user to complete a task. There is no discussion as to whether the solution is usable or desirable, much less delightful. The only testing being done is whether the system “works as designed.”
Hypotheses have behavior change (outcomes) as their definition of success. Shipping a working feature is table stakes. It’s the beginning of the conversation. Our team’s success is not measured in how fast they can get features launched. Instead we measure success by how well our customers can achieve “some goal” initially and ongoing.
This is the key difference between user stories and hypotheses. They refocus the team on what’s really important—making the customer successful and thus achieving a business goal—as opposed to measuring team productivity as success.
Prioritizing Hypotheses
Lean UX is an exercise in ruthless prioritization. It’s rare to have a project budget focused strictly on learning. In most cases, we need to ship product at some point, as well. The reason we declare our assumptions at the outset of our work is so that we can identify project risks. After we string them together into hypotheses we create a backlog of potential work. Next, we need to figure out which ones are the riskiest ones—so that we can work on them first. Understanding that you can’t test every assumption, how do you decide which one to test first? We like to create a chart like the one presented in Figure 3-14 and use it to map out the list of hypotheses. The goal is to prioritize which hypotheses to test based on their level of risk (How bad would it be if we were wrong about this?) along with how much value we believe this idea will generate. The higher the risk and the more perceived value involved, the higher the priority is to test those hypotheses first.
This does not mean that assumptions that don’t make the first cut are gone forever. Keep a backlog of the other hypotheses you’ve created so that you can come back to them and test them if and when it makes sense to do so.
Figure 3-14. Risk Prioritization Matrix
Moving on to Design
When your list of hypotheses is complete and prioritized, you’re ready (finally!) to move on to the next step: collaborative design. If you’ve gone through this process to this point with your entire team (and we strongly recommend that you do), you’ll be in a great position to move forward together. This process is an effective way to create a shared understanding and shared mission across your entire team.
Wrapping Up
In this chapter we discussed how we can reframe our work in terms of outcomes. This is a vitally important Lean UX technique: framing our work with outcomes frees us (and our teams) to search for the best solutions to the problem at hand. We looked at the process of declaring assumptions and writing hypotheses. We begin with the project’s problem statements and then acknowledge our assumptions. We transform these assumptions into hypotheses. We learned how to write hypothesis statements that capture our intended features, audience, and goals and that are specific enough to be tested. We end up with statements that will serve as our roadmap for the next step of the Lean UX process: collaborative design.
In the next chapter, we cover what collaborative design is and how it differs from traditional product design. We discuss specific tools and techniques that empower teams to design together and we show you how designing together is the beginning of the hypothesis testing process.
1 Mountain Goat Software, “User Stories”.
Chapter 4. Collaborative Design
As you navigate through the rest of your life, be open to collaboration. Other people and other people’s ideas are often better than your own. Find a group of people who challenge and inspire you, spend a lot of time with them, and it will change your life.
—Amy Poehler
What is a “user experience”? It’s the sum total of all of the interactions a user has with your product and service. It’s created by all of the decisions that you and your team make about your product or service: the way you price it, the way you package and sell it, the way you onboard users, the way you support it and maintain it and upgrade it, and so on and so on. In other words, it’s created by a team, not an individual user interface designer. For this reason, Lean UX begins with the idea that user experience design should be a collaborative process.
Figure 4-1. The Lean UX cycle
Lean UX brings designers and nondesigners together in co-creation. It yields ideas that are bigger and better than their individual contributors. But it’s not design-by-committee. It’s a process that is orchestrated and facilitated by designers, but one that’s executed by specialists working in their individual discipline who work from a common playbook you create together. Lean UX increases your team’s ownership over the work by providing an opportunity for individual points of view to be shared much earlier in the process.
In this chapter we’ll explore the many benefits that come from this close, cross-functional collaboration. Specifically, we’ll look at the following:
Why everybody gets to design
How low-fidelity artifacts increase collaboration
Building a shared understanding across your team
We’ll also look at a set of techniques that enable this more productive way of working:
Design Studio—a collaborative sketching exercise for the entire team
Design systems and style guides—living repositories of all the customer-facing elements of your product
Collaboration techniques for geographically distributed teams
Let’s dig in...
Collaborative Design
In Chapter 3, you learned about hypotheses. To test your hypotheses, you sometimes simply conduct research (described in Chapter 6). But other times, you ne
ed to design and build something that will help you to test these hypotheses. For example, if you’re in the early stage of a project, you might test demand by creating a landing page that will measure how many customers sign up for your service. Or if you’re later in the product lifecycle, you might be working at the feature level—adding some new functionality that will make users more productive, for example. Navigating the many possible design options for these features can be difficult for teams. How often have you experienced team conflict over design choices?
The most effective way we’ve found to rally a team around a design direction is through collaboration. Over the long haul, collaboration yields better results than hero-based design (the practice of calling in a designer or design team to drop in, come up with something beautiful, and take off to rescue the next project). Teams rarely learn or get better from working with heroes. Instead, in the same way that creating hypotheses together increases the Product IQ of the team, designing together increases the Design IQ of the team. It allows all of the members of the team to articulate their ideas. It gives designers a much broader set of ideas to draw upon as they refine the design. This, in turn, increases the entire team’s feelings of ownership in the work. Finally, collaborative design builds team-wide shared understanding. It is this shared understanding that is the currency of Lean UX. The more the team collectively understands, the less it has to document in order to move forward.
