How to run a design critique by Scott Berkun

How to run a design critique by Scott Berkun

 

From the post:

Goals of a design critique

A design critique involves a small group of 3-7 to discuss a set of sketches or prototypes. You could focus purely on branding elements, ease of use concepts, or even engineering feasibility, it’s up to whoever leads. The important thing is someone does lead the discussion, define what questions should be discussed and facilitate the conversation.

If there are 3 or 4 specific questions you want answered, define them. Without goals everyone will work from different assumptions, and it will be more of a brainstorm meeting than a critique.

If you are early in a project, critiques  should emphasize the higher level user, customer and business goals, and minimize the focus on specific engineering constraints or aesthetic choices. Its worth flagging ideas that engineers or business managers have large concerns about, but hold off on completely eliminating them from the discussion. There may be opportunities to ask for more resources or make other adjustments to a project, if a stellar design concept or idea is championed successfully  (e.g. perhaps a design idea exposes a new business plan that has more opportunities than the current one, and would justify a change in the project goals).

But as the project timeline progresses the tone of critique discussions should change. There should be pressure to have solutions to issues, and the bar for considering new ideas should get higher. If managed well the scope of critique discussions should peak during planning and continually decrease.

Shepherding the creative phase of a project is a significant challenge, and it’s rare to find someone than can manage it as well as the more production oriented implementation and release phases. Often there is a key leadership role for designers to play to fill this gap. Overall, the tone, content and quality of critique meetings is one indicator to how well the creative process is being managed.

Typical goals for critique meetings might include:

  1. Obtain specific kinds of feedback from those in the room about a set of different design approaches for one feature or area of a website.
  2. Compare how several different components of the same product are designed. (Are there elements that should be reused more? Do things that look similar behavior similarly? Etc.)
  3. Discuss the user flow through a design, by examining each screen in the sequence that users would go through to complete a task. (Similar to a cognitive walkthrough).
  4. Explore the designs of competing products, or designs of other products that have elements or qualities that you want to achieve.
  5. Allow teammates with different job functions to provide feedback from their expertise. (QA might raising testing issues, development might ask feasibility questions, marketing might ask questions about advertising or partnerships, etc.)

These goals listed are mostly mutually exclusive. You might be able to manage two of these at the same time, if you’re a great meeting facilitator, but I wouldn’t recommend it.

Secondary goals often include:

  1. Provide some structure to the creative process of a project.
  2. Improve your team’s ability to think about and discuss design ideas.
  3. Teach non-designers about the design critique technique, so they can apply it to other kinds of problem solving situations.

Independent of the specific critique goals: If there are questions from your teammates about your design that don’t fit your intent for the meeting, make sure you come up with some way to address them outside of the meeting. During the meeting, write them down on a whiteboard or notepad, and take them with you when you leave. The more inclusive your design thinking is, the more influence and authority you’ll have over how project decisions are made. Even if the issues you are confronted with arise from decisions out of your control (a demand from the marketing team, or a new constraint from engineering) you want your designs, and your design process, to work with these issues, not around them. (Unless you feel confident that your superior design and skills of persuasion will convince someone with authority to change their mind.)

Who is in the room

conference roomA critique should allow a small group of people to review and discuss many ideas quickly and informally. You can’t be informal and intimate about ideas with more than 5 or 6 people in the room. Instead, you must narrow down your invite list to the people most critical to the design process. Try to forget about job titles or hierarchy, and instead, focus on the people who are most likely to understand the creative process, and give useful and meaningful feedback, both positive and negative.

Depending on the personalities of your teammates, make adjustments as necessary. For anyone on your team that isn’t invited to the meeting, allow them to look at any handouts or pictures, and give you their feedback.  Or even better, make sure to forward them any of the notes you send out following the meeting. In most cases, they’ll see the quality of the dialog and kinds of discussions points that were raised, and ease up on their complaints about not being in the room. And even in the absolute worst case, make yourself available to listen to their feedback independent of the critique session. You can diffuse difficult teammates, appeasing them without derailing the critique meeting, and the creative momentum of the team.

One alternative for designers in larger organizations: you might be able to do design critiques with the other designers in your organization, even if each of you works on different projects. This can be a great way to build a sense of design community in your organization, and give you the benefit of other well trained design eyes, that are fresh to the problems your trying to solve. The downside to this is that you miss on the opportunity to build better design relationships with the non-designers on your team. In the best possible world, you might have time to do both kinds of critiques, at different times in your project.