Published: Oct 09, 2013
Article originally printed on July 31, 2012 in discussingdesign.com.
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.
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 your 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:
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...
Again, there are tons of great resources on setting goals and principles. Some quick tips...
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?
Discussing Design, a blog focused on how to lead critiques, is co-written by Adam Connor and Aaron Irizzary. Adam is an experience design director at Mad*Pow and is also a renowned artist, illustrator, and digital designer. PS: He’s @adamconnor on Twitter.
How do you ensure that your critiques are constructive? Share them with us at the UIE Brain Sparks blog.
Read related articles: