Design Critique

Design Critique

Provide valuable design feedback to a project team so they can determine if further effort is needed

Phases

Discovery Framing

Suggested Time

30-60 min

Participants

Core team, stakeholders, other designers


Why do it?

It provides valuable design feedback to help the project team refine their solution. It helps the team find consensus when deciding what actions to take next. And it holds the whole team accountable for making design decisions.

When to do it?

Integrate design critiques into your workflow by having them regularly or whenever there is a need for feedback from the team. They are most helpful after a design artifact is created or iterated upon.

How to Use this Method

Sample Agenda & Prompts

  1. While the project team hangs up printouts of the design artifacts being critiqued, remind everyone that their job today is to help the project team find the challenges with their design, not the solutions, using language that is specific and kind.

    Tip: If necessary, remind the project team that they should take notes on what’s discussed (e.g. in Sketch or a text editor) and should refrain from defending the work. They can use project context to decide what should/should not be acted upon.

  2. Once everyone is settled, ask the project team the following questions and write each answer on the whiteboard for all to see:

    • What’s the name of the app being critiqued?
    • What is the goal of the app? For example, “‘Super Bowl Land’ is a series of screens for call center operators to manage the billing and account information for football fans during football season.”)
    • Who is the user?
    • What type of feedback are you looking for? 

       **Tip**: Product value props and features can be mentioned here. Try to keep this whole intro to a few minutes.

Try to keep the project team from explaining too much. It can be a poor use of time and it robs everyone in the room of their fresh eyes. Some of the most useful feedback the team can get is “I don’t understand this” or “I didn’t see that.”

  1. Once everyone understands the app being critiqued and the desired feedback, set a timer for 8 minutes of silent critique during which critiquers:
    • Review the screens, and
    • Write sticky notes of constructive and positive commentary 

       **Tip**: 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

Be sure to find the good, too, so that positive aspects of the design are not later deleted because they weren’t commented on.

  1. At the end of 8 minutes, ask critiquers to post their sticky notes to the appropriate screens

    Tip: 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 or fall into “group think”

  2. Scan the notes and open key topics for discussion, looking for patterns and areas that have a high number of comments. Be sure to mix in negative and positive comments as well as ask for expanded opinions from the group if a comment is unclear.

    Tip: If people start talking about or designing different solutions for the problem, remind everyone that they don’t have the same context or knowledge of the problem the designer on the project does

  3. As the group discusses each topic, capture key actions/tasks on the whiteboard in order to move to the next topic

    Tip: Once a problem has been converted into a task (“Super-Duper widget doesn’t make sense. Explore alternate designs.”), you shouldn’t keep talking about it

Success/Expected Outcomes

You know you’re done when all comments have been reviewed and all problems have been converted into tasks.

Facilitator Notes & Tips

Regardless of how you decide to run your design critique, you should ensure that a room is booked and any supplies (such as sticky notes, sharpies, and tape) are available.

Real World Examples

Design printout with feedback attached using sticky notes

Discussing Design by Adam Conner and Aaron Irizarry

Report an issue