Improving how we ask for design feedback
The insights gained from well structured feedback are valuable, but poorly structured feedback can stall or hinder progress
Asking for design feedback is an essential part of the creative process, and can be difficult to master. The best approach to gathering feedback can be contextual. Is feedback internal or from the client? Is it grounded within a trusting working relationship between colleagues or from new clients? The insights gained from well structured feedback are valuable, but poorly structured feedback can stall or hinder progress.
In the past, we’ve experienced different challenges when gathering feedback on internal projects. We’ve sometimes ended up designing by committee, with too many folk involved, all holding different opinions. Or we’ve accidentally ended up prioritising the loudest voices in the room by gathering feedback in meetings. With people on different client projects, it can be hard to allocate time to internal work. So there’s also the issue of giving everyone enough time to look at the design in question before asking for feedback.
A trial process for asking for internal design feedback
When we were designing dxw’s first ever Impact Report (coming soon), we had an opportunity to try a different way of asking for internal feedback. So we:
- asked for feedback early, and on an annotated design file in Figma
- left some short but focused guidance in the Figma file explaining how we’d like the feedback to be given
- gave a select number of people on the impact report team access
- gave the team a chance to digest the designs a week ahead of a design meeting to discuss which aspects of the report we’d iterate on
We asked people to use the comment feature in Figma and to:
Give individual feedback
We explained in the guidance that we wanted to try and avoid designing by committee, or disproportionately centring some voices and leaving less room for others. We took a trust-based approach and asked that our team try and not look at anyone else’s Figma comments, but concentrate on their own instead.
Let your feedback advocate for users
We reminded everyone about the Impact Report’s main user group to encourage as much empathy with users as possible.
Be specific and clear
We asked for feedback to describe any problems and to explain why, avoiding solutions and explaining any potential pain points.
Celebrate the good
We also asked for positive feedback because it’s helpful to know what we could do more of.
As part of the guidance, we explained that we wouldn’t reply to comments directly, but that they would be gathered together, and fed into, the decisions for the next iteration of design. This set expectations and avoided any back and forth about individual opinions.
Our delivery lead collated the feedback. Then, in a structured meeting that included our content team, key stakeholders, developers and our designer, we discussed what areas of feedback we needed to use to iterate the designs, and which areas of the design were ready to build.
This set the wheels in motion for the production team to start scoping the design early.It also meant that our content designers and our interaction designer could work on the sections that needed their attention.
What have we learned from this experiment?
The biggest win from this approach was that it gave everyone an equal voice. Allowing a selection of team members to provide individual unbiased feedback in their own time, meant we provided the opportunity for all voices to be heard and taken forward. And, by including voices that would be involved in all stages of the impact report production, we were also able to make confident design decisions on what to iterate, and what to keep fairly early in the design process.
Some things weren’t perfect – we couldn’t hide others’ comments in Figma, and we only provided a single way to give feedback. But, overall, the process worked really well, and we discovered some useful practices that we can build on and use in our feedback process in the future.