The time is right for we designers to look at Discovery, that squishy, early part of the design process. Discovery isn’t new. Even in earliest days of my career in the mid-90s working for a large Internet agency, we still called that kind of work Discovery. We’ve been chewing on it ever since.
If we want to design better, more useful products, we need to stop designing solutions too early and start instead with product discovery: a process that helps us understand the problem properly so we don’t just design things better, but design better things.
Conceiving of design as “solving problems” helps us separate understanding the problem from creating a solution. This dichotomy implies that we need to have well-defined inputs and constraints and needs before we can hope to imagine the product. Solving the problem — that is, conceiving of a product design — entails applying frameworks, paradigms, and methods to those inputs to get to an output, a product that addresses those constraints and needs. I picture it like this:
van der Merwe offers great advice for understanding design problems. He suggests techniques like Five Whys or Fishbone Diagramming for identifying underlying causes, the things lurking below our observations and assumptions that constitute real needs and objectives. He also points to techniques for documenting problems, using journey maps or concept models to explain the current state and what’s wrong with it. All this is in the name of understanding what makes something important to the business and its customers.
This is van der Merwe’s three-step process for Discovery:
- Define the problem
- Envision the solution
- Prioritize and plan
This description of Discovery positions it as a linear process. This was no doubt a conceit of the short-form article, since experience shows that Discovery is far messier. But it’s also easy to characterize the process as “messy” without qualifying it. What does that really mean? Discovery is better than mere chaos. It’s chaos governed by the tension between understanding and solving a problem. What I’ve noticed, however, is that this isn’t linear: we need to try to solve a problem to understand it.
Let me say that again: Just as we can’t offer a solution without understanding the problem, so too we can’t understand a problem until we try to solve it.
This lovely catch-22 makes design interesting, to say the least. As you take steps to understand a problem, you will only appreciate its depth or complexity when you explore possible solutions.
We can’t understand a problem until we try to solve it.
Creating a possible solution gives you insight into a range of issues:
- Do you understand all the components or elements required in the solution?
- Do you understand all the dependencies between those components?
- Do you understand the relative priorities?
- Do you understand what users consider important or necessary?
- How much of the imagined product is actually relevant to the user?
- Does the vision for the product adequately capture what it can do?
- What will it take to maintain this product?
- What new forms of interaction does the product require from the organization?
- What essential features aren’t covered by the product vision?
These questions (and more) come up when you start to mould a solution. These questions are ostensibly about the product itself — features, dependencies, priorities — but ultimately about the users and the climate in which the product will live. They embody the problem. You can more clearly see these unanswered questions, more clearly pose them, once you have a model or mock-up.
On a recent project, I started designing screens the moment I had a general understanding of the assignment, in the first week of the engagement. My mindset is the important part of this example: I understood that I was designing screens that I knew were most likely wrong. I understood I was drawing pictures as a way to help me understand the problem — the underlying objectives, priorities, and constraints — better. It was liberating to design screens knowing that they were a tool for understanding rather than a first draft of a design direction. Showing them to the client, I arrived at our reviews with questions, not about the design, but about the intent.
Our objective is mutual understanding and shared knowledge.
We can escalate our understanding of Discovery by conceiving it not as linear (problem > solution > plan) but instead as a dialog. Our objective is obviously a product design, but it’s also a mutual understanding and shared knowledge.
Discovery is a process to close gaps in our knowledge by conducting research, talking through ideas, critiquing each other’s work. In short, Discovery employs design techniques build up a repository of information that drives collaborative decision-making.
And here we get the point of Discovery. Design Discovery is not the stage of design in which we finalize all the details. It gives us:
- a pool of knowledge that we can draw from to inform decisions during the detailed design process
- a product definition and vision that articulates the intent of the product, describing how the world is a better place with the product in it
- a starting point that unifies us around themes, concepts, and principles to guide decision-making
How do we get to this? Let’s look at Discovery in terms of the Tools, the Process, and the People.
Choosing the Right Activities
Design gives us tools to uncover and clarify problems, and to explore and determine a direction. What we know about the creative process is that successful creative endeavors depend on various environmental and psychological factors working in concert to achieve ideal chemistry.
Choose activities that balance these environmental and psychological factors:
- Environmental: Activities should permit accidental encounters between ideas, BUT they also should give individuals quiet space to percolate on those ideas.
- Psychological: Activities should give people opportunities to explore lots of ideas, BUT they also should fuel the creative process by subjecting those ideas to critique.
Incorporating Discovery into Your Projects
Design projects come in all shapes and sizes now. Teams are dividing their work in many different ways, chunking into phases or sprints. When you look at processes as described by van der Merwe, you might be skeptical that Discovery is for you. And it’s difficult to see how some methods, with strict timeframes and structures, can accommodate this thing I’m calling a dialog.
My hope in elevating the conversation about Discovery is that we can take it outside the confines of a particular methodology or project structure. Discovery has objectives, and doesn’t care how you accomplish them. It entails four things:
- gathering information you don’t currently have
- processing that information into context meaningful for your assignment
- exploring possible directions based on that information
- focusing those explorations to a single direction and plan of execution
Knowing that success depends on these four things, look at your constraints — time, budget, project framework — and configure your activities to meet the constraints while accomplishing these objectives. You can do it in a week, or you can do it in a quarter. The amount of time you dedicate will influence the overall scope. How much of a product can you define in a week? Maybe not the whole thing. Bite off what you can chew.
Bringing Others Along with You
It can be difficult to convince other people to adopt the Discovery “mindset.” On the surface, you’re admitting you don’t know the solution, don’t understand the problem, don’t know the right priorities, and aren’t sure about the plan, which is not a place people like to be. Ignorance is risky. But people with this attitude don’t have to play dumb. On the contrary, you’re asking people to be smart, not to be led by the first idea that pops into their head or preconceptions or the highest salary in the room.
The essential Discovery mindset has three characteristics:
- Skepticism: People participating in Discovery need to question assumptions, ensuring they’re not taking anything for granted. And if they do take assumptions for granted, it’s because they’ve actively decided to do so, for purposes of project efficiency.
- Curiosity: People need to be insatiably curious about the domain and context of their product. Curiosity entails asking a lot of questions about things that you might think you already understand. And this is where humility comes in.
- Humility: If you’re humble, you’re not afraid to ask questions that seem naive or uninformed. Discovery depends on a mindset where people hunger for more information, and avoid automatically prioritizing their own preconceptions.
Through this attitude, people can confidently shepherd their concepts through Discovery by letting the ideas themselves guide the designers.
I’m thinking a lot about design Discovery these days. Check out my O’Reilly webcast on essential collaborative behaviors for Discovery.
I’m also writing a book on Design and Product Discovery. If you’d like to be notified when that book is published, put your name on the mailing list.
If you’re working on a design or product discovery project, my company EightShapes can drive or contribute.
Of course, I’d love your thoughts on this perspective on Discovery, so add a comment here.