UX Crash Course: Running Critiques

A critique is an invitation for others with different perspectives to help point out what’s working and what isn’t with a design. It’s different than a pitch.

In the Foundations of Design for Developers free ebook, we discuss the process of pitching your work to clients and how you can get the most out of that experience. Since pitching often involves (at some small level) a critiquing of the work, it’s probably best to take a step back and talk about how a pitch and a critique can be different—and where they sometimes overlap.

Pitching vs. Critiquing

The first and main place in which pitching and critiquing differ is the end goal of the session. A pitch is intended to get the approval of stakeholders and the official “go ahead” on what you’ve created. Sometimes, as part of that, stakeholders will offer opinions on what they think should be changed—and those suggestions may need to be implemented before they’re willing to move forward with the next steps of the project.

A critique, on the other hand, only has the end goal of hearing different perspectives and getting feedback on the work. There is no official signing off on the work at the end of a critique, no firm “yes” or “no”—just (hopefully) new ides about what you’ve created.

Because of that, a pitch is generally aimed to focus on the positive. For example, while it’s good to be open to feedback during a pitch, I would never specifically highlight pieces of the work that I wasn’t feeling confident about. By the time you’re taking work to a pitch, you should feel that it’s the correct solution—and (ideally) have the user research to back that up.

Contrasting that, a critique is an invitation for others with different perspectives and life experiences to help you poke holes in a design and find places for improvement. It’s an opportunity to find what’s working, as well as what isn’t. That’s not to say that a critique should be harsh, hurtful or insulting—it absolutely shouldn’t. However, you’re not trying to sell anyone on the idea that this is the right answer. Rather, this is part of the process of making sure that you do end up with something you feel confident enough in to pitch.

As you’ve probably already guessed from those descriptions, pitching and critique also happen at different parts of the product creation process. A pitch happens at the very end of the design process; it’s a presentation of the (mostly) completed work, with some small room left for iteration before development. A critique can (and should!) happen at any point during the design process and doesn’t require completed work.

So, to sum up:

Popular Critique Frameworks

While you can, of course, just open up your work to critique and use a self-guided or more casual approach, some folks (beginners, especially—both leaders and participants) find it helpful to have a little more structure. If that sounds like you, consider using one of the following existing critique frameworks to shape and guide the discussion. All of them can offer you valuable feedback, so which one you reach for is entirely up to you—as is what kind of information you’re looking for.

I Like, I Wish, What If?

Using the “I Like, I Wish, What If?” (IL/IW/WI) framework encourages respondents to break down their feedback into those categories: “I really liked the functionality of B. I wish I could have done A earlier in the process. What if we added A to the nav menu to highlight it more effectively?”

IL/IW/WI works so well because it encourages people to problem solve rather than simply complain. While it does take a little setup and time to explain, it’s not too tricky and offers some valuable room for nuance. After all, everyone can find something they like (or don’t like) about an experience—that’s the easy part. Thinking about how they would rather see something function is a harder question.

While like/dislike information can be somewhat helpful, it’s also infinitely more helpful to hear about how someone wishes something worked. That offers insight into why they didn’t like it—insight they might not have even been able to put words to if asked directly (”I dunno, it just didn’t feel right”). By asking participants to avoid “I disliked” statements and instead refocus those thoughts in to “I wish…” and “What if…”, you’ll end up with much more action-oriented feedback.

Rose, Bud, Thorn

If you are looking for a more straightforward beginner-friendly approach to critique, “Rose, Bud, Thorn” ( RBT) may be the right fit for you. RBT asks respondents to look at what is working well (Rose), what has the potential to be great with some small adjustments/tweaks (Bud) and what was an active pain point (Thorn).

RBT is highly approachable and easy for everyone to understand quickly. While IL/IW/WI sometimes takes a little explaining and requires some examples, most folks are on board with RBT pretty much immediately. In fact, many have used the same framework non-professionally to talk about life experiences, their day at work or school, etc.

However, it is important to emphasize (if you’re guiding the session) that Thorns shouldn’t just be things that the participants don’t like—they should be true frustrations or pain points. For example, “I don’t think the button should be blue” isn’t a Thorn, but “It’s hard to get back to the homepage after completing the form” is.

SQUACK

SQUACK is a feedback framework created by Julie Jensen; it stands for Suggestions, Questions, User Signals, Accidents, Critical Issues and Kudos. While it does have a few more moving parts than the others, it’s also great for calling out specific things—making it especially good for in-depth critique sessions with other design and dev professionals.

Suggestions are comments or thoughts that the reviewer knows are more subjective than objective (which makes it the right place for that “I don’t think the button should be blue” comment from earlier). It’s a great way to bring up ideas while also acknowledging that they’re personal and not necessarily data-based.

Questions are good for raising an issue that the reviewer might not have the answer for yet. Often, during critique sessions, we feel the need to jump right to saying something—offering useful feedback in some way. But sometimes we need to know more before we can do that. Building in space for questions can be a helpful reminder.

User Signals are the place to capture user research or results from usability testing. If you see something that doesn’t align with the information you gathered during user interviews, this is the perfect place to bring that up.

Accidents are for obviously unintentional mistakes—and believe me, there’s always one or two. Nothing will derail an official pitch faster than a typo. People sometimes feel under-prepared to offer design feedback, so they’ll latch onto the things they know for sure aren’t right. This is great for preventing that by catching broken links, errors and other obvious mistakes.

Critical Issues are things that will immediately cause issues for the user if included. That could be an accessibility issue that prevents the product from meeting a certain standard, language that the Legal team needs to review or other crucial problems to solve.

Finally, Kudos are (of course) credit where credit is due for the things that work well. In all critique systems, it’s important to leave room for the good things—not just because it’s nice to hear (and it is), but also because we don’t want to unintentionally change or disrupt a part of the product that’s working well in our efforts to fix the parts that don’t.

For a deeper dive into the SQUACK framework, check out Jensen’s book SQUACK to Improve Feedback.