3. Envision your solution.
4. Minimize and plan to identify the smallest viable solution and how you’ll build it.
1. Frame the Idea
If you really use an opportunity backlog, and really had an opportunity discussion to make your decision to begin discovery, then you’re most of the way there. Use framing discussions to kick off focused discovery.
Involve the people who’ll work together to better understand this opportunity.
Use framing discussions to set bounds for the work you’re doing. If you’re clear on why you’re building something and who it’s for, you and your team will be better able to stop discussions about solutions that don’t solve the problem you’re focusing on, or aren’t for the users you’ve targeted.
2. Understand Customers and Users
Use discussions about customers and users to gain more insight into the people your product or features are for, and how they benefit them.
Involve those who have deep user understanding, and others who need to get it.
Sketch simple personas
I like creating simple persona sketches with a small discovery team to build shared understanding of my users. A persona is an example of your target user assembled from the facts and sometimes the as‐
sumptions you have about your users. Building personas helps us look at the software through the eyes of our users. Personas are handy tools.
Four Essential Steps to Discovery | 183
I built this simple persona with a group at Mano a Mano, a nonprofit group that helps people in Bolivia by doing everything from building roads to supporting education and healthcare. Our discussion this day was about small, Internet-savvy donors—the sort of people who may not have a huge amount of money, but want what they do have to give to be used wisely. We’d expect people like Chuck to find Mano a Mano on the Web or hear about it via Twitter or Facebook.
We created this persona together as a group using flipchart paper. It’s a fast, fun activity with lots of people shouting and contributing information.
Now, if you’re an experienced UX designer who’s created personas before, you may be feeling a little sick to your stomach right now. For the rest of you reading, good personas are built from good data gath‐
ered through solid research. UX people concerned about that might be nervous about team members just shouting stuff out and scribbling it on flipchart paper. It doesn’t sound rigorous. So don’t just shout your guesses. Discuss what you know and what you’ve observed. Tell stories.
Involve people in the discussion who have firsthand experience with users. If you’ve done lots of research, bring it into the discussion with
you. Identify the details most relevant to the opportunity you’re build‐
ing and put those into the persona. Filter out the noise. When you’re done, have an honest discussion about how much of this is just a guess.
"We already have personas created. They’re beautiful documents we’ve posted on the wall." I hear that a lot. But be honest with yourself. Most people haven’t read them, have they? And half of the people who did read them did so just to poke fun at them. Maybe I’m being cynical, but I see that a lot.
Build personas together, collaboratively. Do this to build shared un‐
derstanding with the team about who’ll build the product. Do this to really consider the most relevant aspects of the persona.
Build lightweight personas together to build shared understanding and empathy within
the team.
I create simple personas for each type of user who might use the feature we’re discussing. If I’m moving fast, I may just list different types of users or roles using the software, and note a few details about them.
Remember Gary in Chapter 1? One of the piles of cards right next to Gary was exactly that—a list of users and a few bullets of relevant information about them.
Create organizational profiles or orgzonas
If you’re building a product that organizations might buy—for exam‐
ple, an accounting product—take the time to list different types of organizations and record some details about them. These are your customers—the people with cash in hand who need to get some value from your product. An organization type with some supporting details is often called an organizational profile. My friend Lane Halley first introduced me to creating example organizational profiles much like you’d create a persona. For fun, she called them orgzonas.
Map how users work today
You can go one step deeper and map the way your users work today without your product, or with your current product. If you were play‐
ing along in Chapter 5, you built a story map about the way you do things today. Doing this for the way your users work today will help your discovery team really understand the problems they’re solving.
Four Essential Steps to Discovery | 185
These photos from Duncan Brown of the Caplin Group show some‐
thing they call a narrative journey map. It’s a map that tells a story about the "now" side of the "now-and-later" model I started this book with. It doesn’t describe our great solution; it describes the way people reach their goals today—faults and all.
The body of the map contains facts, observations, pains, and joys.
When you map what you understand now, you’ll see "hot spots"—areas in the flow where there are lots of problems. You’ll also find rewards
—the joys at the end of a set of steps that make your users' efforts worthwhile. You can build valuable products by taking away pains, or magnifying joys. Use this map as a springboard for brainstorming solutions, or for validating that the solution you have in mind really does solve problems.