Notes on Dan Brown’s Creating Effective Discovery Documentation

(added 08/17 to uie.com’s All You Can Learn video library, link here)

What guides discovery?

Curiosity

• You’re excited to learn new things and this energy enlivens the whole team
• You always ask more questions

Skepticism

• You don’t accept assertions at face value and instead probe assumptions
• But you get practical—you illustrate your ideas with pictures/visual artifacts

Humility

• You acknowledge and embrace your lack of knowledge and naivety about the problem
• You name your limits esp when making assumptions

The discovery process

Ask questions to begin creating a shared pool of knowledge:

• Who do we want to reach w our product?
• How will our product improve their world?
• What challenges do they face?
• What’s most important to them?
• How does the process constrain us?
• What is the business’ desired outcome?

The shared pool of knowledge also contains things we’ve already learned (and hopefully lightly documented in some way!):

• We interpreted our previous observations as…
• Users told us…
• We discarded this concept because…
• We already tried doing…

There are two equally-important techniques for the discovery process:

• State the problem

and

• Set the direction

Stating the problem

3 types of assertions in stating problems:

1. Problem statements, which draw attention to the part of the world that can be improved by documenting:

• Who we’re designing for
• Why they need help
• What the need is

Great tools for creating statements include:

• Personas
• Journey maps and/or service blueprints
• Mental models

These tools help identify missing functionalities—or that we may have too many functionalities!—etc

2. Project objectives, which establish the basic constraints of the discovery effort:

• What you’ll produce
• How you’ll render it
• How many you’ll make

Great tools for creating objectives include:

• Site maps
• Business reqs

3. Contextual statements, which elaborate on the ecosystem in which the product will live, including:

• Who will use the product
• Who will maintain it
• How it fits into the business
• What content it will support
• The underlying technologies available

Great tools for creating objectives include:

• Content inventories
• User & stakeholder interviews
• Other background/comparative research

Setting a direction

Setting the direction doesn’t follow stating the problem—both techniques should be used concurrently to inform each other and arrive at a better solution

3 types of assertions in setting directions:

1. Principles, guideposts for achieving our goals, which may include:

• The org’s overall design principles
• Principles written specifically for solving our problem

2. Concepts, central frameworks or big ideas that tie the product together, which may include:

• Vision statements
• Aspirational (probably future) goals for the product
• Emotions we want the product to evoke
• Organizational principles such as:

3. Models, representations of the experience we’re designing which help evaluate our design decisions and identify questions we need to answer, which may include:

• Sketches
• Scenarios
• Wireframes
• Prototypes
• Flow charts
• Style tiles

Using the 6 assertions

Idea 1: 

• Use the assertions to identify intentions for every artifact you’re going to create
  • Creating artifacts can help us gain clarity:

• The challenge is to figure out which type of model will best clarify the task at hand

Idea 2:

• Use the 6 assertions to create a story with a central concept
  • Helps guide discussions across teams and stakeholders
  • Helps to explain and evaluate design
• Create multiple stories to probe multiple solution spaces

• You may need to reapply this process during discovery as background information and research findings come in

Discovery starter outline

Use the 6 assertions to create a plan along these lines:

Keeping it Agile

The intention of discovery is to apply the 6 assertions to articulate a problem space and to define what we want to accomplish with our project

Dan thinks discovery can follow an Agile project structure by slotting discovery phases into Agile sprints

• In my experience, getting everyone on the team (business, PMs, devs) to understand and appreciate with the early phases of discovery can be difficult
• We need to separate A) understanding the problem, from B) delivering artifacts based on understanding the problem
  • THIS is often my most frustrating challenge—getting agreement on the proper amount of time for A to be successfully completed before B starts up

About Dan (from eightshapes.com): Since 1994, Dan’s focused on digital product discovery and definition, user research, information architecture, content strategy and interaction design for content-heavy sites, complex web applications, and digital products. He’s worked on teams large and small to perfect collaboration and productivity. In 2006, Dan co-founded EightShapes with Nathan Curtis to serve clients in healthcare, education, not-for-profit and high-tech.