Practical Design Discovery

FOREWORD

IN WORKING WITH

many design teams and their parent organizations, I’ve probably seen a hundred different examples of failure and frustration: days of struggling with making a good decision, weeks of wrangling priorities, and months of work lost when an executive objects to the direction at the last minute.

In nearly every case, the root cause of the problem is one of two things (and sometimes both). One has to do with the organization’s underlying values, which are incredibly difficult to change. The other results from the team and the stakeholders not having an accurate, shared understanding of the problem they’re trying to solve, or of what the attributes of a good solution will be. Thankfully, the latter problem is relatively easy to fix given the right set of tools and an approach that’s sensitive to the team’s decision-making style.

Building that shared understanding is the purpose of what Dan Brown calls discovery.

If you’re new to the world of discovery for product definition and design, Dan will introduce you to a wealth of ideas and techniques for making sense—together—of what you need to accomplish. If you’re an old hand, these pages will remind you that discovery is a mindset and not just a project phase. Dan’s model and the approaches he describes will help you thoroughly frame both the problem and the solution in ways that are—as the title promises—entirely practical.

—Kim Goodwin

INTRODUCTION

NO DESIGN PROJECT

starts from scratch. We all come to projects with preexisting knowledge, biases, and assumptions. Even with a little bit of experience, we can feel confident in knowing what works and what doesn’t.

But that confidence comes with some uncertainty—an acute awareness that we don’t know everything about this particular project, this particular business, this particular audience. Our efforts can’t rest on prior experience alone. We can’t just dive into creating the final product. We have to start somewhere, building a foundation of understanding and knowledge that clarifies objectives, assumptions, and constraints.

At first glance, that foundation is an expression of the project’s goals. As a new project gets underway, you may feel confident you understand the assignment, only to discover you’re not sure where you’re going. You may find you’re not even sure why you’re there.

Peel away the layers of the foundation, and it’s more than project goals. Design begins not just with a vision of the desired outcome, but also with a statement of how we’re trying to help change the user’s world, and a characterization of our starting point. The foundation is, in short, an assertion of the problem, a possible solution, and how we plan to get there.

We’re responsible for shaping that foundation—no one can hand it to us. Finding that starting point goes by many names. Some people call it strategy or research or requirements. I’ve heard it called inception and definition and ideation. Whatever you call it, you’re learning—learning about users, about the business, about the technology. Learning revs your creative engine: you generate new ideas, you improve upon existing ideas, and you see the problem ever clearer.

I call this discovery, because it’s as much about the journey as what you find along the way. And, ultimately, it’s about uncovering information, and understanding why that information is important. Learning doesn’t follow a specific process, and the term discovery doesn’t imply a particular string of activities. It doesn’t imply that some information is more important than other information. What we learn about the target audience is important, but no more or less important than what we learn about technical infrastructure, branding guidelines, or operational constraints.

I wrote this book because I’m fascinated by these early stages of the design process. While writing, I realized something about discovery: it’s not a specific process or artifact. It’s not a phase or methodology. It’s not a school of thought or design framework.

Discovery is an attitude.

This book is about why this attitude is important to design, and how to incorporate it into your work. Whether you’re starting a new project or in the middle of one, this book gives you the tools you need to embrace the attitude—so you can define the problem, and start to solve it.

Writing this book helped me articulate three things about discovery that I knew implicitly, but aren’t always evident:

Discovery frames the problem and the solution. When you define design as problem-solving, you’re implying a separation between framing the problem and conceiving a solution. Through that distinction, you’re also assuming that discovery is focused only on understanding the problem, the first half of the equation. But I’ve come to realize that you can’t truly understand a problem until you spend some time solving it. You need to try out a few ideas to move forward, and that’s okay.

Discovery happens throughout the design process. We are constantly learning. We don’t get to a moment and say, I know everything there is to know, let the designing begin! We take new ideas and try them out. We have more questions. We mix ideas together. We have even more questions. We discard some assumptions. We test options. We see things in a new way. We validate those perspectives. In design, we’re constantly switching mindsets, from confident decision-making to curious knowledge-seeking. We plan projects to suit the business context, but those models don’t reflect this meandering path, from learning to deciding and back again.

Discovery is a mindset, not a phase. Oh, it would be nice to compartmentalize learning in a single phase. Time-boxing your efforts to acquire knowledge makes them predictable and cost-effective. But learning doesn’t work on a timetable. Your brain forms new mental connections and sees things differently on its own schedule. (Yes, often in the shower.) So, to fit into the modern workplace, we’ll concede to having a discovery phase or design sprint—but the truth is we just don’t know when the creative breakthrough will come, or when we’ll have to answer more questions.

Why This Book?

I want you to understand what makes for great discovery, and how it prepares you by providing not just a starting point, but an ending point, too. I won’t go into every research technique, every method for unearthing requirements, or every kind of brainstorming activity. There are plenty of books on those things. Instead, I wrote a book to help you tie these activities together, regardless of where or how you work. Design happens in a variety of contexts and scenarios, and it’s my responsibility to give you a toolset and vocabulary you can use in yours.

In modern web design and product development, the desire for speed sometimes overwhelms the need for learning. The purpose of this book, then, is to boost your confidence in the decisions you make. Let’s start where all complicated things start: a basic definition.

"Today, the best designs aren’t coming from a single designer who somehow produces an amazing solution. The best designs are coming from teams that work together as a unit, marching towards a commonly held vision, and always building a new understanding of the problem.

—JARED SPOOL, The Redesign of the Design Process

WHEN I STARTED

working on the web twenty years ago, no one was talking about the design process. There wasn’t a guide to help you communicate design decisions or explore different research activities. The idea of design discovery has emerged over time, taking inspiration and techniques from many other fields. Despite the industry’s best efforts, though, it is neither well understood nor well defined.

This is, in part, due to its nature. Discovery has elements of creativity and innovation. We are driven, perhaps, by the myths of innovation, stories of magic and aha! moments. But to truly understand discovery, we need to take a more practical view.

Discovery needs to work alongside business processes. We don’t have infinite amounts of time or money to explore ideas. We need to identify the problem, make connections, and deliver actionable insights and solutions as quickly as possible. The tension between the space to learn and explore and the confidence to move forward is what makes discovery interesting.

I define discovery as a set of activities that yield shared knowledge to structure and inform design decisions about a particular project.

DISCOVERY IS NOT...

I also find it helpful to think about what discovery isn’t: strategy, execution, or a single methodology.

Discovery is not strategy

Strategy is difficult to define, and no doubt many designers will see overlap between my conception of discovery and their understanding of strategy. I see strategy as addressing the problem at a high level without necessarily offering concrete direction for the product or site design. It speaks the language of business, not the language of design. It emphasizes paving a path forward, but doesn’t focus so much on understanding the problem—a hallmark of the design process.

Discovery is strategic in that it entails planning and looking forward, but it’s grounded in the design process, establishing a vision for your product that’s described concretely through architecture and style and tone and layout.

Discovery is not execution

The more interesting distinction for designers is the part of design that isn’t discovery, which I’d summarize as fleshing out the details. This is execution—elaborating, refining, and implementing the concepts established in discovery. This distinction captures the mindset shift, from learning (about the business and technology and, especially, users) to deciding (about layout and interaction and style, among other things). While execution deals with only the latter, making decisions about every nuance, discovery focuses on the former.

It’s convenient to think of discovery and execution as two distinct phases in a project (FIG 1.1). In this view, the end of discovery is the project’s bar mitzvah: a semi-arbitrary point that marks the end of the learning process. But we keep learning as we move into adulthood, and design is much the same.

FIG 1.1: While it’s convenient to think of discovery as the first third of a project, design is more nuanced in practice.

Discovery is not a methodology

Over the years, software design and methodologies have changed. Adjustments in approach are generally reactions to earlier failures and perceived demand. We dispose of methods that seem slow and monolithic because we need to fail fast. Modern design and development practices favor incremental releases, very small units of time, and decreased formality.

What we know about design and creativity, however, is that it thrives when given a chance to percolate. So, we’ve seen efforts to reconcile the needs of design and modern development practices. We may not be curing polio, modeling DNA, or inventing the printing press, but the problems we’re solving are important to someone. And they deserve our best ideas.

Discovery, as I’ve