With only 2 designers in Product Technology - which is now a team of around 30 people in total - there isn’t a lot of opportunity for constructive criticism or peer review. It’s easy to work alone on something without putting your work out there for review and more importantly, improvement.
To force the team to seek out and receive feedback, we’ve started to run formal* design reviews. We borrowed our initial agenda from various blog posts and smart people in the design world, but it has evolved, and is most definitely a work in progress for our team.
The review provides the team with a space to focus on their profession and helps feedback to become part of our regular workflow. It has helped the designers produce better designs and also helped us ask better questions of our product development. Learning to ask the right questions is a really important skill.
Recently we tested the agenda in our first Trans-Tasman review with our Fairfax Australia counterparts. It proved pretty successful enabling us to to effectively triple the size of our design brain power for a piece of work.
This is the process we’re currently using, we sometimes adapt it depending on what we’re working on. So far we’ve run it with between 4 and 8 participants and that number seems to work well. We combine our design team with UX and front end developers as review participants. Everyone has to read this agenda before they take part:
Product Technology design reviews - a work in progress
*Design reviews are a means to seek structured, professional feedback and constructive criticism in a safe place.
Whilst structured, they should be facilitated in a friendly and informal environment - we went to a cafe to run our first one. (We may want to draw up a own code of conduct for what constitutes constructive criticism, but we haven't needed one yet.)
The following agenda is open to change as and when the team sees opportunities to improve…
Our design review agenda
Before the session...
Context
Consider what specifically you would like to receive feedback on. Consider how important the context of the work is. What is the intention of the work? Who is it for and what does it do for them? Will the context require a lot of explanation - would it be beneficial to email participants before the session? - don’t assume people will have had time to look at this, so you still need to be able to present the context!
Providing context is very different to pitching your idea, we don’t want you to pitch your idea!
What feedback do you need?
Consider why you want feedback. Is there a particular aspect you need help with or want to ensure works well?
Agree who will facilitate your next design review - take turns to do this.
The review:
Facilitator invites the reviewee to show their work and explain the audience, intent and context. (2-3 mins)
Participants take 5 minutes to review the work silently, writing constructive criticisms and questions on post it notes. Participants can provide negative and positive feedback and ask questions.
After 5 minutes is up, the facilitator arranges for each participant to provide their feedback. The reviewee can respond with either “thank you” or by asking a question about the feedback they received.
Whilst participants give feedback, the facilitator creates a task list based on the feedback.
Whilst tempting, don’t design during the review. The review isn’t a place for solutioning, it’s a place to give and absorb feedback.
After the review:
The reviewee takes the task list away for consideration.
It is up to the reviewee to decide what feedback they will take action upon. In their own time, the reviewee should feedback to the group which feedback the acted upon and which they didn’t and why.