Discovery Techniques
Provoking Difficult Design Conversations
Your design is wrong until it’s not. For me, knowing things are wrong (at least at the beginning of the project) gives me comfort. The process for getting the work right is starting out wrong.
“Your first idea is wrong” embodies the experimentation mindset in modern design philosophies like LeanUX. It’s also at the heart of design discovery, which I’ve defined as a mindset focused on learning. To learn anything, we have to be wrong about it first.
Having internalized this, I realize that in discovery I must push design ideas just over the boundaries, so I can understand what right means.
In other words, I find myself making “provocative” design decisions. A design decision is provocative when you intend it to generate conversation or to challenge assumptions. These decisions take an idea to the extreme as a means for triggering conversations and zeroing-in on the right approach. Here’s how it works:
- Decide what principle or assumption to test
- Prepare an extreme version
- Write questions
- Facilitate conversation
By the way, doing provocative or extreme versions of design doesn’t mean you should deliver bad designs. Your work should still attempt to adhere to the objectives of the project, even something you’re proud of. By making a design provocative, you’re taking requirements to an unexpected–but not unreasonable–conclusion. This version should give your stakeholders pause, a chance to ask, “Is this what we meant?”
1. Decide what principle or assumption to test: Whether you’ve articulated your principles or not, you’ve perhaps identified a few at least implicitly. You’ve also got a pile of requirements or requests. You’ve also got everything you think you know about the product’s users. All of these are fodder for making provocative design decisions because you don’t really know what they mean until you see them in action.
Pick a principle or assumption that can have many interpretations, or that you feel least comfortable about. Or pick the one you think can have the greatest impact on your work. Or pick the one that’s central to what the project is about.
Example: Working on an intranet project, I heard time and again “get rid of the clutter” and “streamline the content.” People kept saying it, but I was skeptical: Perhaps the idea of this was perhaps more appealing than the implementation. I wondered how much content I could really take out.
Another example: In another project, I was designing a web application to capture sets of regulations across 50 states. Although these jurisdictions were different, they relied on the same set of concepts. I wondered just how modular we could make this system to capture rules.
Both of these instances are good examples because they start with an assumption or requirement that is essential to the product, but not well understood. In both cases, I had a pretty specific question about the assumption, too.
2. Prepare an extreme version. Take that principle or requirement or assumption and turn it up to 11 (or down to 0). You can make it provocative by focusing on that principle to the exclusion of others, or by exaggerating it to ad absurdum conclusions.
Example: For the streamlined intranet, I eliminated extraneous information and devised a layout around the least amount of content.
Another example: For the complex app for regulations, my colleague suggested using a “building blocks” approach, like the kids programming tool Scratch.
It’s these extremes that are the provocative versions. This isn’t where any of the final designs ended up, but it is where they started. These versions triggered difficult conversations, and got us thinking about what the principles or assumptions actually meant.
3. Write questions. Preparing an extreme version always produces questions. At the very least, you know your attempt is wrong, so you can ask, “Why isn’t this right?”
Example: To render the intranet home page with a streamlined layout, we used a “layer cake” approach, with each layer representing a different section of the intranet. The initial design didn’t have many of the trappings of a typical intranet home page: a weighty navigation system, a horizontal navigation menu, loads of “news” content, a list of “shortcuts” to important tools. It was pretty radical. It yielded some interesting questions:
- Are the layers in the right order? (In other words, did we get the priorities right?)
- Should some sections have a larger footprint? (In other words, did we get the relative importance right?)
- Does the sample content adequately explain the section? (What do people need to see to understand what’s there?)
4. Facilitate a conversation. When sharing it with the team, I position the provocative design as a draft, and as something designed specifically to generate conversation.
When they react confidently to a direction, whether positive or negative, I remain steadfast in my pursuit of clarity. I don’t settle for a simple answer, and instead ask them to elaborate: Why do you believe this to be wrong? What would make it better? Or conversely: What about this design resonated with you? How do you think users would respond?
In these conversations, my aim isn’t solely to get feedback on the design, but also to get input on the principles, to validate the assumptions, to elaborate on the requirements. The more clearly I can articulate the principles, the better they serve as guides for the ongoing design work.
Of course, shape this approach to suit your needs.
The real take-away here isn’t the step-by-step: I shoehorned a fluid and automatic process into a framework. This is the conclusion: you can use the ambiguity inherent to discovery to your advantage. Don’t get your designs wrong for the sake of being wrong: get your early iterations wrong in a way that answers your most burning questions.
I’ve used some version of this technique for all kinds of things: the layout of a page, the structure of a research program, the tone of the written content, the style of the photos, the breadth and depth of the navigation.
In every case, I start with an extreme version based on the limited direction I have, and use that extreme version to provoke a conversation about what what it means to be right.
My book Practical Design Discovery is out now, and you can download a sample chapter from A Book Apart. The book puts techniques like these into context, showing how an entire discovery phase comes together. If you pick up a copy, all my dreams will come true!
Need help doing discovery for your digital product? EightShapes can advise or drive projects to get you to a product definition and vision. Find out more at eightshapes.com. Please get in touch!
