Setting the Foundation for Meaningful Critiques: Goals, Principles, Personas and Scenarios

In a recent post Aaron talked about the importance of intent in the success of critique. Without the right intent on both sides critiques can go nowhere. Or worse, they can hurt the design, the designer and the relationship between the designer and the critics.

But now lets say that the intent is right. The critics are looking to help the designer understand the impact of the decisions he or she has made. The designer has every intention of listening, of critiquing right along with the critics, and using what they learn to iterate and improve upon their design.

There is still a chance that the critique will go south or yield little of use.

Remember that critique is a form of analysis. It’s a dialog about the hows and whys of the design aspects that are working and those that aren’t. But working towards what? In order to analyze anything, you need to have something to analyze it against. Often, this is where we see critiques fall down. The participants all bring their own perspectives to the critique, and that’s great, but they also may be bringing their own idea of what the design should be and do. Without everybody on the same page, the information you collect in a critique can be scattered, conflicting or irrelevant.

And this is where goals, principles, personas and scenarios come into play. Don’t look at them as just deliverables in a statement of work, I know many people often do. Look at them as a level of understanding. By providing your teammates or critics with this information you can set a foundation on which good dialogue can be built.

The Background: Personas and Scenarios

Personas and scenarios provide the “setting” for the analysis? How are we going to look at the design? Through whose eyes? With what behaviors or expectations? In what contexts?

In UX design it’s common to say phrases like “I/You are not the user.” This can be hard for people to remember; clients and professionals with other areas of expertise, hell, sometimes even UX designers, forget it for a moment or two. By setting up solid personas and scenarios at the beginning of your project (hopefully based on research) you give yourself and your team a starting point to help guide your critique and analysis.

It’s important to make sure your team understands and agrees with the scenarios and personas you’re project is addressing, so make sure to review them at some point in your process prior to starting critiques of your design. This way, when comments come up in a critique that feel like they’re based on a personal preference, or a usage outside the scenarios you’re designing for, you can refer back to your personas and scenarios and ask how the comment relates to them.

If it does, great! Your critics are still analyzing from the foundation you set.

If not, you can move the critique along to the next comment. Or perhaps you need to discuss whether the comment really matters and should be factored into the design. It is possible to miss something when coming up with personas and scenarios. But by having them at least now you have a basis for discussing whether these comments indicate that something may be missing.

There are tons of great articles, webinars, presentation slides and so on that talk about how to create good personas and scenarios, so I’m not going to cover that here except to mention a few points:

• Make sure your personas are about user’s behaviors, goals, and expectations. Don’t get hung up on demographics. I’m told that occasionally demographics matter. And I’m sure they could, but I haven’t yet encountered a project with personas where demographics weren’t just a stand in for implied behaviors. For example, giving a persona an age of 65+ to indicate they might have difficulty seeing, be slow moving, etc. And as Dana Chisnel likes to point out, assumptions based on demographics have a tendency to be misleading.
• Your scenarios should set the context and flow of the story. It should describe what happens, but not how. And it should describe the experience you’re trying to create. Sure there will be edge-cases and the need for error handling etc., and you can handle those with variation scenarios if necessary. Focus on the experience you want users to have, and then construct the design to elicit that experience.

The End Game: Goals and Principles

If personas and scenarios are the starting point, then goals and principles are the are the finish line. Goals and Principles describe where you’re trying to go with the design; the problems you’re trying to solve and the guidelines by which you want to solve them. For whatever aspect of a design you’re critiquing, you can ask of them: “does this help us reach our goal of…” or, “does this adhere to the principle of… ….that we set?” followed by “how?” and “why?”

If your team knows the goals and principles, if they understand and agree to them, then similar to personas and scenarios they act as a tool to keep your critiques on track. With them you can keep the discussion focused on learning things that will help you iteratively improve your design and move closer to achieving the desired end state.

We sometimes get asked what the difference between design goals and design principles is. It’s simple…

• A design goal is an outcome from the production or use of the product/service. It describes a changed state that happens as a result of the thing you’re designing.
• A design principle describes a characteristic of the design itself, but (similar to scenarios) not how that characteristic is achieved.

Again, there are tons of great resources on setting goals and principles. Some quick tips…

• Goals should be measurable (of course). Not just because it means you can actually track success later, but because having an idea of how something will be measured and monitored can help clear up ambiguity in what the goal is really about.
• Be specific with design principles. There are lots of basic (read: generic) design principles out there. People are constantly publishing their “10 critical design principles” lists, and those are great. Don’t ignore them. But make sure that you’re creating principles based on the personas, scenarios and other things you learn from the research on your project.

What happens without these things?

Can you still critique? Of course you can.

But typically the value of these critiques relies on the likemindedness of the participants, or chance. Without these things you and your critics are left to using assumed, unarticulated stand-ins. Chances are the people in the room will have different opinions of who the users are, what scenarios the product will be used in, what the goals for it are, what design principles should be followed. Hell, even if you decide just to use basic, generic design principles, there are tons of different permutations, and across them there are some conflicts based on schools of thought.

Often what happens in these critiques is that the discussion either focuses on those general, assumed design principles, which can still be helpful or the it turns quickly away from the design itself and toward how to analyze the design. Are the ideas that Joe, the business analyst across the table, has about the product’s users correct? Are the goals that Denise, the developer next to you, is talking about the ones you’re really after? If you do come away with new understanding of your design, will they really contribute to improving the product any more than addressing some general design issues?

By setting up principles and goals and using them consistently throughout the design process, you give your team the ability to elevate critique beyond the basics and avoid awkward conversations later about just what the hell it is you’re trying to design.

Now I know it sounds like I’m saying you need to do a lot of up front work to incorporate meaningful critiques into your process. And in a way, I guess I am. I’m sure the agile and lean proponents out there (i consider myself a process independent, in case you were wondering) are ready to filet me. I don’t think that some of these things have to take a ton of time. With the right information, conversations and collaborative attitude, the important parts of these things can be hammered out fairly quickly.

And of course, like I said, you can critique without them, just be prepared for what may happen. But, if you can use these tools, and you know they’re helpful in improving the way you and your team talk about your design, why wouldn’t you?