At a design critique (or ‘crit’) any designer can share a piece of work in progress with others to get feedback and iterate on it.
My former colleague María Izquierdo and I have been using design crits as part of our work on GDS data services for a few months now. During that time, they’ve proven to be a great way to get feedback and improve collaboration between disciplines.
The design team at GDS recently organised the first cross-government design crit and case study day. We held it at the GDS office and around 40 designers, user researchers and content designers from across government came along to learn about how to run better crits and get feedback on work.
In this post, I’m going to share how we use design crits and how they can benefit your team.
Why do a design crit?
When I do a design crit, I invite my whole team, which includes developers, user researchers, product managers, and other designers.
Design crits aren’t just useful opportunities for early feedback. They can improve collaboration across disciplines by involving everyone in the design process. They can also have a positive influence on team culture. They can ensure that design is a facilitator for valuable conversations and a core part of how a team works.
I’ve asked the team members who’ve been attending design crits for a few months now for feedback. These are some of the things they value about crits:
- they give the whole team an early view of what's coming up
- they give everyone a voice
- they help build shared understanding
- they’re an opportunity for all disciplines to learn about design and from each other
- they bring all disciplines together, so work isn't compartmentalised
- there's something concrete for everyone to look at, so it's easier to identify research problems and gaps in knowledge
- they facilitate dialogue when we have to make decisions as a team
Advice for running a design crit
Shortly after joining GDS, I attended a 3-day design training session. The design crit session helped me to run crits with a better structure. Here’s what I learnt about in the training session, and how I use these techniques in my current work:
Start by specifying what you want to get feedback on and giving context
This helps the conversation stay on track. If the session indicates that you need to talk about technical aspects or how to test the work in progress, you can make a note and have a separate conversation to do that afterwards.
If you are doing a crit with people outside your team or organisation, start by setting some context, like who the users are, what the user needs are, any assumptions you've made and what stage the project is at.
Explain what useful feedback looks like
Examples of useful feedback can be:
- relevant research evidence from other projects
- technical difficulties
- existing design patterns on other services that could be reused for what you’re showing
- anything else that is based on evidence and not on personal preferences
Feedback like “I don’t like it”, which is based on personal opinion, or “that will never work”, which is based on assumptions and not supported by evidence, is not useful.
Get someone to take notes of the feedback
Because you’re presenting and facilitating the session, you’ll need some help to gather the feedback and questions from the team.
What I’ve learned
Along with these, I’d also like to add some of my learnings from running design crits:
Always have something to point to
I’ve shown work at different stages, from journeys sketched on a whiteboard to working prototypes. It has always helped to have a visual aid to get the team to understand the problem I’m trying to solve, even if it’s a high-level one.
Talk about the process when you give context
Before I show the final option I’ve chosen, I talk the team through the findings that led me to that decision. I also go through the other options I’ve explored and explain why I haven’t chosen them. This opens the design process to the team and helps them understand how design decisions are made.
Avoid jumping straight into solutions
Some members of the team might suggest specific solutions during the crit. To keep the conversation on track, I acknowledge their suggestion but remind them that the session is to gather feedback, not solve problems right on the spot. The same goes for questions I can’t answer right away. I make a note and get back to them later.
Try to have design crits regularly
We have design crits every week if we can, every two weeks at most. We don’t always look at exciting new work, we might critique small iterations to designs that are already built. But it helps to establish a routine. Team members get used to viewing design work in progress and have regular opportunities to improve at giving feedback.
Learning more about design crits
Following our recent cross-government design crits meetup, we hope to hold similar events in the future so that everyone can share their experiences and learnings from design crits. Contact the User Centred Design team if you’re interested in taking part.
And if you have taken part in a design crit and have any thoughts or advice about them, please share them in the comments section below.
Follow Blanca on Twitter and don’t forget to sign up for email alerts.
