Click here to preview the new Fast Company

Want to try out the new

If you’d like to return to the previous design, click the yellow button on the lower left corner.


9 Rules For Running A Productive Design Critique

Design critiques can be painful, long, and unfocused. Here are some guidelines for avoiding the most common pitfalls.

Four people crowd around a 27-inch monitor, peering at a design mockup.

First developer: "Are you nuts? We can’t build all that for the next release."

Second developer: "Have some vision, man! This is for next year. Uh... right?"

Product manager: "We should use those thin little icons, like on my iPad. Here, look at my iPad. See? Great icons, right?"

Designer: (Shakes with rage and/or sobs.)

Design critiques—the process whereby a team gets together and reviews a design or a product prototype—can be painful. When people aren’t on the same page about goals and context, critiques can take a long time, they can lead to inefficient or unclear outcomes, and, let’s be honest, they can hurt feelings. But they don’t have to be that way. Here are my favorite rules to make them efficient, focused, and worthwhile.

1. Identify the design owner

The owner is usually the designer working on the project. After the meeting is over, they will be the one on the hook to solve any problems that get identified. Write their name on the board. Remind everyone "so-and-so is the designer. Not you. Our job today is to help her."

2. Designate a facilitator

Don’t expect the meeting to run itself. Pick somebody whose job is to follow these 9 rules and move things along quickly and efficiently. It might be the designer, but it doesn’t have to be. Ideally, it should be someone a little bossy. Write their name on the board, too.

3. Restate the project goals

The design owner should—very briefly!—remind everyone of the goals of this project. This should be something like one to five bullet points, and hopefully at least one of the goals is measurable (for example: increase task success by 50%).

Referring to the project goals will help the team make informed judgments, not just gut reactions. And yes, write these goals on the board.

4. Ask for what you want

Do you want feedback on the high-level user flow, or on nitty-gritty visual polish? Be specific and you’ll keep the critique focused and useful.

Also—you guessed it—you should write the meeting goals on the board as well. It might sound kind of silly, but writing all this stuff on the board really helps people craft the right kind of feedback. They’ll appreciate the constraints.

5. Steer clear of sales pitches

Starting your meeting with a long explanation of every screen from the designer is a bad idea for two reasons. First, it’s a poor use of time – designers, myself included, can get long-winded when talking about their work.

Second, it robs everyone in the room of their fresh eyes. Some of the most useful feedback a designer can get is "I don’t understand this" or "I didn’t see that." If you explain and point out how everything works upfront, you’ve just given everyone a monster spoiler, and you’re much less likely to spot comprehension problems.

6. Write it before you say it

After you’ve identified the owner and written down their goals, it’s a good idea to spend a short time (say, five to ten minutes) with everyone silently reviewing the design work and taking down notes. This silent work time lets everyone think about the design a bit more deeply, and experience it by themselves—which happens to be the way you experience design in the real world.

The added benefit is short-circuiting groupthink. When everyone has to commit their opinions to paper before they share they become a lot less likely to all pile on to the same opinion.

7. Go negative AND positive

Of course, you want to encourage constructive criticism. Finding flaws at the mock-up stage is obviously far more efficient than patting your designer on the back. You don’t want to protect people’s feelings and end up launching a suck bomb product.

But you also want to make note of the good stuff. Most likely, at the end of your meeting the design owner will have a list of problems to address. If you don’t also give them a list of things that are already working well, they might accidentally throw the baby out with the bathwater.

8. Don’t design in the meeting (that’s the owner’s job)

While it’s OK to suggest an alternate approach occasionally, don’t use your design critique to solve big problems. Design work—as with other kinds of critical thinking—is best done by an individual. Identify problems, but leave it up to the owner to figure out the answer.

9. Leave with a task list

The facilitator keeps things moving by converting discussion into tasks. Once a problem has been converted into a task ("Frobazz widget doesn’t make sense. Explore alternate designs."), you shouldn’t keep talking about it. Write the task on the board. Once there are no more new tasks to capture, you should end the meeting.

If you keep your design critique on these rails, you’ll typically get through it a lot faster, and everyone—the designer included—will feel a lot better about the outcome. Treating critiques seriously means you’re taking design seriously. That’s good for your team and good for your product.

Interested in reading more on this topic? Scott Berkun wrote a great post on design critiques 10 years ago that’s still super useful today. Do you have design critique rules that work well for your team? I’d love to hear them!

[Image via Shutterstock]

Add New Comment


  • robyn hansen

    I like when designers set parameters that respectfully protect the creative process. It is such an important way to get the very best work from your team.

    It often seems as though with every other role in the company, there is the assumption that those people are professionals and can be trusted to do their job with little-to-no input from the design department, but for some reason, when it comes to the design process; everyone gets to give direction, and it's very often at the pixel level.

    While it is a process and great ideas can come from anywhere (and it's important to be open to that); it's when ideas are coming from everywhere, and everyone's experience and expertise out-trumps yours, that it gets muddied and it's really easy to veer off course.

    What I really like?... that the comments immediately start to critique the ‘critique rules’ (I'm guessing the majority of them are not from designers).

    This is why we need rules.

  • rfairfax

    "Product manager: 'We should use those thin little icons, like on my iPad. Here, look at my iPad. See? Great icons, right?'"

    My guess is that this was written from the perspective of someone who is not a product manager. As a PM, I've heard more designers gush over icons than product managers. FYI most product managers are concerned with making something that works, getting it to market and meeting/exceeding users' needs than with what happens at a pixel level.

    Designers do a disservice to themselves and the teams they work with by depicting the contributions and intelligence of other disciplines as trivial and inane.

  • Jake Knapp

    No diss intended. 

    That imagined conversation was meant to be satirical – including the overly-emotional designer – and if you didn't laugh, I didn't write it well enough.

    However, I take issue with the idea that PMs aren't concerned with what happens at the pixel level. Just like the best designers and engineers care about product/market fit, the best PMs care about design, and yes, even pixels. In fact, it's totally okay for the PM to have an opinion about the icons. You just have to have those conversations at the right time and on the same page, which, as I meant to joke about in the intro, often doesn't happen.

  • ehoffer

    I'm not saying that structure is bad or should get thrown out. I'm saying that YOUR proposed structure is good for general meetings but not uniquely valuable for DESIGN critiques.

    Design critiques, for example, might involve a reductive exercise where designers pull off elements of the product prototype until we get down to the absolute essence of the product.

    Design critiques might also be structured around design principles like color, typography, hierarchy.

    Critiques could also be structured for analysis of function and usability.

    Each of these lenses have a particular structure that designers and the design in question can benefit from. Yes good meeting structure is important but that only gets you to first base. To get substantive value from a critique, a designer needs much more.

  • Jake Knapp

    Thanks for the reply and expanded notes – those are all super good points, and you bring up a great set of structures for a design critique that I had omitted. Your point is well taken that the "9 rules" only gets you a foundation.

    I guess the only place you and I might disagree is on your first point: "a design critique is attended by people who know something about design." I'm not sure exactly how to define "know something about design" but I am convinced designers can get quality feedback from smart people who aren't themselves designers, and don't necessarily know how much about color, typography, and hierarchy, etc. 

    I don't mean to say those things don't matter – they absolutely do. But at a fundamental level, the design *is* the product. It follows that the other people who are deeply invested in shaping the product (CEO, founders, engineers, marketers, and so on) need to be involved in shaping the design. When you review work with those people, it's also a design critique – a different kind than the one you're describing, perhaps, but it can certainly be every bit as important.

    Thanks a lot for writing back – I appreciate the discussion!

  • ehoffer

    This isn't a design critique. A design critique is attended by people who know something about design. You're describing a feature-level design feedback meeting with the client or with the people doing implementation and your 9 points are good general meeting tips, but not anything special for designers. These 9 points might be helpful for what Googlers call a design 'critique' but are of limited use to someone practicing design in a design-centric company or agency.

  • Jake Knapp

    It's awesome that you work at such a design-centric company that your team doesn't need a structure and can just fall into a productive critique. It's awesome, but I do think it's uncommon. Product companies (whether startups and large companies) generally do benefit from more structure, and not just for feature-level reviews. 

  • Zeke Franco

    Good advice. I'd add a few tips: You might need to use a parking lot to manage input and perhaps even friendly ground rules for new teams. As a “design owner,” there are times where it makes sense to sketch ideas in the meeting as critique comes up. This way you can flesh out where the concerns are and exactly what the critique is. I make it clear that I'll iterate on the sketches/design afterwards. It could feel a bit condescending to tell a group of passionate people, that you'll take their concerns into account and "address them" later. I find a team really engages when you can start helping them by sketching out their feedback. But I do agree, don't solve big problems during a critique.

  • Zeke Franco

     : Usually the "facilitator" will get us back on track if we are getting too tangential or just not syncing up well. Generally, I just try to sketch out what they are saying, tweak a few details, take a picture of the sketch, then say thanks for the feedback and move on.

  • Jake Knapp

    Those are excellent points. A parking lot can be a great tool, and I agree that capturing issues or questions with a sketch both builds team confidence and removes ambiguity. How do you ensure that the team doesn't go too far down the sketch path and design in the room?

  • Clare Ross

    Thank you for this instructive and usable list. Its a solid and well thought out structure. I think that the steps are applicable to all kinds of projects and I plan to use them at my next meeting. Thanks so much.

  • Jake Knapp

    Awesome, thanks for reading! Write back and let me know how it goes when you try them.