Running better design critiques

Critical discourse is the most effective way I know of improving work and learning. It’s fundamental for anyone involved in creative disciplines. It’s also hard, but worth the practice.

While ‘crit’ improves our abilities as practitioners and strengthens our teams, it requires we take control of the whole feedback process. Only by leading critiques and asking clearly what we want feedback on can we really benefit.

What crits are great for

I’ve helped run 3-9 person critiques primarily in a digital product design setting, and find them particularly important for:

  • Challenging our assumptions (are we actually doing the right thing?) and approaches (are we doing it the right way?)
  • Improving how we think about and discuss ideas as a team
  • Improving our ability to articulate our intentions and approaches
  • (In)validating ideas early on before committing time to executing them
  • Learning from each others’ processes and methods, strengths and weaknesses
  • Consistently increasing the quality of our work, and how efficiently we do so
  • Facilitating an ongoing conversation about work in progress, so awareness and ownership is spread across all departments and specialisations

What crits shouldn’t be

Formal presentations

Structuring crits is important for making the most of the available time, and making that structure feel natural takes practice. But they should be conversations, not pitches.

Big reveals

In organisations with less than 10 designers (like FreeAgent), I consider it a failing of company culture if team members hear about new work for the first time during crit. Everyone should have at least a vague idea of work being done. We share works in progress every day on a private Tumblr account, which creates a stream of work that anyone in the organisation can view and comment on.

Brainstorming sessions

Crit is a great way to figure out if we’re actually tackling the right work the right way, but it’s not the time to explore every alternative. This is especially true with larger crits. If there’s a fundamental disagreement about the whole purpose of a piece of work, resolve that outside of crit.

Exclusive to designers

Don’t make design a department, make it an activity everyone participates in. Encouraging non-designers to attend crit lets them observe the process, and in turn lets them participate more effectively.

When to critique

My number one rule for crit is: don’t wait. Early and often is best, so aim to have several short crits every week. I encourage our team not to work on something for longer than a day before getting feedback. Making this a reality relies on a supportive environment; people should feel encouraged to experiment with new things and seek feedback when work is in its infancy.

In addition to everyday impropmtu crits, our whole design team has a ‘mid-week critique’ together on Wednesdays at 10am. I think of this scheduled crit as a fail-safe. It’s more like a regular forum everyone knows about, helping to create a nice little bit of pressure the afternoon before to get whatever you’re working on into slightly better shape.

Guidelines for running crits

These guidelines are what I use to structure the largest, most formal critiques. As with most things, introduce as little process as you can, then learn and adapt.

  1. Nominate a moderator

    Someone to keep track of time, keep things moving along, ensure all participants are heard, and remind presenters to note down any actions resulting from the critique.

  2. Presenter: describe the purpose and objective of your work

    And why you’re approaching it this way. What job does it do for people? What are their needs? What experience are you trying to create, and in service of what ultimate goal(s)? Everyone should understand and agree on the purpose in order to move forward.

    If the work has been critiqued before, be sure to recap the objectives and explain what changes have been made since the last crit. Compare screenshots, video captures, commits, or whatever else you need to prove the validity of those changes. If everyone agrees that the changes are for the better, we can move on.

  3. Presenter: define what you want feedback on

    Describe whether you’re still at an early stage, near completion, or somewhere in-between. Using sketches, prototypes, print-outs or whatever other medium fits best, explain your ideas, process, and any trade offs you’ve made. What are you most and least confident about? Then be explicit about what you want feedback on. Some suggestions:

    • Early stage: idea validation; high-level user, customer and business goals
    • In-progress: content, workflows, hierarchy, interactions
    • Later stage: UI details, micro copy, interaction finessing

  4. Participant: feeding back

    As someone critiquing the work, listen. Then listen some more. Take notes of any thoughts and questions if need be, but don’t interupt the presenter. We all deserve the time to explain our rationale before being questioned. Sometimes simply talking through rationale aloud makes solutions obvious.

    Highlighting the strengths of the work is a good first step. Then try probing into why decisions were made, particularly if you think they’ve been subject to bias. Concentrate on explorative and divergent questions instead of issuing commands and being prescriptive about what actions to take.

    Always be asking: is this fulfilling the purpose of the work in the best way? Will it do the best job of helping the people who need it? Is there too much ‘design’ getting in the way? Can it be made purer?

  5. Presenter: create a task list and explain what you’ll do next

    Take a note of what actions you’ll take as a result of the critique. For example: a different creative direction, rewritten content, more research, more testing. Then explain what the next milestone is, and when the team can expect to see the next iteration of the work. When you get back to your machine, post your action lists into your design team channel or chat room so everyone’s clear on what’s being done.

Numbers and timings

Our scheduled ‘mid-week critiques’ are the largest crits I moderate: 9 people, timeboxed to 1 hour. These 9 people span two different design teams: communications and product. If everyone has work to be critiqued, a single hour really isn’t long enough to do it all justice. But I also think an hour is a big enough chunk to be block booking out of everyone’s already busy day.

The solution we’ve found in the product team is to organise separate crits of 3-4 people. These really let us dig into the details. Any significant learnings we feel are relevant to the whole design team will naturally be mentioned in our Slack #design channel, in face-to-face conversation, or during our next team-wide crit.

As with standups, I see the quality and value of crits quickly degrade as they grow too large. With smaller crits of 3-4 people being more focussed, I’d wager that having a weekly team-wide forum instead of a crit would be a more effective use of everyone’s time in much larger design teams.

Tips for presenters and participants

Be assertive. Don’t belittle decisions you’ve made and avoid starting sentences by saying “This is just my opinion, but…”. Equally, be honest when you’re unsure of your choices instead of trying to post-rationalise.

Define boundaries. Early stage crits aren’t for discussing execution details, just as later stage crits aren’t for completely rethinking the approach. If presenting, be specific about what you actually want feedback on.

Don’t get defensive. Learning not to take feedback personally is one of the most fundamental lessons to be learned. Critique is an objective practice. It’s not about us, it’s about the work.

Critique yourself beforehand. Ask yourself questions of the work and find the best way to articulate your ideas and approach. In doing so you’ll not only be better prepared to field questions from others, but will quickly identify failings in the work before others do.

Use the 5 Whys exercise if you’re struggling to get to the bottom of why a decision was made.

Groups vs one-on-ones

Group crits are the best way to expose the rigours of good process to everyone in the team, and a greater number of participants should (in theory) mean a broader spectrum of feedback. But involving more people lengthens the crit, and certain people will naturally be more apprehensive expressing their opinions in larger groups.

One-on-one crits can be hugely effective with the right people. If I’m feeling confident about a piece of work, I know I can take it to a few specific people and they’ll tear it to shreds — or at least ask dozens of questions I’d never even considered! Knowing who to ask, and when, makes a massive difference. We all give different feedback depending on our own biases and tastes. Seek out divergent thinkers early on, and convergent thinkers in the later stages of a project.

Example questions

Around the work

  • What evidence do we have of the need for this? How do we know this is the best response to that need, the right thing to be making?
  • What do we actually want people to do with this? How does that fit into their daily lives and routines?
  • Who do we expect to be using this, and in what scenarios? How do we expect that to affect their emotional state?
  • What’s our definition of success here? How will we know when it’s been successful?
  • What are the implications for our other work in doing this? Will this require changes to be made elsewhere? Is now the right time to make those changes?

Inside the work

  • What were the steps you took to get here? What other alternatives have you tried, and why did you settle on this approach?
  • Do we have any existing design patterns similar to this? How does this factor into our whole design system?
  • What would be the worst way to design this? Is there anything we can learn from that?
  • Why have you chosen this tone? How does it fit with the way we might expect people to feel when using this?
  • Is every element central to the task in hand? If not, what purpose do they serve?

References

These articles have helped inform my approaches to critiquing work: