Running a review

How to introduce giving feedback

Ask everyone to focus their feedback on the work, not the person who wrote it or their skills. You could say things like:

everyone did the best work they could with the information they had at the time
every comment is valuable
think about how the person presenting the work is feeling about sharing their work at an early stage
be honest and constructive so that we can make the content as useful as possible
positive feedback is still feedback
it's okay if you do not have any feedback

Ask people to try to avoid saying things like:

‘That will not work,’

‘That word’s not right’

Ask people to try to make suggestions and ask questions about the design or content like:

‘Have you thought about trying this?’

‘How does this part help the user’?

‘What’s the reason for including this?’

Ask people to add some context so that people know if what you’re saying is based on:

research or experience
what you’ve seen on another product or service
based on your opinion or feeling

You could say:

‘When we tried this on [this] product we found that it worked better to do [this] rather than [that]’

‘I read an article in [this website] saying that recent research suggest that users find [this] easier to read than [that]’

‘When I look at this design or sentence it makes me feel like [this]. I’d be interested in what other people think. Would [something else] help avoid that?’

Presenting the work and what you want people to do

Let everyone know how you, or people presenting, are going to share the design or content. Include the timeframes for presenting the work, making comments and discussion.

Be clear about whether you if you want people to:

write down comments during the presentation
raise comments during the presentation
put their hand up to make a comment after the presentation

During the presentation explain the problem that the design or content is trying to solve. Let people know where the user will find the design or content when it’s live or ready.

Remember that you are familiar with the content and the group is not. If in doubt, share less design or content.

You can explain your process and thinking but try not to ‘sell’ the content.

How you present the work depends on what you are reviewing and what you want from it. Explain what you want feedback on. This could be areas that you feel least confident in. It could also be something that you have discussed regularly in your team without coming to a decision.

When to share the material

Sharing material on the day creates a collective response. However, some people prefer to see content or design before the session. Either way, you need to give people time to think about their feedback.

Balance how you run the session between how people prefer to work, what is possible in the time and what you want to achieve.

Example 1: Design of a date picker.

You could say:

Problem: Explain the problem that the date picker will solve, for example:

‘There are many different ways for users to enter a date in Co-op products and services. Users sometimes struggle to enter a date manually because the keyboard does not work or the field does not match. Different designs may also slow users down because it is not familiar.

We want to design a way for Co-op users to enter a date which is accessible, achieves the outcome for the product and aligns with other Co-op experiences.’

Discovery:Talk through any user research, external best practice or insights you found while exploring the problem space

Initial Ideas:Show any prototypes or sketches

Design:Talk through the proposed design in Figma and what you want feedback on.

Example 2: Long form review of content in a glossary

You could say:

Problem: Explain the problem that the glossary will solve, for example: ‘We know that people come across words connected to agile working that they do not understand.

Discovery: Talk through any user research or insights you found while exploring the problem space.

Initial ideas: Show any prototypes or sketches if it’s relevant. You could also highlight the process you have followed and why you have made your decisions so far.

Design: Talk through the proposed content and what you want feedback on, for example:

‘We’ve created a glossary which is a list of words or terms that people might come across when they are learning about agile ways of working. Each term has a description so that people know what the term means. It is on the test site now. After this review and amends we’re making it live on the Experience Library’

You can also explain what the content or design is not, for example:

‘The glossary is not the place that people come to learn how to use agile methods. That is what the rest of the site is for and there are links through to methods.’

Constraints and blockers

Let your team know what stage you’re at in the design. This will help people provide the most useful feedback for you.

This could include:

the feature or element is a prototype so we can easily make big changes if we need to
this is going live tomorrow so we need to know if we’ve missed anything
If there is anything that cannot be changed due to technology or other decisions
any information that the user will experience before or after what you are showing today
what aspect of the design or content do you want feedback on, for example: how a specific feature works, the overall design or layout, do people think this will be useful, does a section of content help the user to get from one point to another in the journey

Next section of the review guide

Go to gathering feedback.

Previous section of the review guide

Go to starting a review.