Chapter 6
Make Assumptions Explicit
Abstract
By asking internal stakeholders to craft an artifact together, PrD shines a light on each team member’s assumptions. The process of revealing assumptions is, in and of itself, beneficial to the organization as it reduces potential misunderstanding early. But equally important to aligning internal teams around their (often hidden) assumptions, PrD asks teams to reveal assumptions to external stakeholders, enabling rich conversations with little investment.
Keywords
assumptions
implicit
explicit
reveal
expose
vet
alignment
cohesion
Your assumptions are your windows on the world. Scrub them off every once in a while, or the light won’t come in.
—Alan Alda
Overview
Our assumptions are like a building that confines us. We’re trying to learn about the world around us. We’re trying to survey the landscape, trying to map it, but we see outside only through the windows of the building in which we’re standing. Moving from window to window won’t help. To make matters more challenging, the building may be an eyesore in the landscape—a discovery we can’t make from inside. We need to exit the building and look at it from a fresh perspective. But we can’t do this by ourselves. Our assumptions confine us and they won’t fall away on their own.
We imagine a future we believe is desirable, but we see it through the lens of our assumptions. Our assumptions, built from our past experiences, knowledge, and expertise, may not address the needs of a new situation—a new strategy, new market, new customer base, or new technology.
PrD is designed to make our assumptions obvious. To continue the analogy, we self-consciously craft a “building” (an artifact, during the Creation Session) explicitly rendering the team’s assumptions, and then we plop that building into our external stakeholders’ landscape to learn their perspective of it (during the Engagement Sessions). In PrD, once we’ve created an artifact, we quickly exit it to see it as our stakeholders do. Just as when we pass by an ugly building we are compelled to comment, external stakeholders can’t help but point out where our assumptions don’t make sense.
The approach resolves the dilemma of asking ourselves (or our stakeholders) what we should do next: We set up an environment to trigger conversation and provoke thoughtful engagement. When the team creates an appropriate artifact, the Engagement Sessions result in a series of discoveries. By design, PrD generates surprises.
Their value lies in generating novel insights. As The Case of the Black-Magic Batman illustrated, only after offering action heroes to the children of the village did the research team uncover the underlying framework of their society—a crucial (and surprising) understanding to support the client’s goals. This discovery changed everything. It revealed an entire world of folk beliefs, traditional medicine, superstitions, and witchcraft, inherent to the village’s culture and way of life. This surprising result was essential to the client’s ultimate goals: Any new approach to medicine would have to accommodate an environment rife with competing folk beliefs concerning health and medicine.
Revealing Assumptions Isn’t Easy
The parable of the Pharaoh, his architect, and the pyramid offers an excellent example of how difficult it can be to reveal our assumptions. In its original form, the story argues against traditional forms of programming.1 Here we illustrate how the discipline of UX is best positioned to illuminate our assumptions.
A Pharaoh approaches his architect and says: “Build me a pyramid that will dwarf all others.”
The architect gathers his workers and begins to build the Pharaoh’s dream.
He starts with the bottom layer, and after 25 years it is finished (Figure 6.1).
The architect proceeds to the next layer, and after 15 years, it too is finished (Figure 6.2).
As the architect begins the next layer, the Pharaoh suffers a fatal illness and lies on his death bed.
“You have failed,” he whispers to the architect. “You have left me with a monstrosity.”
The Pharaoh’s son, looking at the architect’s work, is struck with a brilliant insight.
“Look,” he says, drawing on a tablet. “If you proceed this way, you will always complete a pyramid no matter what” (Figure 6.3).
In the story, Mayo-Smith argues for constructing incrementally, completing small components to build a larger system. The story is also an argument against detailed project planning:
Because large software projects have many functional components, a good way to guarantee success is to finish the design, coding, and debugging of each component before you begin the next piece. This Complete Before Continuing process … starts with an overall model and a feature list, then proceeds with small development steps.
Figure 6.1 The first layer of the Pharaoh’s pyramid
Figure 6.2 The next layer of the Pharaoh’s pyramid
Figure 6.3 An agile approach to building the Pharaoh’s pyramid
It’s a powerful argument and speaks eloquently to the beauty of agile methods. But note the clause after the ellipsis: “starts with an overall model.” And here is where many project teams are well served by their UX teammates.
Inherent in the parable is a big assumption: All parties actually know what each is talking about. We naturally assume we share a common language or, metaphorically, a common architecture of experience. Just exactly what is the “overall model” referred to by Mayo-Smith?
Consider an alternate (or extended) ending for the parable based on the UX perspective.
The son and the architect ponder this revelation when the Pharaoh, agitated by the failure, musters his strength and interrupts them.
“No, no,” he whispers. “That is not at all what I wanted.” In his trembling hand he draws a form on a slate tablet, illustrating what he meant (Figure 6.4).
How often do our customers “ask” for a pyramid, when what they want is an elephant?
This is the fundamental challenge of UX: What do our users actually mean when they say they need “a pyramid?” Of all the disciplines engaged in product development, UX is the one best trained and most experienced in getting the answer to that question. And PrD is one of the most powerful tools we can use.
Figure 6.4 What the Pharaoh meant when he asked for a pyramid
Discussing Solutions, not Assumptions
Imagine a cross-disciplinary team of developers, analysts, architects, program managers, and a product owner. It’s very early in the product life cycle—Iteration 0, Gate 0, Pre-Explore, Charter. It should be the time for ideation and divergent thinking, to look at the problem space and really get wild about the possibilities. Instead, what typically happens? Several team members propose solutions to the problem or the requirements as perceived. Instead of parking these ideas off to the side, tensions rise and, after lots of highly paid people sit around debating things in meetings, the team yields to a couple of team members who Know. What. The. Solution. Is. Maybe everyone just adopts the HiPPO (highest paid person’s opinion; Figure 6.5).
Figure 6.5 HiPPs debating their opinions about what the solution should be
In many instances, the team fails to set aside this early deep dive into solution space. Team members with other ideas are forced to “disagree and commit.”2 The team plows ahead based on what they imagine can be built. From the start, the outcome is crippled: The result isn’t defined by what stakeholders can use or need, and, worse, the team hasn’t committed to discover stakeholders’ true concerns. If that isn’t bad enough, many on the team won’t see a problem—they achieved consensus on an outcome, they crafted a plan, and they’re executing on it. The apologists in the group rationalize the approach. They suggest no one can really predict the future, so it’s best to get something out there and adjust it later, if there’s a problem. Unfortunately, all that follows is damage control (Figure 6.6).
Figure 6.6 When teams focus on solutions too early, all that follows is damage control
Released Product is No Place to Learn What Stakeholders Need
Damage control comes in many forms: marketing messaging, transition change management (market education), training to remedy poor UX, or “customer support.” Each of these activities costs money—a lot of money—and none positions the organization to execute on its true strategy: improving its position in the market or delivering on its underlying charter.
PrD offers an alternative. In PrD everyone’s ideas become concrete immediately with little argument or infighting. A liberating aspect of PrD is how easily people get on to the same page. PrD requires internal team members to get their ideas and opinions out of their heads and into the artifact, even if those ideas conflict with one another. The artifact doesn’t have to make sense; it does, however, have to represent the team’s assumptions.
Nonsensical Artifacts Generate Useful Results
This idea has been controversial—that an “impossible” artifact generates useful results. It’s more than some team members can accept. Once a team has experienced it, there’s no going back, but getting them to believe it will work beforehand requires expert facilitation (which we cover in length in the chapters that follow). Even if a proposed idea seems foolish or ridiculous, the team must find a way to express it, to articulate the idea as faithfully and truthfully as possible.
Good Assumptions are Hard to Find
Getting team members to even recognize their underlying assumptions is often a challenge. We don’t think about our assumptions very often—we simply act on them.3 Here again, an expert facilitator teases out the team’s underlying assumptions, even as the team bakes those assumptions into an artifact. This process is not familiar, but it eliminates tensions. Rather than arguing about whose assumptions make most sense, the discussion shifts to making those assumptions manifest—how to articulate them in an artifact so stakeholders can react to them. The focus is no longer on which idea is better but on getting all ideas expressed appropriately.
As described in The Case of the New Case, Leo urged a client’s development team to question their assumptions about the very charter of their program. The product manager had assumed merely changing the envelope of the product, or rearranging some of its external components, would suffice to address long-standing customer complaints. But going into a test with an incremental change would likely not provoke the reactions the product manager was hoping for: His end-users wouldn’t see much of a difference between his proposed changes and the current product. The team had gone in with the assumption the product’s form factor would remain unchanged. Leo prompted them to call out and question this assumption. What would happen if they did change the form factor? Perhaps more importantly, what if changing the form factor didn’t address the perceived customer pain points? Would a radical change in form factor provoke customers to reveal needs having nothing at all to do with form factors?
In The Case of the Transformed Treatment, entertainment expert Chris Stapleton used his work in play testing and mixed reality technologies to challenge assumptions in therapies for aphasic patients. Working with therapists, patients, and their caregivers, Chris and his team identified a radically different way of approaching therapy: challenging traditional therapy’s key operating assumption (getting language skills back) by demonstrating a different assumption (enabling storytelling). In this case, professional therapists were unable to step out of their frameworks to see how their operating assumptions might be counterproductive.
Ass.U.Me—Implicit Assumptions Make Us All Look Stupid
Make Assumptions Explicit forces the team to reflect on its own values and beliefs. It doesn’t matter whether reflection occurs during the Creation Session or with external stakeholders during the Engagement Sessions. All that matters is the team truly understands its operating assumptions and has reduced the risks associated with them.
Most projects proceed from problem to solution space without such purposeful reflection (Figure 6.7). The organization’s assumptions are baked into the outcomes without anyone realizing it. At minimum, these solutions are expensive because they fail or require significant rework. In the worst cases, the results are dangerous, leading to potential harm.4 In any event, implicit assumptions create hidden risk. Implicit assumptions include:
• What the internal team can deliver
• How the problem should be approached
• Who the external stakeholders are, including their needs, frustrations, and goals
Figure 6.7 Straight-line thinking from discovery to solution within Sato’s Design Thinking model
Without surfacing assumptions, the team risks delivering a wholly inappropriate solution. Our assumptions shape and ground our response to the problem at hand.
We Really Want to Believe
Returning to our opening analogy, what we want to do is exit the building we’re in (and the quicker the better) to see if it’s even the right building in the context of the larger landscape (the problem space). We want to avoid spending effort or money on a solution based on the wrong set of assumptions.
We naturally rationalize our work based on our underlying assumptions. But we rarely step back and question those assumptions before we get started. As The Case of the New Case shows, a team can be so enmeshed in its assumptions that either they don’t realize those assumptions exist or they are surprised they should even be questioned.
In Three-card Monte, the “mark,” or victim, goes in assuming he’s about to play a game of chance (Figure 6.8). It’s this assumption that allows him to get taken. Our external stakeholders are not trying to con us. That’s not where the analogy lies; rather, by failing to vet our assumptions we risk conning ourselves.
Figure 6.8 In Three-card Monte, the mark assumes he’s playing a fair game of chance
We Don’t Know Anybody Else’s Assumptions Either
We can’t even assume we know our team members’ assumptions. In the Creation Session we strive to get them all on the table, but we’re not always successful. In The Case of the Business Case, only after going through a full PrD cycle of Creation and Engagement Sessions did the product manager and the lead technologist reveal they were operating under radically different assumptions. Here was an example of the whole team not just being unaware of its assumptions about the problem space but also not even agreeing on assumptions for the solution space! Sometimes our assumptions are way off. The earlier we identify and assess them, the better.
For any project intending to introduce innovation into the marketplace, the team must agree on its underlying assumptions. Without that alignment and shared vision, the project faces insurmountable risks.
Risk Factors
Making assumptions explicit is tricky. It requires a huge amount of trust among the team members. If the team doesn’t start with mutual trust, the process is likely to fail (of course, many other processes are likely to fail as well). Because assumptions are often hard to detect, team members may be unaware of them. A spirit of play, an environment of trust, and excellent facilitation are necessary to tease out the team’s assumptions.
Insincerity
Insincerity or lack of authenticity is never a good quality in our professional or personal lives. It also has no place in the PrD process. Our ethics and integrity are on the hook. PrD asks people to be vulnerable, to voice their heartfelt opinions. In some cases, years of pent-up frustration are released when people are finally given permission to air their beliefs.
When we are focusing on assumptions, we must be on our best behaviors. If we are facilitating, we must adjudicate among many competing opinions, finding a way for each to be expressed in the artifact. Crafting an artifact incorporating everyone’s assumptions is an intense design problem. All the while we have to keep in mind the artifact itself is likely worthless. Designers have experience interpreting client requirements. Their job is to translate requirements into meaningful artifacts. But designers don’t have the luxury of criticizing team members’ assumptions or dismissing them as silly. The team will look to the designers to help articulate its assumptions, not be critical of them. Making assumptions explicit is an in-the-moment act, requiring complete sincerity and passionate advocacy for each team member’s point of view.
We always assume good intentions: Attendees at the Creation Session are sincerely interested in having their point of view represented. While it’s possible a team member could subvert the process by offering a completely insincere idea, PrD self-corrects: External stakeholders will react to it like anything else.
Not Getting to Yes
The second most likely risk is failure to get the team’s agreement on the artifact—a failure of getting to “Yes.” What are we supposed to do when three conflicting ideas are proposed by team members?
Again, expert facilitation and leaving our egos at the door mitigate the problem.
Rule Number 1: Everybody’s assumptions must be addressed.
Consider the following ways to accomplish Rule Number 1:
• An individual eventually decides to take her idea off the table because she sees a better expression of it coming from someone else.
• The artifact is crafted to permit multiple pathways through it, each path expressing a different idea.
• The team crafts multiple artifacts.
• Most elegantly, the team crafts a single ambiguous artifact permitting an external stakeholder to interpret it in any number of ways, including the ways the internal team believes it should be interpreted.
This last resolution offers the team an emergency exit when there are multiple beliefs (with potentially opposing consequences).
Rule Number 2: (see Rule Number 1).
Summary
• PrD reduces risk to a project by having team members reveal their assumptions early on. The team puts its cards on the table on Day One. The challenge is for team members to overcome guardedness, reluctance (at revealing ideas “too soon”), or defensiveness.
• Make Assumptions Explicit also builds team cohesion—all with little debate or infighting.
• Revealing assumptions involves the entire team in the UX research process.
• When differing opinions result in conflicts, expert facilitation is required to permit everyone’s assumptions a place in the artifact.
• Whether assumptions are truly tacit knowledge or merely fabricated rationales, the stakeholders ultimately adjudicate their value.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.