LiRPPS: Lightweight, Research-Based Principles, Personas, and Scenarios – Part 1

Last year, I wrote about an amazing tool we’ve been using with design teams: The Magical Short-Form Creative Brief. It’s magic is revealed as it helps keep design meetings and discussions focused on revealing the insights we need to move our design forward.

We start each design meeting by reading the short-form brief out loud, to ensure everyone participating is on the same page. If we don’t agree, we have a great discussion about how the project has shifted.

The brief consists of four simple components: the objective, 1-2 personas, 1-2 scenarios, and 1-2 design principles. The objective is what we’re working on (such as, “The billing information form”). The personas describe who the users are (“Nancy, our frequent purchaser”). The scenarios are the stories that describe how the personas will use our design and why (“using a new credit card for the first time because of an identity theft issue”). And the design principles are the tests we’ll use to tell if our design is great (“Only tell us something once”).

Personas, scenarios, and design principles are reference tools for the work we’re doing. They act like razors that cut through passable designs, so we can focus on what could make the user experience great. Making them explicit helps everyone on the team understand the ‘why’ behind our decisions.

When we’re creating our brief, we know where the objective comes from. It comes from where we are in the design of our project. But, where do the personas, scenarios, and design principles come from?

Heavyweight Processes Bog Us Down

Often, when I ask a team if they have personas, scenarios, or design principles to guide their design, the reply is, “We wish.” In many cases, they tried creating personas once (often at great expense), only to find the project stalled before anything useful was produced.

Or, after hours of meetings with delegates from all parts of the organization, they’ve crafted a set of generalized design principles to apply to everything they’ve ever built. Frequently, these principles are so generic that they don’t help with anything. After all, what do principles like “Make it human” (Facebook) or “Be universal” (Google) really mean when you’re staring at a mockup of a billing information form?

Most of the time, personas are skipped because they are seen as being too heavy and expensive. After all, teams already feel strapped for time on their design work. When will they push everything aside to make generic personas and principles? Never.

The Price of Making Stuff Up

The alternative is to make these things up. Teams sit around and imagine a user, then declare her to be the persona. They imagine a scenario and they come up with some simple principles. These aren’t based on research, so nobody knows if they’re designing for the right things.

Having solid principles, personas, and scenarios helps us enforce our standard of what makes a design great. That’s hard to do when everyone knows that the razors we’re using were arbitrarily chosen. When someone suggests a design wouldn’t work for a particular persona, it’s easy to counter that with, “We made that persona up. We don’t know what they would or wouldn’t want, let alone if they even exist.”

Uncovering a Lightweight Approach

There’s a third alternative. We started experimenting with reducing the effort required to create personas, scenarios, and principles. We went a simpler route and asked, what’s the least amount of time it takes to create usable decision-making references for designers?

We got the process down to a single day. Six hours (ok, maybe seven hours) to come up with personas, scenarios, and design principles that can provide clear guidance for a team over several months.

Turns out, there was a trick to it. Our trick was conducting some solid user research beforehand. A short stint of research that we based our reference tools on.

Preparing for Customer Visits

Anyone who has tried to cook a delicious stir fry dish knows the secret is to prepare all the ingredients beforehand. Stir fry dishes cook up fast, so everything needs to be cleaned, chopped, and in place before the oil goes into the pan.

Turns out the same is true if we want a lightweight process for creating personas, scenarios, and design principles. We have to have all of our ingredients prepared in advance.

For our lightweight process, we don’t need a lot of research. We’ve found the ideal minimum is twelve half-day customer visits. With some clever scheduling, we can get these down to six days of effort. Over a three-week period, that’s two days each week.

Not everyone on the team has to go on each visit. Usually, each “away team” is three or four folks. If our entire design team (including stakeholders and influencers) is a normal size of six to ten folks, then each person will probably only go on a few visits. If we can get everyone on three or four visits, we’re doing well. Four half-day visits over three weeks to help ground the team in solid design tools for a four-month project seems quite reasonable. And two days of research isn’t a burden on any individual’s schedule.

Don’t Be Tempted To Skip the Research

“But we know our users really well. We don’t need to spend the time visiting them.” Yeah, um, no. It’s so tempting to think we know our users. After all, we see their feature request emails and our sales people are always talking to them.

Occasionally reading an email or hearing about some desired feature second hand is not the same as understanding what problems they’re solving and how they work. Visiting a customer’s home or office, seeing what they do with the product today (or how they get by without it), and understanding the complete context of use is an eye-opening experience.

This is especially true for critical stakeholders and influencers. You know these folks. They’re the ones who do that seagull maneuver, where they swoop into your project and poop all over your design ideas. They need to have direct exposure to the customers and to see the environment the design is to be used. It will change their swoop-and-poop behavior completely.

LiRPPS Prep: The User Write-ups

Across our visits to the twelve customer sites, we’ve probably bumped into a total of sixteen or so users. As we visit each one, we write up a two-page summary of what we need to remember. Often, we’ll include a couple pictures of the person and their environments. (That’s assuming they’ve given us permission, of course. Most of the time they do.)

This is critical because it’s hard to keep sixteen people straight. We need to know what they were trying to do, how they did it, and what their environment was like. Before our day of creating personas, scenarios, and design principles, we write up each user on a separate page.

LiRPPS Prep: The Prioritized Action List

The last thing we need to prepare is our prioritized action list. We’ve found that when we take a team out to meet their customers (often for the first time), they come back urgently needing to create this list. They can’t do much else until they’ve made it.

We ask the team to list out everything they think they want to fix or build, based on what they’d just seen in the customer visits. The team is so afraid they’ll forget the great ideas they had while talking and observing their users, they can’t think of anything else. We’ll often use the KJ Technique to prioritize the best ideas. We use the top winners as the focus for our new personas, scenarios, and principles.

Read part 2 of this article.