How to Provide Good Feedback on a Web Design Project

Providing good feedback to a designer on a web design project is important if you want a successful outcome. Bad feedback can impact the project timeline, increase the scope (and budget) of the project, and affect the overall quality of the completed website, leaving everyone involved grumpy and frustrated. At the end of the day we all want a successful outcome and a final product that meets the project goals, so let’s talk about how we can achieve that!

There are a lot of rabbit holes we could go down on this topic, but I want to keep this post simple, and provide some actionable tips on how you can provide good, helpful feedback to your designer/developer that makes them go:

Instead of:

Let’s start at the very beginning

Feedback starts at the very beginning of a project. When preparing the project brief, there should be very clear goals set out, and a list of project deliverables that aim to meet those goals. Everyone involved in the project should sign off on these goals and deliverables, and thus a ‘scope’ is born. 

At each stage of the project, you should refer back to the goals and deliverables to make sure that they are being met. Every time you have a piece of feedback or a new idea, consider it in context of the goals and deliverables. Ask yourself if your feedback is helping to meet the project goals, or if it is outside the scope of the project.

It’s not a bad thing if the process of the project gets your creative mind flowing, and you get lots of ideas. However, when approaching the designer/developer about your new ideas, preface them by saying something along the lines of:

I have an idea that is probably outside the scope of this project, can we discuss what is possible?

This will get a positive response, and your designer/developer will be able to talk through:

• Whether is aligns with the project goals
• What is possible
• Whether it will make sense to adjust the scope of the project to include it or wait until the project is complete and add it after
• What impact it will have on the timeline and budget. 

If instead you tell your developer:

… you’re probably not going to get a positive response, and adding stress to your designer/developer won’t make them work more efficiently.

Feedback isn’t always needed

If your designer/developer sends you some completed work for you to review, they may sign off by saying something along the lines of “I look forward to hearing your feedback”. Some people may misinterpret this to mean “please nit-pick every tiny detail and look for opportunities to upend the whole project”.

When reviewing the work, don’t feel like you have to provide feedback if you can’t find anything to give feedback on. 

If your designer/developer did such a good job understanding and executing on the brief that you can’t find anything to provide meaningful feedback on, that’s great! They won’t feel sad if you get back to them with no feedback, in fact it may even make their day by validating the amount of effort they put in to ensure a quality product.

Examples of bad feedback

Let’s jump into some examples of what you should avoid when providing feedback on a web design project. This part of the post might feel a bit negative, but that isn’t my aim! I’m not trying pile shame on you if you’ve done any of these before (I’ll admit, I am also guilty of poor quality feedback), I just want to see more successful projects, and happier client/developer relationships ♥️

So let’s get into it, here’s what to avoid when providing feedback.

Vague and subjective feedback

Try to avoid comments that don’t provide enough detail. They can come across as lazy, and sometimes borderline passive-aggressive. Things like:

• I don’t like this
• Make this pop more
• This doesn’t vibe well
• Good grief this looks terrible

This type of feedback often isn’t helpful and doesn’t achieve anything. It will, however, guarantee two things:

• A grumpy, deflated developer
• A plethora of questions asking for additional detail from your developer so they can better understand what you want to avoid more negative feedback.

Instead, think more deeply and put yourself in the shoes of the designer receiving the feedback. Here’s some examples of how you can turn those bad feedback examples into good ones:

Instead of ‘I don’t like this’:

Instead of ‘Make this pop more’:

The call to action button doesn’t stand out in this section, can we try changing it to our accent brand colour?

Instead of ‘This doesn’t vibe well’:

The background image for this section doesn’t align well with our target audience of 45-65 y/o men. Can we try something more like this [example]?

If you’re not very good with words, that’s okay. Try to find visual examples of what you are trying to communicate and send them to your designer, sometimes this is more helpful than words anyway!

Feedback based on personal taste rather than project goals

It’s also important to separate your personal preferences from what will actually help achieve the project’s objectives. Ask yourself whether your feedback is driven by what you personally like, or whether it genuinely serves the target audience and project goals.

For example, if you’re working on a website for a luxury spa targeting women aged 30-50, but you personally prefer the bold, edgy aesthetic of a skateboard brand’s website, that preference shouldn’t drive your feedback. Your designer has likely made intentional choices based on the project brief and target audience research.

Before providing feedback based on taste, consider:

• Does this align with our target audience’s preferences and expectations?
• Is this feedback helping us meet our conversion goals?
• Am I suggesting this because I like it, or because it serves the project objectives?

The same principle applies to feedback from friends, family, or colleagues who aren’t part of the core project team. While their input might be well-intentioned, it should always be filtered through the lens of the original project goals and target audience.

Last-minute changes to important elements

Waiting until the final stages of a project to request changes to core elements that were approved early on can prolong timelines, increase budgets, and create unnecessary stress. Some examples of changes like this would be changing the brand styles and guidelines, changing to a different external SaaS software that was already heavily integrated, completely changing the brand messaging.

Sometimes these types of changes may seem small at a glance, however there can be lots of dependencies in place which will often have a domino effect, requiring changes in multiple areas of the project. This means undoing lots of work and spending additional time and resources on aspects of the project that the designer/developer has mentally moved on from (this can be an efficiency killer).

To avoid this, if you realise early on that something isn’t working, let the designer/developer know ASAP. The earlier in the process you raise concerns, the easier and less costly they are to address. Don’t wait until you see the “final” version to mention that you never liked the direction in the first place.

If you genuinely didn’t realise something was an issue until later in the project, be upfront about it. Here are some examples of how you can approach it.

Acknowledge that the current work had already been approved:

I know we approved this earlier, but seeing it in context now, I’m concerned it won’t work for [specific reason]. Can we discuss…

State that you are aware it may have timeline and budget impacts:

I’m aware this will impact the budget and timeline, can we discuss…

Be open to prioritising what is essential for launch, and what can wait:

I have an idea that may not be essential for launch, can I run it by you to see what is possible?

Let’s do good feedback

I hope that was helpful and not too divisive! If we want to see more successful projects, feedback plays a very important role. By having a clear brief and goals from the beginning, and ensuring we provide helpful and detailed feedback (when needed) through the lens of those project goals, then I think we are well on the way.