Getting feedback on a design from a client is an often difficult process. Nobody really enjoys it, and the expectations on both parties are rarely communicated effectively up front. I’m here to put that right today! (Never hurts to dream big … !). So, first, what are we talking about here …

Every web design & development project goes through a phase where the designer has worked their little cotton socks off and has to show their work to the people who are paying for it (who, lest we forget, are the most important people in this project). This is fraught for a number of reasons.

Firstly, the designer has been working away on this design for however long, poring over the brief, researching competitors, studying the sitemap and so on. They’ve likely screwed up any number of metaphorical drafts, arcing each one neatly into a wastepaper bin in the corner of their office. But now, there’s no hiding: they have to present their work. No wonder they’re nervous.

Secondly, the client has been sitting anxiously waiting for this design work. It’s possibly their first tangible deliverable after agreeing to commit thousands of pounds on your services. Yes, they’ve seen the sitemap, yes they’ve approved the content … but really, what they want is pretty pictures (see: well designed websites). They’re excited, slightly nervous (what if everything has been misunderstood? will the designer have remembered to include pictures of their kittens?).

The whole situation is tense. But it needn’t be.

design feedback

 

The kind of approach outlined above is what I think of as the ‘Big Reveal Hypothesis’ … it’s a real ‘them and us’ way of working. You’re sat in your siloed office, they’re sat in theirs. And once every so often you meet together, clash heads, tweak, twist and pull at whatever it is you’re discussing, and then retreat to your respective corners. You carry on like this, often stuck in ‘design revision hell’ with changes going back and forth, contract squabbles (‘we agreed 2 rounds of changes’ … ‘yes, but what constitutes ‘a round” … and so on)

It’s not ideal. At David Horn Design we try and work on a much more collaborative basis. We try and share design work throughout the process, iterating quickly so that the client can see the impact of the conversations they’re having with you, and so that nobody is left stunned during the ‘big reveal’ when you’re showing the work.

So, perfect. Share the work as you go on, there’ll be no surprises, and everything’s dandy. Well, not quite.

Fundamentally, although you – the designer / agency owner – are well used to the concept of design feedback (mostly: ‘yes, we can make your logo bigger’), your clients are not. And although you think you are good at asking for and dealing with design feedback, mostly, you’re not either.

So … it’s time for a few guidelines. How to get the best feedback on your design project:

Prepare the client for what to expect

Right at the start of the project we want to establish how to manage feedback. We need to lay a good foundation in how we’re going to work together – and avoid a lot of the conflict that can arise during the design feedback process.

It’s quite understandable that a client does not understand their role in giving design feedback – why would they? – and they will typically fall back on their personal opinions. They don’t like this colour, they prefer this font … and so on. But that can be avoided if we properly brief the client on their contribution to the process.

A natural tendency for clients – and, I’ve noticed, for life partners also (but that’s for another day) – is to express solutions rather than problems. A problem could be ‘the pink does not represent our brand well or speak to our primarily male, under 18yrs old market’. The solution – more often expressed – is ‘please change the pink to a blue’.

We need to explain to clients that although recommendations for solutions are welcome, they should try and express the underlying problem. It’s the best way to ensure that you – the designer – are able to offer an alternative solution which may be better.

So, we can tell our clients what they should focus on (the problems arising, rather than the solutions yes, but also … ) and that comes down to the business objectives. What are we trying to achieve – as a business – with this new project? How does the design support those goals? For this project – what does success look like? More sign ups, better conversions, lower bounce rate, more pages per visit … etc. and how does the design support those.

This helps take clients away from offering solutions and brings them back in to talk about how the design you’re presenting best supports their business goals.

Asking for the right kind of feedback

This can be summed up in two words: be specific. But because I’ve never used two words when two pages will do the job, there’s more …

We’re after quality feedback, and we’re not going to get that if we ask ‘so, what do you think?’. It’s too vague and again speaks to personal opinions rather than objective problem solving. We need to ask the questions that focus the client on the right things in order to assess the design.

I might start with something along the lines of:

  • do you feel the design represents the brand values (that we discussed in the brief)? If not, what are the areas of particular concern?
  • does the design reflect the information you’ve given us about your services / offering? If it doesn’t, where have we slipped up?
  • does the design reflect the balance of priorities for this project – how does it tie in to your business objectives?
  • you know your customers better than we do – do you think we have prioritised their needs & their desired actions?

… and so on. The questions asked call back to the information we collected in the brief, they are tied to specific objectives and they are specific, allowing the client to communicate clearly without falling back to personal opinions. The client has to articulate why the design falls short – they have to do that in terms of tangible problems.

design feedback

Collecting feedback in the best way

Okay, so this is an area where we still sometimes struggle. I stand behind the process we have developed over the last 20 odd years, but if there is one phase of it that is still in a state of flux, it’s the process of collecting the feedback.

Whatever I do, there are elements that are crucial though:

  • consistency. It is no use getting feedback from clients in an email, then on Slack, some of it in Asana (or your PM tool of choice), and some of it over the phone. Gather feedback in one place – or have a process by which feedback is pulled together from multiple places into one place. That’s a pain, but sometimes unavoidable if you’re dealing with larger teams all of whom want a voice. Which brings me to …
  • … it is always best (and I mean always best) to ask the client to consolidate feedback on their end and present a unified front before they share it with you. Now that does not mean other voices get excluded – the ‘feedback review’ meeting can include the team (within reason – I find that more than 4 client voices in the meeting can be hard to manage) – but the feedback is presented as one, to prevent opinions developing in the meeting and anything approximating internal politics playing out on your Zoom call.
  • if it’s possible, collect feedback visually. And this is the bit where I’ve struggled recently. I’ve been using the tool MarkUp for sharing design work recently, and I like it – particularly because it does not require the user to open an account, and also because it can all be done collaboratively. Other services are out there: BugHerd.com , Marker.io, and others. I also share work using an XD link, but that requires the user to have an Adobe account if they want to mark the design up visually. Overall though – whatever tool you use, having someone visually mark up your design work is hugely more helpful than them saying ‘oh, it’s the button on the right on page 4 – the one that goes to the other page’. Avoid that completely by just having them draw on the screen.
  • finally, after the feedback session, type up the notes and add them to your Project Management tool (we use Asana) – make ‘feedback notes approval’ a to-do that has to be completed by the client, so that they are effectively signing off on your understanding of that meeting.

Get through all of that, and you’ll have a decent system for gathering and collating feedback – one that will build trust with your client by allowing you to focus on specifics, remove opinions from the process (and instead focusing on problems), and helping your client to play a full role in the process.

Phew! That’s a lot of stuff. But it’s worth it. Making this process as smooth as possible is, in my experience, the surest way to make sure everyone is on board with the project throughout the process.

UPDATE: After writing this post, the people behind Marker.io reached out to me, having picked up on the pain point I was having about typing up notes into Asana. Turns out that Marker.io can automatically create to-do’s / list items within Asana and that it syncs both ways. So, mark something as complete in Asana, Marker.io automatically updates – and vice versa. Now, that’s pretty cool. Their starter plan comes in at $37 per month, so this is a premium service – but judging by the proactive way they reached out to me, I’d definitely recommend checking them out. Always good to see companies be proactive like that.