Chapter 5
Create, Discover, Analyze
Abstract
When viewed through the lens of a design thinking cycle, PrD differs from other forms of user-centered design in its starting position. Rather than beginning user engagement with a discovery process teams begin in the concept phase crafting an artifact. Only after having an artifact in hand do teams engage with users to discover the problems and challenges they face.
Keywords
build first
incrementalism
hill climbing
fidelity
Follow effective action with quiet reflection. From the quiet reflection will come even more effective action.
—Peter Drucker
Overview
As we described in Chapter 2, traditional user-centered design (UCD) treats user research as an up-front activity occurring separately from design. (We say “traditional” to emphasize that PrD is also a form of UCD.) Following Sato’s iteration of the Owens/Kumar model, traditional UCD starts in the lower left quadrant of the matrix, whereas PrD starts in the upper right (Figure 5.1).
Figure 5.1 Traditional UCD versus PrD in Sato’s Design Thinking model
Traditional UCD starts with research, with discoveries, and moves through frames and concepts and then decides upon a solution. In most traditional UCD projects, once a team has landed on a solution, it spends the remainder of the project exploring, refining, and improving on that solution. PrD starts with concepts, moves to conceiving solutions based on them, and then through discoveries and frames. Early on, these discoveries refine our concepts, causing us to craft new solutions based on the new frame of reference. Typically, several cycles through the four quadrants are required before the team lands on a desired solution. This approach reduces the likelihood of landing on a solution too early because it starts with a divergent thinking process (conceptualization).
In PrD, teams are required to begin with what could be called “iterative debunking sessions.” The team exposes its assumptions by crafting an artifact representative of them (see Chapter 15 for more). What is being created is the provocation, not necessarily a mock-up of a specific solution or product. This is a crucial point: The PrD artifact—what is created—does not have to be a representation of the solution per se. The artifact might be:
• A series of vision statements
• A rough business plan
• A representation of a product or interface.
The variety of possible artifacts is reflected in the cases:
• In The Case of Constricted Collective Conversation, the artifact was a chalkboard on a public sidewalk.
• In The Case of the PowerPoint Play, the artifact consisted of provocative statements about design.
• In The Case of the Black-Magic Batman, the artifacts were second-hand action figures.
• In The Case of the Hard-Boiled Eggs, the artifact was a carton of plastic eggs.
• In The Case of the Pushy Pillboxes and The Case of the Rx Reminder, the artifacts were in fact representations of possible solutions.
Begin at the End
No matter the form it takes, the artifact is used to represent the internal stakeholders’ assumptions and provoke a reaction from external stakeholders (users, customers, etc.). Once we’ve created it, we get the artifact in front of external stakeholders so the internal stakeholders can see, firsthand, how their assumptions were wrong. Leo has long compared this technique with a scene in Through the Looking Glass. In the story, the Unicorn comments on how Alice goes about serving cake, saying, “You don’t know how to manage Looking-glass cakes. Hand it round first, and cut it afterwards”1 (Figure 5.2).
Figure 5.2 “You don’t know how to manage Looking-glass cakes. Hand it round first, and cut it afterwards”
PrD shifts the UCD cycle by following the Unicorn’s advice. So, in the PrD cycle, things are done “backwards.” Building stuff does not wait for anything. We start by creating something (a representation of an assumption). As we learned in the last chapter, we know what we’ve created is going to fail. That’s fine. We’re failing on purpose to iteratively reveal valuable insights about our stakeholders’ problems. This is especially important when trying to innovate, when neither the problem nor the domain is understood. How well the problem is defined goes a long way to shape what happens once the team enters the solution space. The result of this work might not be a specified solution but a clear, crisp product vision. When Apple set out to build the iPod, for example, Jobs framed the problem to be solved with a single sentence: “1,000 songs in my pocket.”2
The Artifact Provokes Discovery
As soon as the artifact is built it is handed over to external stakeholders, without reservation, protectiveness, or defensiveness. We place the artifact in front of a stakeholder and give him some tasks to perform with it. Then, without leading, we prompt him to explore, play pretend, and tell stories. This moves us to discovery. Here, as the internal team engages with external stakeholders, they together co-explore ideas, propose solutions, and, in some instances, rework the artifact together. This means PrD is not only empathic, like traditional UCD, but also participatory. This broader focus lends itself extremely well to generating stakeholder “buy-in,” as the external stakeholders themselves become active participants in the vetting and development of ideas from Day One. To paraphrase the adage: It’s much easier to edit than to start from a blank slate. In this case, external stakeholders are invited to edit the team’s assumptions about the problem space by engaging with the artifact.
As long as the team is in problem space the emphasis is on the left side of Laseau’s funnel (Figure 5.3).3
Figure 5.3 While the team is in the problem space, they remain on the left side of Laseau’s funnel
The focus is on generating ideas about the problem space, not refining potential solutions (what we call “hill climbing”). Similar to Activity-Centered Design,4 PrD focuses on gaining a deep understanding of the goals and tasks of the stakeholder, not on usability and not on testing the interface to see what stakeholders’ preferences are. This comes later, in solution space, after the decision regarding what will be built has been made.
Analyze What They Mean, Not Just What We Heard
Once we’ve captured external stakeholder reactions to our assumptions, we move to analysis, in which we hope to uncover stakeholder goals and true needs. The analysis we use in PrD is similar to other qualitative social science research techniques: We review the actual words used by our external stakeholders, paying close and particular attention to their emotional reactions to our provocations and the common themes that emerge among the different Engagement Sessions (Figure 5.4). We are searching for meaning in the data. What are stakeholders actually saying? What is the true need they are expressing?
Figure 5.4 Note not just what the stakeholder says, but how she feels
As we discuss in Chapter 16, the sessions may be recorded to capture stakeholder reactions verbatim, but even if they are not recorded, Observers in the sessions should strive to capture exact utterances.
In The Case of the Business Case, for example, it was clear from several Engagement Sessions the user interface itself was not familiar to many of the targeted users. For some teams, that finding would be enough to analyze and dig into. What needs to change? What preemptive marketing needs to be done to help prepare users for this novel interface?
But the case shined a light on a more profound issue: The stakeholders were completely baffled by the business proposition itself. They expressed their confusion in terms of the interface, but a deeper examination of their concerns revealed apprehension about the business offering. We can’t rely on the superficial reactions stakeholders offer us; we must step back, preferably during the Engagement Session itself (see Chapters 14 and 16), to understand the meaning behind those reactions. We consider their comments in the context of our assumptions and our objectives. And, we very likely begin a new concept phase as a result.
We’ll scrap our idea and come up with a better one, a natural consequence of the process of reflecting, critiquing, and reworking. PrD has far greater impact while the team is exploring the problem space than after it has landed on a solution. Without this “surveying of the land” we won’t know what other hills there are that could have been climbed (Figure 5.5).
Figure 5.5 Analysis and framing during the problem space investigation lets the team identify the problems of interest
Taking the Low Road
Let’s talk about what we’re actually creating at this point. This whole process, the process of creating, discovering, and analyzing, of cycling through the quadrants of concepts, solutions, discoveries, and frames, is best done using low-investment, low-fidelity artifacts.
High-Fidelity Artifacts Look and Feel Like Finished Products
First, low-fidelity artifacts or sketches that look, well, “sketchy,” communicate exploration and send the signal there are still a lot of degrees of freedom left in the design process. Buxton5 discusses how sketches (and we would add low-fidelity artifacts) let stakeholders know the conversation is about a tentative proposal; at this point the team is noncommittal. This approach invites stakeholders to be more vocal: to suggest, explore, question, and propose. Low-fidelity artifacts therefore are more appropriate while in the problem space of a project.
High fidelity, Buxton argues, sends the message the team is already in solution space. The process is now more about resolving specific issues and refining the solution. This, he insists, is a very different exercise, more about usability improvement than idea vetting. With high-fidelity artifacts, the team telegraphs its goal is to make the best of the decided-upon direction and solution. If the team isn’t at a refinement stage, this is the wrong signal to send. External stakeholders will feel the design is already fixed, regardless of their feedback or input.
Low-Fidelity Artifacts Cost Less
Low-fidelity artifacts have another advantage: They’re often faster and cheaper to produce. (This is not, however, always the case. See Chapter 8.) In PrD, after all, speed is of the essence. In addition, since we know we’re wrong going in, we want to reduce our investment in crafting artifacts.
Risk Factors
Create, Discover, Analyze is fraught with risks, many of which we cover in detail in later chapters, but here are a few worth mentioning.
Effort
Hands down, the most frequent risk cited by newcomers to PrD is the idea of wasted effort. “How can you just embark on some wild set of ideas, knowing it’ll likely be a waste?” Depending on the speaker, the waste being alluded to varies: Researchers express concern about building stuff before we know who we’re talking to; developers express concern we’re building stuff before we know we can even deliver it.
As stated earlier, the real concern is about how much effort the team puts into these exercises. PrD works best when the team expends the least effort expressing its assumptions. Bottom line: If it feels like the team is taking too long to get in front of stakeholders, it probably is. The solution is to “just do it”; stop the hand wringing, the analysis paralysis, and the fussing over design details. Just. Get. Out. There. The goal is to get to insights with the minimum investment of time, money, and energy. The earlier and cheaper we can validly vet an idea, the better (Figure 5.6, left). As they ask in Lean UX, what’s the smallest experiment we can conduct to test our hypothesis?6
Figure 5.6 Craft an artifact with the least investment to drive the most insight
Reality, Timidity, and Incrementalism
For many teams, the true risk in the Create, Discover, Analyze principle is a failure to get outrageous. We hear it all the time from sponsors: How do we get a group of people to really “break out of the box?” How can we get the really wild ideas on the table so teams can explore the stupid, the unfeasible, the nonviable approaches with stakeholders?
We see it in nearly every Creation Session we’ve run: Some member of a team resists the principle and focuses the team’s effort on an incremental shift in a current approach, “because it’s what can be built.” To be clear, even this timid approach will produce results from our stakeholders, but it likely just delays the inevitable and, more importantly, delays the project.
By “incrementalism,” we mean starting with the status quo and changing only one aspect of it in some way that is easily envisioned. If it is a product, as in The Case of the New Case, the team may simply move pieces of the front panel around to the side. If it is a strategy, it may mean increasing gross revenue. In any case, incrementalism begins with what the team knows can be accomplished and never ventures outside that envelope.
Consider the following scenario: The team decides to go with an incremental approach and sets up interviews with stakeholders. Assuming the team has internalized the real purpose of these interviews (not to test its idea but to test its assumptions), the likely outcome of the first couple of interviews will be stakeholders declaring the idea indistinguishable from what they have today. If the sessions go well, these external stakeholders will not only denounce the approach as a waste of time but also offer up their rationales.
The sessions can be viewed as a success in only one key way: They have forced a reluctant team to face the real problem, a problem no amount of incrementalism will address. For some organizations, this alone is a major breakthrough, but we believe that gulf can be crossed during the initial Creation Session itself, accelerating the process by days or weeks.
The antidote to this risk is strong facilitation during the Creation Session. Force the teams to get wild, set up some kind of competition, and offer awards for outrageousness. In Appendix B we offer a few ways to encourage “box breaking” and get past this risk.
Missing the Point
A third risk is when teams fail to view insights through an appropriate critical lens. This happens for several reasons:
• The data don’t get collected correctly. (The chapters in Part 3 address this risk.)
• The analysis focuses on the small, not the big-picture issues.
• The “answer” is sitting right in front of us but we can’t see it.7
Focusing on the Small
In The Case of the Business Case, the team (new to PrD) was writing up its results as if they were usability tests. Although it’s true the framework for the report is very much like a usability test, the content is very different. After reading through the rough draft, we pointed out where they were focusing on the “small,” rather than profound insights. For example, in the original report, the team pointed out where users failed to understand a particular interaction with the screen, or pointed out the need for additional data. While those were certainly true, they missed the more important point: The proposal was light years ahead of stakeholders’ understandings. This single insight was worth the entire effort—the business leaders needed to know how far ahead of the curve they really were so they could adjust their road maps, marketing, and of course the experience design itself.
Regardless, after going through all of the effort to get assumptions in front of stakeholders, the risk is the team fails to hear the profound results coming back. And there are almost always profound discoveries in this process. In fact, knowing there are likely profound results in the data is one of the ways we keep ourselves on the hunt for them. If we haven’t had a profound breakthrough, either we weren’t listening or the data didn’t get captured correctly.
Hiding in Plain Sight
Often the results are obvious, so obvious the team races past them in search of a hidden jewel. Leo recalls a Participatory Design (not PrD) session he led to redesign a website for key stakeholders. After collecting pages and pages of input from the participants, he returned to the office. Taking over a conference room, he pasted up all of the sheets, grabbed a cup of coffee, and just sat back looking at what the stakeholders had done. The sheets were covered with scribbles and sticky notes—a riot of noise and color. But after several minutes of squinting his eyes, of letting his laser-beam attention go out of focus, a solution appeared out of the noise.
That one “aha!” established the conceptual design for the solution, satisfying two competing stakeholders. Prior attempts to reconcile these competing needs had failed. The solution was staring him in the face, hidden in plain sight. By paying attention to the overarching patterns, not the details, Leo was able to see the real problem (and ultimately the solution) emerge.
Diminished Value
One risk, while unlikely, has potentially high impact on the team’s credibility with its sponsors: The team “discovers” an already well-known problem. Here’s how this plays out: The team goes through the artifact creation process, sets up stakeholder engagements, and returns a major discovery of “the problem.” Sadly, when it reports out its discovery, other members of the organization discount the discovery as something that’s been well known for a long time. The only saving grace here is at least the team didn’t spend a lot of effort retreading old ground.
There are a couple of antidotes to this risk. The first is to make sure the Creation Session is populated with the right folks—those folks who “already know what the problem is” should be in those sessions, if possible. This reduces the likelihood of viewing the problem as novel. The second antidote is to place the obvious discovery in the context of all the others. PrD Engagement Sessions usually don’t return a “single” problem statement. In most cases, the team returns with too many critical issues, not just one. Reporting out a “top three” set of issues, of which the “well-known” problem is just one, lends credibility to the process in that it too found a known problem, perhaps without the team being previously aware of it.
Finally, if a particular problem (in this case a “known” problem) resonates more strongly than others, across multiple sessions, then this is a major point of validation—and validating a known problem using a different method is an important data point. Essentially, the response to the naysayers should be: “Yes, we too found this to be the key problem as well. Perhaps it’s time to do something about it. Here’s some additional information we gleaned from the stakeholders that might provide a path to a solution.”
Summary
• Traditional UCD begins with research, followed by the team moving into solution space with a design based on what was learned. In contrast, PrD couples research with creating stuff—in PrD we start with design and use it as the vehicle of discovery, all the while staying in the problem space.
• As we cycle through ideas and analyze our failures we iterate closer and closer to an optimal solution.
• Time to insight and overall cost-benefit is typically best served by focusing on low-fidelity, quick-and-dirty artifacts.
• This approach is not without risks. Mitigate them by including the right people in the initial Creation Sessions, by expert facilitation, and by looking for deeper meaning in the captured data.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.