Design Discovery Wolves

Chris Detzi
Apr 14, 2010 · 7 min read
Harvey Keitel as “The Wolf” in Pulp Fiction

Let’s get down to brass tacks, gentlemen. If I was informed correctly, the clock is ticking, is that right, Jimmie?

As user experience designers, we understand the merits of engaging in a thorough, upfront review of the ‘space’ we’re designing for prior to putting pixels to paper. In fact, we’ll often insist on having time to deeply explore the business objectives, users, and environment we’re working in. In recent years, however, we’re under pressure to prove the merits of an ambiguous discovery phase. We are paid to design, after all. With budgets tight, deadlines short, and expectations high, it’s easy to relate to client anxiety with ill-defined activities that end with deliverables that aren’t tangible and actionable.

The Devolution of the Design Discovery Phase

There was a time when discovery phases were time-consuming, multi-layered endeavors. While well intentioned, we were often overambitious in this phase. We used discovery to turn over every stone with hopes of finding the silver bullet to the design problem. We poured a lot of time and money into discovery but didn’t always end up with information to help us make design decisions.

Just Show Me the Design!

The emerging answer to overwrought discovery activities has been to jump straight into design ideation to expose opportunities, ideas, and problems. We’re seeing an explosion of prototyping, pattern and component libraries, and other tools to make design quicker and more efficient. However, we must resist the temptation to jump to designing solutions without thoughtful and (often difficult) discussions about core problems, opportunities, and user needs.

The Wolf

We need techniques to capture inputs quickly and efficiently. We need to focus on essentials and understand problems quickly so that we can find solutions quickly. In other words, we need to be like the Wolf, a character from Quentin Tarantino’s Pulp Fiction gloriously played by Harvey Keitel.

The Wolf was a problem solver.

He was called upon to create order out of chaos, remove barriers, and drive rapid resolution. He scrapped irrelevant activities that obstructed his ability to get the job done quickly. In Pulp Fiction, it was to quickly eliminate any evidence of a gruesome murder. In our case, it’s about quickly establishing clear direction from unstructured and highly disparate design inputs.

Focusing Like the Wolf

Successful design starts with focusing energy in the right places. The Wolf focused on essentials to solving the problem given time and resource constraints. Sound familiar? If we were only given say, a week, to get all of our inputs, what should we focus on?

The good news is that we already have a shared conceptual understanding of essential discovery inputs. Though Peter Morville’s Information Architecture (IA) Venn-diagram is nearly ten years old, it’s relevant today to our broader practice of user experience design.

If we focused more purely on identifying problems and opportunities in each area, we can dramatically shorten discovery phases and produce more actionable outputs in the process. Let’s look at the essential questions we need to answer to design an effective solution:

Context (or Business)

  • What business problem are we trying to solve with this design effort? What’s the most important problem to ‘fix’ with this effort, and how are other problems prioritized?


  • What are the users needs and interests in this product or product category?


  • What materials are available to help us shape the product experience?

Executing Like the Wolf

How should we structure our activities and plan to answer these questions efficiently? Imagine a rapid, intense succession of activities designed to immerse ourselves in each of these areas over a period of days.

1. Capturing Business Essentials

The trick to discovering business essentials is asking the right questions of the right people. In fact, we need to drive to limit the number of conversations. But how do we do that, particularly in environments with a lot of interested stakeholders? To start:

  • Identify the right people (based upon the questions you need answered)

Why a group meeting? Not only does a group meeting capture everyone’s inputs in a single discussion, it often reveals conflicting goals and perspectives and forces discussion (and hopefully some resolution) of issues right then. Our goal is to rapidly identify the range of possible answers, the core issues, ideas, and conflicts for everyone to hear, consider, and resolve as a group. These questions are much more difficult to answer and resolve with a series of individual, fragmented discussions. And given your constraints, this is your best shot to do it move on.


We must be the leaders and strong facilitators of this activity by:

  • Sustaining focus on what needs answered and (politely) dismissing anything that’s irrelevant.


Keep it simple and lightweight. Summarize (preferably on a single page) the answers you heard in the meeting and distribute for comment and/or validation. If you did your job right, this should be a simple summation of what everyone heard (and saw!) in the meeting.

2. Capturing User Essentials

It’s vital to speak with those we design for, but this can be costly and time consuming. Involving users is often the first thing to get eliminated from a plan when working under tight deadlines and budgets. But we can and should speak with users even if only afforded a few days to do so.

The first thing we need to do, however, is lower our expectations. It’s harder to follow a rigorous protocol if given only a few days. But if the choice is speaking with some users less formally or not speaking with them at all, I’ll take less formal conversations every time.


Start by asking your client where you can find a short list of actual users you can contact. During a recent project, we used a year old customer survey where respondents indicated an interest and willingness for follow-up. This yielded a surprising number of responses and at zero cost I’ve also found folks in sales departments quick (and happy) to identify people they know whom are willing to talk. Your mission is to find a handful (six or so) of real users and spend an hour or so speaking with each of them explicitly about needs, and implicitly about motivations and behaviors that impact their use of the product. Ideally, you have another person with you to capture comments and notes as you progress. If not, record the sessions so you can reference it after the session. If you stack it right, you can schedule and facilitate these interviews in a day or two.


Again, the point is to summarize and move on. Stick with simple, succinct answers to the questions we’ve outlined. It’s also here that you should identify any potential conflicts between business and user requirements.

3. Capturing Content Essentials

At this point, we should have a good set of high-level business and user requirements. But before we can act, we need a solid understanding of the materials available to us to shape the design. But our goal here isn’t to identify and catalog every piece of content (at least not yet) but to spend a day or two surveying and auditing the landscape. Our goal should be to immerse ourselves in the content space for at least a day or two, focusing on:

  • Big buckets and types of available information.


Plan to set aside an uninterrupted day or so to completely immerse yourself in the content. Chart out a rough plan for how you’ll break up the review. For example, perhaps you spend the first few hours on the web site content, followed by a few hours with non-web based product materials that could prove useful (collateral, brochures, guides, kits, etc).


Continue with the theme of succinct answers to your core questions and highlighting only what’s relevant to the work that lies ahead. Be sure to cite all of the materials you reviewed to set proper expectations about the scale and scope of your effort.

Ready. Set. Design!

If the will, dedication, and focus is there, I can imagine starting and finishing a rapid design discovery effort in as little as a week or two. And after it’s complete, we’re moving into design equipped with a very strong set of inputs, informed by all the key people, including the product’s users.

Now of course there are plenty of ‘what-if’ scenarios and other project or political constraints to contend with. What if we’re designing for a wide range of user groups or behaviors, for example? What if the business stakeholders are unwilling to participate or worse can’t agree? What if the volume of content at our disposal is too much to assess quickly? While legitimate concerns, the theme here is to find ways to get the essential inputs you need in order to design a solution. You may (will) need to cut corners and make decisions about the importance of things along the way but the point is to change the conversation from if to have discovery to how long will discovery take. We’re problem solvers and these are just more problems for us to solve. Onward wolves!

Originally published at


A collection of stories, studies, and deep thinking from…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store