How do you give website design feedback that’s actually helpful—and most importantly, actionable—to designers and developers?
In this blog post, we outline the best practices to give and receive website feedback, for all parties involved.
We’ll show you how to:
- As a QA or client, share your feedback to a designer or developer in a way that’s actionable (and gets your website fixed much faster);
- As a designer, collect and manage feedback items from your clients.
We’ve all been there: color-coded spreadsheets, frantically annotated screenshots, dozens of frustrated emails... it can turn into a real mess.
Endless revisions are no fun.
So how can you carry out your web design projects—without a three-day headache as a result?
We’ve organized this post into two different sections:
- The “client” section: tips & tricks to make sure you get the most bang out for your buck when giving feedback on websites. Project managers, show your clients this! Jump to this section ->
- The “project manager” section: a complete guide on how to set up a flawless website feedback collection process. Jump to this section ->
We have quite a lot of ground to cover, so let’s dive in!
How to give website design feedback
Agencies make it part of their routine to ask for product feedback when sending deliverables to customers.
But, most struggle with receiving good input from their QA team or clients. Often, it is vague, incomplete, and impractical.
Don’t be that guy!
In this section, we’ll look at a few easy ways to give your designers web design feedback that they will love.
1. Give feedback early, and often
Different production stages require different feedback.
During pre-design—before the project even starts—be as exhaustive as you can:
- Think of your target audience, and turn these insights into a style guide;
- Show the design team fonts, color palettes, and other websites that you really like (copying is not cool, but inspiration is fine!);
- Provide an idea of the general site structure (hint: use Whimsical for this).
When the first mockups come in (during prototyping), focus on design first:
- Are all design elements (menus, images, forms…) in the expected spots?
- Is your brand’s visual style clearly communnicated throughout the site?
And finally, once your website is live, focus on functionality:
- Is anything not working as expected, or broken (images, custom code, links…)?
- Are there any major user experience issues?
Give your feedback in small chunks instead of everything at once, making the review process more manageable.
Start with specific/key web pages, like the homepage for example.
2. Be actionable
Remember that if someone who has been working on your website for weeks misses a bug, it can’t be very obvious what the issue is.
You want your developers to be able to easily find or reproduce it.
To that end, you’ll need to share a lot of info:
- Operating system
- Console logs
- Visual feedback, like a screenshot with annotations, or video recording if necessary
- Steps to reproduce
Alternatively, you can use this neat checklist for all bug reports going forward:
3. Be specific
For a lot of designers, developers, and other creatives, client feedback often looks something like this:
- "I don't like this."
- "This needs to be different."
- "It's not working."
- "Can we move this?"
Before you know it, you're stuck in an endless feedback loop of comments and edits that eat up time and resources.
To avoid lost productivity and frustration, be specific about comments and changes.
Use precise language. Instead of:
- “This font doesn’t work.”
- “This font is too small. Use the style guide we provided, and blue for links.”
As you go through the design process, it helps to have a visual record of the edits and requested changes to the site.
The old way of gathering feedback involves having clients write out a list of the changes they would like to see. Then, awkwardly trying to include written instructions for how to find the page they're referring to.
This can create a great deal of frustration for designers who must:
- Try to decipher the client's notes;
- Track down the page or item;
- And finally, hope they make the correct change on the next iteration.
4. Proactively reduce back-and-forth
Whenever you have meetings with your designer, try to discuss every requirement at length.
Leaving things “less important” that “could be done later”, in some cases, means going back to the drawing board.
Some agencies will use a pre-design website questionnaire. If not, ask for one.
Asking questions you know will come up at some point in the next few weeks will save all stakeholders a ton of time (and headaches).
5. Use tools rather than emails
Just because Slack is fast and easy doesn’t mean it won’t take up less of your time.
Rather than instant chats, take some time to adopt your designer’s tools. Some may ask you to work straight from their issue tracker.
Others use an annotation tool like Marker.io. There, you can discuss specific issues separately, ensuring minimal confusion:
6. Understand which bugs are worth reporting
Before reporting a bug, ask yourself: is this worth reporting?
Sure: you want your web design project to be flawless. But at the end of the day, time is of the essence.
If the defect only sometimes occurs on an obscure page that the end-user rarely ever sees... this is probably not a big deal.
So, which bugs are worth reporting?
Typically, two conditions come into play here:
- You can reproduce the bug with ease. If you can’t reproduce the bug—especially if it only occurred once—do not file a defect report. Developers won’t be able to retrace your steps either.
- The bug has not yet been reported. Take the time to perform a quick search in your issue tracker to check if someone else already reported the issue. You don’t want to waste valuable dev time trying to reproduce a bug that has already been fixed.
By following the two simple rules above, you’re reducing the number of bug reports a fair amount—and your developers will thank you for it.
7. Report bugs immediately
If you try and file a report days—or even hours—after noticing an issue for the first time, chances are you won’t remember the steps taken to reproduce the bug.
This leaves a potentially critical defect for the disgruntled end-user to find.
As soon as you find a problem, write down the steps to reproduce clearly, but in as few words as possible.
Large projects typically have hundreds of reports, and you don’t want to waste a developer’s time reading long-winded sentences.
Bug reporting forms must be impeccable themselves:
At Marker.io, we like to keep it simple, but effective: steps + result + what you expected to see instead.
One such report might look something like this:
As a last resort, we sometimes recommend getting into a quick call with the designer (for more serious bugs only).
In some cases, showing step-by-step how to reproduce a specific bug is faster than trying to decrypt a long-winded bug report.
The developer also gets to see if the client/end-user is operating the app or website in an unexpected way.
Your next steps
How your web pages ends up looking depends a lot on how well you and the designer manage web design feedback.
- Decide, with your agency, on a process to collect feedback in an efficient way.
- Decide how often you will need to be involved in the feedback loop, and what each phase entails in terms of feedback.
- Use an interactive tool like Marker.io to report feedback, discuss issues at length, and keep on top of all current issues statuses.
- Enjoy your flawless new website!
Receiving and managing feedback as a project manager
1. Set up your issue tracker for client feedback
Most of your client feedback lives in emails, Slack messages, and meetings notes.
This creates a lot of back-and-forth and it’s near-impossible to properly keep tabs on everything.
We used to be a web development agency—here’s how we did it back then.
Your first issue tracker
The first step is to create a source of truth with all feedback. We will call that your issue tracker, which is a fancy term to say “feedback tracker”.
Tell your team and clients: if it doesn’t exist in the issue tracker, then it doesn’t exist at all. Period.
As project manager, it will fall down to you to categorize feedback—and then assign team members.
Every issue in your tracker should have at least these four labels:
- Reporter. Who reported it, and who should be kept in the loop for more questions and notifications on status updates.
- Assignee. Who is best suited to fix the issue: designer, developer, content creator?
- Priority. How severe is the issue?
- Type. Is it a content problem, a visual problem, or a workflow problem?
It can be as simple as a Google Spreadsheet or Excel file:
Whatever bug report template you choose to use, make sure your clients understand it and have access to it.
While a spreadsheet is a great starting point for smaller teams, it can soon turn into a nightmare for a few reasons:
- Your team has to update it constantly. In most cases, your team already works in a task management tool like Trello, Jira, or Asana.
- You can’t communicate. It’s hard to have a conversation on a spreadsheet. After 100 comments or so, Google Docs is a mess, too.
- Not great for bugs. It’s not great for technical bugs which require a lot more information: console logs, environment data, steps to reproduce, etc.
You can use any project management tool, plugin, or issue tracker that you like.
For this post, I'll use Trello as an example, but there are dozens of great bug tracking tools out there.
Whenever your client files a new piece of feedback, you should immediately categorize the issue, then assign a team member to it. With Trello, it takes just three clicks to go from client report:
To a complete, well-organized list with issue type (UX design, backend…), priority, assignee, and due date:
The best part? Your team can filter tasks directly from Trello to see what needs to be worked on next:
Ok! Now that your issue tracker is set up, it’s time to get some feedback and bug reports from your website straight into your issue tracker.
2. Collect website feedback to your issue tracker
There are 3 ways to get design feedback into your issue tracker:
- Collect -> transfer. Collect feedback from clients via email, Slack messages, and meeting notes, then have someone make sure everything is in the issue tracker.
- Client access: Invite your clients to your tracker and ask them to create issues themselves.
- Website widget: Collect visual feedback directly on your website with a widget like Marker.io that will feed directly into your team’s issue tracker.
Option 1: Collect → transfer
The “Collect→transfer” option gives you maximum control, but it’s very time-consuming.
You will have to transfer everything the client sends you in your issue tracker, then back to the inbox to update your clients.
Option 2: Client access
The second way would be to give your client access to your issue tracker and let them create issues directly.
The problem with this approach is that you might not want to expose your internal tools to your clients. Plus, it forces your client to adopt yet another tool just to send feedback.
Next thing you know, they might end up sending emails again because it’s too much hassle or they can’t get it to work, and you’re back to square one.
Option 3: Website widget
The best way for clients and QA to send you feedback is to use a website feedback tool on your live websites.
It’s as easy as using one of those live chats you see everywhere on the web.
With a tool like Marker.io, here’s how easy it is for your client to report a bug or share an idea:
The best part is that Marker.io is in constant sync—in real-time—with your issue tracker.
This means that every time your client clicks that “Create Issue” button, your team will receive a neat report like this:
What about technical bug reports?
Nothing makes developers angrier than an unclear bug that they struggle to reproduce, let alone understand.
Any of these sound familiar?
- Which page were you looking at?
- What browser are you using?
- Do you have technical errors in your console?
That’s why it’s important to have a checklist of items to ask your clients when they report bugs—you never know what developers might need.
The absolute bare minimum should be:
- A title & description with steps to reproduce
- A screenshot, with annotations if possible
- Page URL
- Browser, environment info, and console logs
Thankfully, when your clients report feedback with Marker.io, our widget will capture all this information automatically.
Now find me a developer who wouldn’t want to get bug reports like this!
3. Communicate with your clients
We now have a strong feedback tracker and have options for how to get your clients to submit website feedback.
But what if your developer has more questions? For example, what if your client does not like an image, but fails to provide an alternative?
Depending on your setup, you need a way for your team and client to communicate .
- If you’re using a spreadsheet, create a column “notes/communication” where anyone can add questions.
- If you gave the client access to your internal issue tracker, most tools will have a “commenting” section.
- If you’re using Marker.io to collect feedback, our tool also comes with a feedback portal.
This is how you can communicate with your client without giving them access to your internal issue tracker.
For each issue, your team can start a chat with your clients.
The best part is all communication will be logged automatically by the Marker.io bot into your internal project management tool, too!
Pro tip: whatever method you use, make sure that all conversations are organized around each issue. Avoid starting a single conversation thread that discusses multiple issues at the same time.
4. Notify clients when issues have been resolved
In the agency world, you live and die by your reputation. A happy client will stick around and refer you to new business.
That’s why you should offer clear and transparent communication.
If your clients are going to take the time to offer feedback, the least you should do is let them know when their feedback has been addressed.
Whatever method you use, every issue a client submits should have a status. A good starting point is:
If you’re using a spreadsheet, add a new column with these statuses.
However, you still have to ask your team to update yet another tool just to let your clients know how it’s going.
But that’s annoying...
As a developer, you job is to fix bugs and address feedback. It’s not to send email updates for every little change, right?
Again, we have good news.
If you’re using Marker.io to collect and collaborate on client feedback, our 2-way sync with your issue tracker will make this process seamless.
When your developers mark a client issue as “Done” in your issue tracker, Marker.io will automatically mark the issue as “Resolved”—and send notifications to your clients.
Check it out:
Your next steps
At Marker.io, we used to run a web design agency, so we know the pain. Managing client website feedback is no easy task.
- Set up your issue tracker as your “source of truth”. Forget emails and Slack messages. You can start with a spreadsheet, but we recommend a tool like Trello, Jira, or Asana.
- A way to collect feedback & bug reports into your issue tracker.
- A way to communicate back-and-forth with clients.
- A way to update clients when issues have been resolved.
- Start a free trial with Marker.io to automate points #2, #3, and #4. No credit card required!
We hope you enjoyed our guide on how to manage feedback during web design projects.
You should now have a clear idea of what a good client feedback process looks like. The next logical steps are:
- Adapt your tools to be able to include the customer at some step of the QA process.
- Ensure good organization of feedback going forward—and educate your client on the best ways to give feedback as well as file bug reports.
Got more tips? Send ‘em our way via Twitter or email!