There are two kinds of designers: those who’ll admit they’ve had trouble handling feedback, and liars. That’s why the new book Discussing Design: Improving Communication and Collaboration through Critique caught my attention. The authors (Adam Connor and Aaron Irizarry) shared a number of useful concepts around design critique that I folded into our process. This post is an overview of what we changed; I encourage you to read the book and apply the lessons in your work.

The Bigger Picture

The improvements we’ve made around critique act as a bookend to another recent process change in how we collaboratively generate a high-level design direction for a given set of features. Simply put, we come up with the basic ideas together, and we evaluate the full-fidelity designs together.

This is a subtle point, but it’s critical. Since all of our fingerprints are on the designs, no one feels like they’re in front of the firing squad during the critique. Even if one person did the lion’s share of the detailed design, they can still switch hats and be a critic.

The 75/25 Process

As it relates to critique and iteration, the basic process is as follows:

1. Collaborate on the high-level design direction for a given set of features, but don’t use more than 25% of the available time.

2. Pause and evaluate the design concept against the higher-level project and business goals. (Whenever possible, also compare it to what you’ve heard from customers and users.) Decide whether you need to change direction, then select a solution.

3. Prototype that solution, but don’t use more than 75% of the available time.

4. Pause and analyze the effectiveness of the prototyped, high-fidelity design relative to the finer-grain objectives of that specific design. Identify improvements to make.

5. Use the last 25% of the time to make as many of the improvements as possible.

The 75/25 rule sounds a little arbitrary, but I borrowed it from Pixar. Without Lean-style pivots, a quarter of the way through is about the last responsible moment to change direction. And to make non-trivial improvements, developers will need at least 2-3 days in a typical two-week cycle (i.e. 20-30% of the time).

You can also look at the flip side: early on it’s too soon to nitpick, and later on it’s too late to make fundamental changes. In the middle, you mostly have to leave people alone and let them work.

Critique: Effectiveness Analysis

Adam and Aaron’s book gave me what I was missing to structure the critique session into something that’s a useful input to design. First, framing the session as one focused on analysis gets people into a critical thinking mindset. Try your best to keep people in an evaluative mode instead of slipping into a problem-solving mode. (There’s no magic trick to this; just stick to your guns and emphasize that you really want to devote this time to smoking out all the improvements you possibly can.)

A natural extension of the analysis is an articulation of the objectives. (I specify the key objectives in writing.) Explicitly discussing your targets is key to knowing whether they’ve been hit. In the book, the authors use the term “objectives” as a catch-all to capture anything the design should be factoring in:

• Your personas and their goals

• Your project’s business goals

• The scenarios that have touch points into these features

• Any design principles agreed upon by your team

• Any relevant best practices for your target platform

• and so on…

Depending on your culture, having a forcing function for a discussion of objectives might just be the biggest impact of properly managing design critique.

When the Going Gets Tough

The thing I’m most grateful for about the book is the frame of mind that helped me come up with these sentences during some uncomfortable moments:

• “I hear what you’re saying about that [specific design element]. Can you tell me more about the problem you feel is inadequately solved by what we’re seeing now?”

• “I can tell you’re not in love with this, and that’s OK. Which parts of this design seem to lack effectiveness?”

• “Hmm, that’s interesting. I wonder if we should reframe this objective, perhaps significantly. Or have we identified an entirely new objective?”

• “That’s a powerful idea, but it would take us in a new direction. Can I talk to the development lead and get back to you?”

• Stakeholder issues a directive; “We can take that specific directive, but I’d like to go further; anything you can tell me about the line of thinking behind that will help me apply the same idea elsewhere.”

Though you might be bracing for impact, you may very well hear reactions you don’t expect. Depending on their personalities, some stakeholders may not make any decisions on the spot and ask for time to think things over. This feels anticlimactic, but it’s healthy. I think it’s part of the reason why the authors included a detailed example of sending the stakeholders the designs in advance(!) so that they can mull them over beforehand.

Are You Ready to Get Better?

I would definitely rather hear gushing praise instead of outright insults, but neither contain information I can use to improve the design of a product.

So why not use every available method to make things better? If Pixar does it, shouldn’t you? If engineers do code reviews, shouldn’t you do the same?