Get more out of design reviews

I’ve reviewed a lot of designs. It’s a sign of healthy team that they share work to be reviewed. When I ran NHS Digital’s weekly design meet-ups I made sure to encourage this as much as possible.

Sometimes it can be hard to know where to start with some feedback. Particularly beyond some gut feels or likes or dislikes.

But once you get rolling it gets easier. And you find you start really helping. Particularly if the feedback is constructive or open to allow the designer to talk through their ideas.

I’ve also experienced a lot of designers who were very reluctant to change designs or scared of feedback. And you find that they’ll put your feedback into the “backpocket” to never be thought about again. Which is frustrating if you’ve made a mistake before and are watching someone else make the same one. But you do find that making the change or improvement their idea can work. And the way to do that is to use questions to guide them, you and everyone in the review.

The structure I use

Here’s what I do. Let me know if you do anything differently. If the designer has made a few of these clear already. Skip a section. These are the more generic chunks I use:

What feedback is useful right now?

A lot of designers getting used to having their work reviewed share their work too late. So sometimes you find there’s not much that can be changed before research or build. But ask about what sort of feedback they’re after. It might not be what you give them. But expectations are good at the very least.

The context of the design?

A good storyteller very quickly sets the context of where a design sits within a product or journey. If that wasn’t clear confirm the scenario and context something will be used. There’s a massive context difference between most sales sign up forms and something you use because you’re sick. Is this something pays for? Or has to do?

What problem are they trying to solve?

What thing are they trying to make clearer? What issue needs solving? Is there data to prove that. Is that something they can control or improve here? Is this the best place to do it? Or the only place we can control for now? At the heart of a good review is being honest about whether we’re going to make the impact we expect. And the cost or effort to do that.

Sometimes the problem doesn’t feel very important. And it’s great to talk about. And if a designer can’t explain the problem they’re solving it’s a sign they need to think it through some more with whoever set the issue or opportunity.

What else have they tried or explored?

Good design is iterative and goes through loops of change and creation. Sometimes in a review we can also suggest ideas people have discarded. Ask them what else they considered and why they didn’t go with them. It’s often a very revealing part of discussion.

It’s also worth considering who they’ve worked with to explore a design. Have they talked to any engineers? If not, they might need to explore some other things if technical constraints exist.

What do they think is the weakness?

Instead of telling them what you think works and doesn’t. Get the designer to talk through where they think things are weak. I know personally when I have a worry about a thing being weak it often is. And talking it through can help me design something better. Or be at peace with that issue.

How and with who are they going to prove their thoughts are right?

A good process works out if something works. How will they do that? Who will be included in that. Who isn’t involved? And will that cause issues. If they’re going to build it without testing it first, how will they mitigate any issues or rapidly change?

What could go wrong, and how people could recover?

Things are always going wrong. What happens if someone inputs something unexpected? How recoverable are things? Will the user be guided to success or is it a painful process? Get the designer to walk through what thought they’ve put into this.

It’s quite common for teams to spend a lot of time on the happy path. But we all know from daily use of services and products that’s not always true.

Does it align to style guides, product journey and typical use of the component?

If you know these rules this is easier. But ask how it reuses existing styles and whether anything changes or uses things differently. A good designer is cautious about changing or reinventing patterns that work. And knows when to use them and when something new is needed. If it is different they should be able to justify it. And be believable.

What thoughts have they put into accessibility and inclusion?

Have they thought about how people on different devices and using assistive tech will experience the thing? What about people with disabilities? How have they thought about the impact of the service will be on people? Will it make it easier for people to use the service or product? Who have they not included and will they be able to take the steps to do resolve that?

What happens next?

I like to end a session finding out what they’re doing next with the feedback and the design. It’s a good chance to open up the choice of coming back with some changes or the feedback from going live. A good design process keeps evolving. When something is “design and done” it’s a bad sign and carries a lot of risks if things don’t work.