November 6, 2026

How to Give Useful Feedback on a Website Design

On each screen, record where you are, what you noticed, what you expected, and why the difference matters. Then describe the outcome you need.

A magnifying glass with a blue handle hovers over a printed contact form headed Get in touch, enlarging the Email field while the Name and Message fields stay small.

Your team or agency has shared a redesigned website or a campaign landing page for review. You need to look it over and send feedback before the next round of work.

You know the customer and the campaign, but translating that knowledge into design notes can be harder. “Make it stand out” leaves your designer guessing what matters and why.

So what should you write down on each screen? Record where you are, what you noticed, what you expected, and why the difference matters. Then describe the outcome you need, leaving room for your team to find the solution.

For a quick comment, use: “On [page, section, and screen size], I noticed [observation]. This matters because [visitor’s task or page goal]. Could we [desired outcome]?” Number the note and add a marked screenshot when the location needs explaining.

1. Agree on the Page’s Job Before You Review It

Write down who the page is for and what it should help that person do. Keep the project brief nearby, along with any agreed brand guidelines or campaign message.

For example, your starting note might be: “This page helps operations managers understand the service and request a consultation.” That gives you a reason to question a buried consultation link beyond your personal preference.

Sarah Gibbons’s guidance on design critiques puts agreed objectives at the center of useful feedback. Without that agreement, ask your team to confirm the goal before you judge whether the page meets it.

Ask what kind of feedback the team needs at this stage, too. An early design may need comments on direction, while a later round needs specific concerns about the agreed design.

Keep a notebook nearby, or open a spreadsheet or a document, whichever helps you stay focused while you take notes. Go through the design first, collect your observations, and then decide what is actually worth sending. That’s more useful than sending your designers a lot of feedback in several texts or emails.

There’s a blank feedback sheet you can print alongside this guide. Use it to collect what you notice and any changes you may want to request. Then choose which ones are worth sending.

2. Turn Your First Reaction Into a Concern

Write down your first impression before you study the page. What do you think it offers, and what draws your eye first?

Then read the page more closely. You may find that your concern changes once you understand the content, or that you can point to its cause.

D. Keith Robinson’s guide to website critique recommends exploring your first reaction. Keep an uncertain reaction in your feedback if you label it honestly.

Instead of “This looks busy,” try: “The illustration caught my eye before I saw the offer. Someone scanning this page could miss what we’re offering.”

That example describes your experience and a possible consequence. It doesn’t claim customers behaved that way, because your review isn’t customer research.

If you can’t explain a reaction yet, say so: “The introduction sounds more formal than our usual campaign copy. I’m not sure which wording does that. Could we check it against the brand guidelines we already agreed on?”

3. Give Each Note a Place, a Problem, and a Purpose

Use one issue per numbered note, with a screenshot or marker that points to the relevant part. The designer should be able to find the same place without asking which button you meant.

A useful structure is observation → impact → question or request. Lara Hogan introduced it for workplace feedback in her Feedback Equation. Erin Casali adapted it for design critique.

Use the short format above for everyday comments. When a concern needs more explanation, expand it with these fields. This practical template combines the advice rather than reproducing a published framework.

  • Where: Give the page address, section, and screen size you were viewing. Attach a marked screenshot if it helps locate the issue.
  • What I saw or did: Describe the visible detail or the action you took. Separate what happened from what you think caused it.
  • What I expected: Say what you thought you would find or what you expected to happen.
  • Why it matters: Connect the concern to the visitor’s task or the page’s agreed goal.
  • Desired outcome: Explain what needs to be clearer or easier. Label any proposed fix as a suggestion.
  • Priority: Say how important the concern is and why.
  • What’s working: Name anything nearby that should stay as it is.

Keep the location, concern, and reason in every note. Add expectations or action steps when they explain the problem. Add a preservation note when something specific should stay unchanged.

If a note involves an action, record the steps and the result. Mozilla’s bug-writing guidelines offer a useful borrowing from software reports: separate the actual result from the expected result.

Example: A Note About an Unclear Main Action

This expanded example is illustrative, not a report from a tested website. It records the size to help someone find the same view, rather than recommending a size to check.

  • Where: Campaign landing page, opening section, phone preview at 390×844. Screenshot marker: circle the button.
  • What I saw: The main button says “Continue.” The headline offers a consultation, but the button doesn’t say what happens next.
  • What I expected: A clear sign that this starts a consultation request.
  • Why it matters: Someone considering a consultation may pause if they can’t tell what comes next.
  • Desired outcome: Make the next step explicit. One wording to try: “Request a consultation.”
  • Priority: Worth trying, because the button leaves the next step unclear.
  • What’s working: Keep the note that the consultation has no obligation. It answers a real question right next to the button.

This gives the team a problem to solve and a reason to solve it. The suggested wording remains an option they can discuss.

4. Record What Changes as You Move Through the Page

On the opening screen, note what you noticed first and whether it supports the page’s job. Distinguish “I noticed the photograph first” from “customers won’t read the headline.” Only the first describes what you observed.

As you scroll, record the section where your understanding changes. You might understand the offer only after reaching a later explanation, or mistake a large empty area for the page’s end.

Therese Fessenden’s article on scrolling and attention warns about these misleading endings, called false floors. In your note, identify the exact section and explain what made you think there was nothing below it.

For example: “After the testimonials, the large gap looked like the end of the page. I almost missed the service details below it. Could we make it clearer that the page keeps going?”

When a concern follows a click, include what happened before and after it. “Opening section → selected ‘See plans’ → arrived at the comparison table” gives more context than “The pricing section is confusing.”

Use these notes to explain what you noticed at the sizes you reviewed. Choosing those sizes and completing launch checks need their own review, beyond this feedback-writing method.

If you’re comparing layouts in Online Website Previewer, record the size shown for the view you’re commenting on. Keep your notes in your chosen document or thread.

The previewer displays live pages, so submitting a form or placing an order really submits it. Check the safe test setup with your team before doing either.

5. Lead With the Observation, Even When You Have a Fix

A suggested solution can be useful, but it needs a reason. “Make the button blue” doesn’t explain what the current design prevents you from seeing or doing.

Try this version of the same feedback instead: “The button blends into the background, so I missed the next step at first. Could we make that action easier to see? One suggestion is a stronger contrast, such as blue.”

Lead with the observation, then label any fix as a suggestion. Ask for the outcome you need and leave room for the designer to find another way.

Practitioners differ: Spool’s guidance favors questions, while Boag’s argument welcomes client suggestions. Stating the observation first keeps your note useful under either approach.

Judge the Concern Against the Right Goal

For a campaign page, compare the message with the ad or email that brought the visitor there. Unbounce, a landing-page software vendor, explains this as message match.

Its conversion-centered design guidance recommends one campaign goal, while acknowledging that homepages serve people with different reasons for visiting. Use those goals to explain your concern rather than imposing one main action on every page.

For a redesign, refer back to the problem the project is meant to solve. Hoa Loranger’s guidance on redesigns also cautions that returning customers can resist changes, even when the design improves.

These sources explain what to judge against, rather than comparing feedback methods for landing pages and redesigns. If something familiar has moved, describe the old expectation and the new experience instead of writing “Change it back.”

6. Rank Your Notes and Name What to Keep

Put the most important concern first, with a reason for its priority. A long list of equally urgent comments makes it harder to see which ones affect the page’s purpose.

You can adapt the Do, Try, Consider labels Jackie Bavaro described in Asana’s feedback practice:

  • Must resolve: Reserve this for a requirement or a problem that prevents the agreed goal. Explain the requirement or impact.
  • Worth trying: Suggest an approach to explore, then review what it changes.
  • Consider: Offer an idea or question that needs discussion, without presenting it as a required change.

Agree on those meanings with your team. A marketer’s priority label should start a useful discussion, not silently turn a preference into a launch decision.

Also leave specific positive notes. “Keep the explanation beside the price because it makes the package difference clear” tells the designer what to protect.

Casali’s design-critique guidance includes positive feedback to help prevent changes to things that already work. You don’t need to invent praise for every concern, but don’t leave the team guessing what you want preserved.

7. Send Notes the Team Can Answer

Before sending, separate comments that contain more than one issue. Keep each note’s number with its screenshot so the team can reply point by point.

Ask your team or agency whether they want consolidated notes or direct discussion with the people reviewing the design. Confirm who can resolve conflicting requests, and flag those conflicts before sending.

Published advice differs on the collection method. Helen Rajan’s guidance favors one voice, while Boag’s article favors direct stakeholder discussion. His article is sponsored by feedback-tool vendor BugHerd, so agree on the method with your team rather than treating either as a rule.

Ask for a response that names the decision, explains the reason, and says what happens next. That follows Rachel Krause’s guidance on closing the loop after a critique, written for designers.

Send the numbered notes with the page’s goal at the top. Include a short handoff: “These notes cover [pages and sizes reviewed]. The main concern is [issue], because [impact on the goal].”

Your feedback is ready when another person can find the issue, understand why it matters, and discuss the outcome without guessing your intent. That gives the next round a shared starting point.

Blank Feedback Sheet

Download the printable sheet (PDF, two pages)