[ 17 ]

Succeed Fast, Succeed Often

While I still encourage industry-standard build–test–learn cycles, I do believe that the information gleaned from the Six Minds approach can get you to a successful solution faster if you start with this knowledge.

In this chapter we’ll look at the Double Diamond approach to the design process, and I’ll show you how you can use the Six Minds to narrow the range of possible options to explore and help you select the optimal designs. We’ll also look at learning while making, prototyping, and contrasting new services or products with those of your competitors.

Up to now, we’ve focused on empathizing with our audience to understand the challenge from the perspective of the individuals who are experiencing it. The time we’ve taken to analyze the data should be well worth it, helping us to more clearly articulate the problem, identify the solution we want to focus on, and inform the design process to avoid waste.

I challenge the notion of “fail fast, fail often” because I believe the Six Minds approach can reduce the number of iteration cycles needed.

Divergent Thinking, Then Convergent Thinking

Many digital product and service designers are familiar with the Double Diamond product and service creation process, roughly summarized as consisting of four phrases: Discover, Define, Develop, Deliver (Figure 17-1).

Figure 17-1

The Double Diamond design process

The Double Diamond process can appear complicated, so I want to make sure you understand how the Six Minds approach can help to focus your efforts along the way. I won’t focus on discovery stages such as linking enterprise goals to user goals because there are wonderful books on the overall discovery process that have come out recently. I’ll recommend them at the end of this chapter.

First Diamond: Discover and Define (“Designing the Right Thing”)

Within a Double Diamond framework, we first have the Discover phase, where we try to empathize with the audience and understand what the problem is. Then comes the Define stage—figuring out which of those problems we might choose to focus on.

The Six Minds work generally would be seen as fitting into the discovery process. It provides a sophisticated but efficient way of capturing more information about the customers’ cognitive processes and thinking, in addition to building empathy for their needs and problems. We are performing research revolving around understanding our customers better, creating insights, themes, and specific opportunity areas. Thinking back to the last chapter, we can use the results of our research to answer these questions:

• What appeals to our audience (what language they’re using to describe what they want and what’s drawing their attention)?
• What would enhance their lives (help them solve their problem and expand their framework of thinking about or interacting with our product or service)?
• What would awaken their passions (excite them and make them feel like they’re accomplishing something important for themselves)?

Even though most of this chapter will focus on the second diamond, I want to acknowledge that our primary research is a treasure trove in terms of helping us identify specific opportunity areas. After considering the appeal/enhance/awaken triad, you’ll probably have some insights into where opportunities exist, whether it’s helping a wedding planner with finance management or helping a custom cabinet maker with marketing. Now you’re ready to explore some of the possibilities for solutions.

Second Diamond: Develop and Deliver (“Designing Things Right”)

By the time you get to the second diamond, you have selected a customer problem that you want to solve with your product or service. Now it’s time to select the optimal design for the product or service that solves that problem.

There are a seemingly infinite number of solution routes you could take. To expedite the process of selecting the right one, you need ways to constrain the possible solution paths. The Six Minds framework is designed to dramatically reduce the product possibilities by informing your decision making. The answers to many of the questions posed in the analysis can inform design and reduce the need for design exploration. Here are a few examples:

Vision/Attention

Six Minds research can answer many questions for designers: What is the end audience looking for? What is attracting their attention? What types of words and images are they expecting? Where in the product or service might they be looking to get the information they desire? Given that understanding, the designers can determine how to use that knowledge to their advantage and whether to intentionally break from those expectations.

Wayfinding

We will also have significant evidence for designing the interaction model, including answers to questions like the following: How does our audience expect to traverse the space, including virtually (e.g., walking through an airport or navigating a phone app)? What are the ways they’re expecting to interact with the design (e.g., just clicking on something, or using a three-finger scroll, or pinching to zoom in)? What cues or breadcrumbs are they looking for to identify where they are (e.g., a hamburger icon to represent a restaurant, or different colors on a screen)? What interactions might be most helpful for them (e.g., double-tapping)?

Memory

We will also have highly relevant information about user expectations: What past experiences are helping to shape their expectations for this one? What designs might be the most compatible or best synchronized with those expectations? What past examples will they be referencing as a basis for interacting with this new product? We can help to speed acceptance and build trust in what we are building by matching some of these expectations.

Have We Stifled Innovation?

“But what about innovation?!” you may be wondering. I am not saying “Thou shalt not innovate.” There are certainly times when it’s appropriate to come up with new kinds of interactions, new ways to draw attention, new paradigms. What I’m saying is that you should first consider whether there are any ways in which you can innovate within an existing body of knowledge and save yourself a huge amount of struggle. When we work within those existing precedents, we dramatically speed acceptance. Here are some things to keep in mind:

Language

Content strategists will want to know to what extent customers are experts in an area. What language style would they find most comprehensible (e.g., would they say “the front of the brain” or “the anterior cingulate cortex”)? What language would merit their trust and be the most useful to them?

Problem solving

What do the users believe the problem to be? In reality, is there more to the problem space than they realize? How might their expectations or beliefs have to change in order to actually solve the problem? For example, I might think I just need to get a passport, but it turns out that what I really need to do is first make sure I have documentation of my citizenship and identity before I can apply. How are users expecting us to make it clear where they are in the process?

Emotion

As we help people with their problem solving, how can we do this in a way that’s consistent with their goals and even allays some of their fears? We want to first show them that we’re helping with their short-term goals. Then we want to show them that what they’re doing with our tool is consistent with those big-picture goals they have as well.

There are so many elements from the Six Minds that can help you as the designer to ideate more constructively, in a way that’s consistent with the evidence you have—which means that your concepts are more likely to be successful when they get to the testing stage. Rather than just having a wide-open, sky’s-the-limit field of ideas, you have all these clues about the direction your designs should take.

This also means you can spend more time on the overall concept, or on branding, versus debating some of the more basic interaction design.

Learning While Making: Design Thinking

Several times in this book, I’ve referenced the notion of design thinking. Popularized by the design studio IDEO, design thinking can be traced back to early ideas around how we formalize processes for creating industrial designs. The concept also has roots in some well-known psychological studies of systematic creativity and problem solving from the ’70s by the psychologist and social scientist Herbert Simon, whose research on decision making I referenced earlier.

Think of building a product like a camera that will act as a surgeon’s eyes during surgery. Obviously this is a tool you would need to design very carefully to ensure it could be manipulated precisely and bend the right ways. In working to construct a prototype, the engineers building this camera will learn a lot about things like the importance of its weight and grip. Similarly, there will be a myriad of things that you won’t find out until you start making your product. That’s why this ideation stage is literally thinking by designing.

Don’t underestimate the importance of early sketches of the interactions and service flows. Bill Buxton, one of Microsoft’s senior researchers, writes about this really well in his book Sketching User Experiences: Getting the Design Right and the Right Design. He proposes that any designer worth their salt should be able to come up with 7 to 10 ways of solving a problem in 10 minutes—not fully thought-out solutions, but quick sketches of different solutions and styles. Upon review, such sketches can help to inform which possible design directions might have merit and be worthy of further exploration.

Like Buxton, I think that really quick prototype sketching is very helpful and can show you just how divergent the solutions can be. When you review them, you can see the opportunities, challenges, and little gold nuggets in each one.

Starting with the Six Minds ensures that you approach this learning-while-making phase with some previously researched constraints and priorities in place. Rather than restraining you, these constraints will actually free you to build consensus on a possible solution space that will work best for your audience. You will be able to evaluate the prototypes through evidence-based decision making, focusing on what you’ve learned about the customer, rather than relying on the highest paid person’s opinion (HIPPO).

Next, I’ll give you one example of why it’s so important to do your research prior to going ahead and building.

Case Study: Let’s Just Build It!

I was working with a group on a design sprint. After I’d explained my process, the CEO said, “It’s great that you have these processes, but we already know what we need to build.” Generally, a team doesn’t know what they need to build at this point, or if they’re all really set on a particular direction, the reasons might not be good ones.

But the CEO wanted to jump in and get building, so we went right to the design to see what would happen.

As you see from the diagrams in Figure 17-2, their “solutions” were all over the map—the perception of the target audience and the problem to be solved varied widely between the team members. Quickly the CEO recognized that they were not aligned like he had thought. He graciously asked that we follow the systematic process after all.

I asked him and his team to quickly sketch out their solutions so I could see what it was they wanted to build (since they were on the same page and all).

Figure 17-2

Vastly different visions for a website suggests the team members are not yet aligned

Don’t Mind the Man Behind the Curtain: Prototype and Test

In the contextual inquiry, we consider where our target audience’s eyes go, how they’re interacting with our product or service, what words they’re using, what past experiences they’re referencing, what problems they think they’re going to solve, and what some of their concerns or big goals are. I believe we can be more thoughtful in our build-test/learn cycle by taking these findings into account.

For the prototype stage, we’ll go back to a lot of our Six Minds methods of contextual inquiry. We want to be watching where the eyes go with prototype 1 versus 2. We’ll be looking at how customers seem to be interacting with our product, and what that tells us about their expectations. We’ll consider the words they’re using with these particular prototypes, and whether we’re matching their level of expertise with the wording we’re using. What are their expectations about using the prototype, or about the problem they need to solve? In what ways are we contradicting or confirming those expectations? What things are making them hesitate to interact with the product? (For example, are they not sure if the transaction is secure or if adding an item to the shopping cart means they’ve purchased it?)

In the prototyping process, we’re coming full circle, and using what we learned from our empathy research early on. We’re designing a prototype, or series of prototypes, to test all or part of our solution.

Here are a few observations and suggestions for you to keep in mind:

Avoid a prototype that is too high-fidelity

I’ve noticed that when we present a high-fidelity prototype—one that looks and feels as close as possible to the end product we have in mind—our audience starts to think that this is basically a fait accompli. It’s already so shiny and polished and feels like it’s actually live, even if it’s not fully thought out yet. Something about the near-finished feel of these prototypes makes stakeholders assume it’s too late to criticize. They might say it’s pretty good, or that they wish this one little thing had been done differently, but in general it’s good to go.

That’s why I prefer to work with low-fidelity prototypes that still have a little bit of roughness around the edges. This makes the participants feel like they still have a say in the process and can influence the design and flow. Results vary with paper prototypes, so it’s important that you know going into this exercise what the ideal level of specification is for this stage.

When I’m showing low- to medium-fidelity prototypes to a customer, for example, I prefer not to use the full branded color palette, but instead stick to black and white. I’ll use a big X or hand sketch where an image would go. I’m cutting corners, but I’m doing that intentionally. Some of these rougher elements signal to the user that this is just an early concept that’s still being worked out, and their input is still valuable in terms of framing how the end product should be built. I like to call this type of prototype a “Wizard of Oz” prototype—don’t mind the man behind the curtain.

In one example of this, we were testing how we should design a search engine for a client. For this, we first wanted to understand the context of how people would be using the search engine. We didn’t have a prototype to test, so we had them use an existing search engine. We used the example of needing to find a volleyball for someone who was eight or nine years old. We found that whether the users typed in “volleyball” or “kid’s volleyball,” the same search results came up. And that was OK because we weren’t necessarily testing the precision of the search mechanism; we were testing how we should construct the search engine. We were testing how people interacted with the search, what types of results they were expecting, in what format/style, how they would want to filter those results, and generally how they would interact with the search tool. We were able to answer all of those questions without actually having a prototype to test.

Do in-situ prototyping

Now that you know I’m a fan of rough or low-fidelity prototypes, I also want to emphasize that you do still need to do your best to put people into the mode of thinking about what they will need. Going back to the contextual inquiry, I think it’s important to do prototype testing at someone’s actual place of work so they are thinking of real-world conditions.

Observe, observe, observe

This is the full-circle part. When we’re testing the prototype, we observe the Six Minds just like we did in our initial research process. Where are the users’ eyes going? How are they attempting to interact? What words are they using at this moment? What experiences are they using to frame this experience? How are we being consistent with or breaking those anticipations? Do they feel like they’re actually solving the problem that they have? Going one step further, a more subtle question: how does this show them that their initial concept of the problem may have been impoverished, and that they’re better off now that they’re using this prototype?

When we think of emotion here, it’s not very typical for an early prototype to show someone that they’re accomplishing their deepest life goals. But we can learn a lot through people’s fears at this stage. If someone has deep-seated fears, like those young ad execs buying millions of dollars in ads, we can observe through the prototype what’s stopping the users from acting, or where they’re hesitating, or what seems unclear to them.

Test with Competitors/Comparables

As you’re doing these early prototype tests, I strongly encourage you test them with live competitors if you can. One example of this was when we tested a way that academics could search for papers. In this case, we had a clickable prototype so that people could type in something, even though the search function didn’t work yet. We tested it against a Google search and another academic publishing search engine. Like with the volleyball example earlier, we wanted to test things like how we should display the search results and how we should create the search interface, in contrast with how these competitors were doing those things.

With this sort of comparable testing before you’ve built your product, you can learn a lot about new avenues to explore that will put you ahead of your competitors. Don’t be afraid to do this even if your tool is still in development. Don’t be afraid of crashing and burning in contrast to your competitors’ slickest products—or in contrast to your existing products.

I also recommend presenting several of your own prototypes. I’m pretty sure that every time we’ve shown a single prototype to users, their reaction has been positive: “It’s pretty good,” “I like it,” “Good work.” When we contrast three prototypes, however, they provide much more substantive feedback. They’re able to articulate which parts of prototype 1 they just can’t stand, versus the aspects of prototype 2 that they really like, if we could possibly combine them with this component of prototype 3.

There’s also plenty of literature backing up this approach. Comparison reveals further unmet needs or nuances in interfaces that the interviews might not have brought out, or beneficial features that none of the existing options are offering.

Concrete Recommendations

• Simulate the product and test your design direction with users (including simulating AI systems).
• Use the same methodologies described here to further test your understanding of users’ cognitive experience (e.g., vision/attention, wayfinding, language, memory/assumptions, decision making, and emotion).
• Rework failures to be more consistent with underlying cognitive systems as a way to reduce the number of failures as you build and explore the solution space.

Further Reading

Buxton, B. (2007). Sketching User Experiences: Getting the Design Right and the Right Design. San Fransisco: Morgan Kaufmann.