When it comes to web design, collecting feedback from clients can be a real nightmare.
We’ve all been there: never-ending spreadsheets, frantically annotated screenshots, dozens of frustrated emails... it can turn into a real mess.
Plus, you have to deal with the other side of the equation: your team.
Designers and engineers hate when client communication isn’t flawless. It's too easy to get caught up in endless back-and-forth about specific bugs and improvements ideas.
So how can you balance it all, and ensure you can carry out your web design project—without a three-day headache or a disgruntled client as a result?
There’s a lot of advice on getting better feedback from your clients out there. But to be frank, tips like “have regular meetings with your client” or “set deadlines for every task” are a little too generic for us.
So, at Marker.io, we’ve decided to get down to brass tacks. We've put together our best pointers to improve client communication during web projects.
In this article, you’ll learn:
- How to get better design feedback from clients, and how to educate them on the specifics you need from them to advance on their projects;
- How to organize and categorize feedback—for quicker issue resolution, and to reduce stress on the team;
- How to reduce back-and-forth emails with your client;
- How to improve and streamline your bug reporting process.
By the end of this post, you will have a better idea of what a good client feedback process looks like.
Our goal is to help you complete your next web design project faster—and more efficiently.
We have quite a lot of ground to cover, so let’s dive in!
Get better design feedback from clients
If you’ve been in the web design industry for a while, this won’t come as a surprise to you: client feedback is everything.
As a matter of fact, it is probably part of your routine to ask for product feedback when sending deliverables to customers.
But, most web design agencies struggle with receiving good input from their clients. Often, it is vague, incomplete, or technically incorrect—in other words, impractical and difficult to act upon.
This turns into a growing frustration. Not only for the web design team, who doesn’t have enough information to work with, but also for the client—who will often fail to state what needs to change.
The solution to this problem is twofold:
- Ask specific questions. The more vague your feedback questions, the more vague the answers will be. Do not expect a client with no experience in web design to share console logs with you, or tell you what screen resolution they are using.
- Different production stages need different feedback. If your client still has negative feedback about the font you used when you’re already in post-build... you haven’t been exhaustive enough when fixing issues in the earlier stages.
We’ve prepared a list of questions you can ask your clients at every stage of the process. Don’t hesitate to incorporate your own!
Pre-design feedback questions
Ask these questions after an initial meeting with the client, to confirm that you are on the same page.
- Does the style guide fit your requirements?
- We are going to be using fonts A, B and C, as well as the following colors. Are there any nuances you’d rather see?
- Here’s what we had in mind for general site structure. Does anything need to change?
- Are these photos/graphics OK to use?
Pre-build / post-design feedback questions
Ask these questions after sending the client their mockups for a new site. The goal is to increase efficiency, as you don’t want to be having to re-design a menu in the post-build phase.
- Are all elements (menus, banners, images) in the expected spot(s)?
- Is the brand’s visual style clearly communicated throughout the site?
Post-build feedback questions
It is at this stage that you should expect the most feedback from your client.
If anything doesn’t work now, they will file a bug report for it. Try to be as comprehensive as possible.
- Is anything not working as expected, or broken (images, custom code, links…)?
- Are there any major user experience issues?
Issue-specific technical feedback questions
In the post-build stage in particular, you will need the client to share more info.
We're looking at the technical stuff here: operating system, browser, viewport, and more.
This will make it easy for developers to reproduce bugs on their end.
Keep this checklist at hand for when the situation arises:
- What is your operating system?
- What browser did you use?
- What was your viewport?
- What is your device pixel ratio?
- Can you share the console logs?
- Can you provide a screenshot of the issue (if relevant)?
Customers that are not too tech-savvy may have a harder time answering these. If this happens, you can use a tool like Marker.io to automatically capture this this info and share it with your design team:
In a nutshell
If you want to receive better, actionable feedback from your customers, the best advice we can give you is this: help them help you.
Most importantly, you should guide them towards giving you the information you need to advance on their project.
Be as specific as you can. Avoid open-ended questions like “what do you think?”.
Rather, go for “do the colors fit the brief?”, “is there any image missing?” or “is there any element you would place somewhere else?”.
Organize and categorize client feedback
Now that we’ve learned how to get the feedback we want for our web design projects, let’s get to the next logical step.
Turning feedback into readable, structured data.
As project manager, it will fall down to you to categorize feedback—and then assign specific team members to specific issues.
The power of a well-organized feedback process is often underestimated. Most teams tend to centralize everything and have two to three different labels to try and categorize issues and bug reports.
Sure: for smaller projects, this is completely fine.
But when many parties are part of the testing or QA process, basic spreadsheets are no longer enough.
As a matter of fact, they will transform into a mess that no project manager should ever have to deal with.
Our best tip: share access to whatever issue tracking you’re using with your client. Two advantages:
1) it's easy for your client to track your progress;
2) it reduces the amount of “so how are we doing on bug XYZ”-emails you’ll receive.
For this post, I'll use Trello as an example, but there’s 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, 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:
You can take this to the next level by using automation to assign team members to bug reports.
You could also display different report forms depending on the reviewer:
Good feedback management is paramount to a successful web design project, and this is why we made it a central part of our software at Marker.io. Try it out for yourself here.
Reduce back-and-forth emails
Even with great organization, emails are bound to be a part of your daily routine as a web project manager.
The emails themselves are not the problem: it tends to become overwhelming when clients reference a bug they reported over 3 months ago… or worse. How are you supposed to keep track of it all?
At Marker.io, we have a simple, 3-step checklist to make sure client emails are not taking up most of our work time:
1. Proactively reduce back-and-forth
This is part of your work process already: before starting a new project, you’ll have a video call with the client to try and figure out what work needs to be done.
But these calls tend to remain practical, quick, and only touch the surface: “I need a new website A with custom code to do B”.
It is tempting to agree to everything your client requires, but you are setting yourself up for weeks of frustration if things don’t go as planned.
This is your opportunity to discuss potential problems at length as well as solve them ahead of time.
For example, "if integrating ABC with XYZ doesn't work—what other APIs are you open to using?".
Another way to get the most information out of the way from the get-go is to use a pre-design website design questionnaire.
By having your customer answer questions you know will come up at some point in the next few weeks, you are saving yourself a ton of time (and headaches).
2. Move away from e-mail when possible
This one might sound like a no-brainer, but be careful: 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 with your client (maybe during the initial call?) to educate them on the tools your team uses to deal with feedback.
You can share access to your bug reporting software, or—even better—use Marker.io to discuss specific issues separately.
This ensures no mixing up ever happens, and as a project manager, there will be no confusion on which bug report the client is referencing:
3. Write better emails
If you do end up relying on email, stay away from open-ended questions.
Depending on the scale of your project, you’ll end up with a huge amount of feedback—which often takes ages to parse and recategorize.
First, take the time to focus on what matters the most for the project. For example, showcase the most recent pages completed, point out which bugs were fixed, and outline what the next steps are.
Then, ask specific questions:
- Are all elements in the proper place on these pages?
- Can you try to replicate these bugs on your end now?
- Are we still on track for tasks X and Y?
As always, the goal here is to avoid creating a whole conversation. Just stick to “what’s next” and close the discussion as soon as possible to avoid back-and-forth.
Improve your bug reporting process
As web developers, defect reporting is second nature. But what may seem like routine to you can be a daunting task for your customer.
Improving your bug reporting process, and making it as convenient as possible for your client to be a part of your QA process is in your best interest.
The better your clients understand your workflow:
1. the easier for you to read through their bug reports;
2) the faster you can fix bugs.
We suggest sharing this section with your client to make sure both parties are on the same page.
Understanding which bugs are worth reporting
This is step one for a reason.
We’ve experienced this countless times.
Duplicate defect reports, tickets for issues that have already been fixed, or ultra-low priority bugs all pile up to ruin a project manager’s day.
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 an issue you can save for later.
So, which bugs are worth reporting?
Typically, three 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. You also need to make sure you encounter the exact same problem every time.
a) developers most likely won’t be able to retrace your steps, and thus can’t fix the bug,
b) if this bug occurs only infrequently—then the end-user also only has a low chance to encounter the problem ever again.
- The bug has not yet been reported. Take the time to perform a quick search in your favorite project management software 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.
- Priority is medium too high. This is mostly relevant for time-sensitive projects. Stuff like typos, broken links or missing images (assuming they don’t prevent the end user from operating the website).
Those are best kept for later and are likely to be fixed alongside other, “main” bugs.
By following the three simple rules outlined above, you’re reducing the number of bug reports a fair amount—and your developers will thank you for it.
How to report bugs effectively
Reporting bugs effectively comes down to great organization.
First of all, 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.
Next, write down the steps 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 client (for more serious bugs only).
In 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 website in an unexpected way.
Tools for bug reporting
Thankfully, tools exist and make the whole process a breeze. If you’re still using emails and spreadsheets for bug tracking, it’s time to move on.
With a tool, not only do you centralize every report and have a clear overview—you also allow the client to work directly with you.
There’s plenty of options out there:
- Marker.io: That's us! We developed our tool specifically for web design agencies, and it is perfect for QA testing. Take screenshots, annotate them, and immediately send technical data to your favorite project tool. Give us a try!
- Trello: Easy to use, even for non-technical people—which makes it a great choice when it comes to client communication.
- Teamwork: Have your client add bug reports as tasks immediately on Teamwork. Or, assign a middle-man to fetch the information from emails and then organize it.
- …and many more!
We hope you enjoyed our guide on how to get better client feedback in 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.
Let us know if you’ve got any questions or feedback about this guide in the comments!