How to Run a Design Review That Gets Useful Client Feedback

Catch a design problem on screen and it’s a quick fix. Catch it after the website is built and it’s a much bigger one. That’s the case for a design review, a scheduled working session where the designer walks stakeholders through a design, such as a sitemap, wireframe or full-color comp, explains the reasoning behind it and collects feedback before the next round. Done well, it’s the cheapest point in a project to find problems.

Many teams skip the conversation and email a PDF instead. Even some designers see a client call as an extra step that slows down the day’s production. That saves an hour on the calendar but often costs days in back-and-forth. A good designer should want to discuss a design, a content idea or a wireframe, because reviews benefit both the designers and the customers paying for the work. This guide covers how to run a design review process that produces clear, useful feedback, in the same room or over video.

What is a design review?

In a client project, a design review is the moment the person who made the work and the people paying for it look at it together. The designer presents what was made and why. The client asks questions, reacts and confirms whether the work meets the project’s goals.

It isn’t a formality at the end. On a website project, reviews happen at each phase, and each one builds on the decisions approved before it:

1. Research notes
2. Content outline (if one is needed)
3. Sitemap
4. Wireframes
5. Site design

Does that sound like a lot of little pieces? It is, and that’s the point. Reviewing in small pieces means that by the time a full-color comp is on screen, the content needs have been discovered and cataloged, the sitemap has been approved, and the structure has already been agreed in the wireframe review. The conversation can focus on look, feel and detail instead of reopening the layout. By then everyone also knows the meeting rhythm, so the final design review goes smoothly and people are more comfortable giving feedback. You can see how these phases fit together in Daylight’s design process.

Where reviews fit in the design process

Design process models vary in how they name and number the steps, but most digital projects move through the same phases in order. Each one ends with a review:

1. Research: goals, audience and competitors. Review the findings before anything is drawn.
2. Strategy: priorities, content plan and sitemap. Review to agree on what the product needs to do.
3. Wireframes: layout and structure without visual styling. Review to lock structure while changes are cheap.
4. Visual design: full-color comps and prototypes. Review look, feel and detail.
5. Build: development on a staging site. Review the working product against the approved design.
6. Launch: final quality checks before going live, then a review of results afterward.

Some industries, such as architecture and engineering, schedule reviews at set completion points instead, often 30, 60 and 90 percent. Website and product teams usually review at each deliverable, but the principle is the same. Check the work before the next phase builds on it.

Why live walkthroughs beat emailed PDFs

Good design takes a lot of research and planning before anything polished appears. At many agencies, the designer is the person in charge of creating the logic for the project solution, and every good design decision has reasoning, research and industry knowledge behind it. None of that reasoning is visible in a static file.

Much of that work is hidden. The tasks most people recognize as design, like choosing a color scheme, often take less time than the groundwork that comes first. On a website build or redesign, the designer starts by researching the project’s goals and target audience, then builds a content structure while learning about the business. That hidden design time is easy for a client to overlook, and a review is where the designer can share those early findings.

In a review, the designer can also explain the three pillars that shape most layouts:

• Industry standards that let the design make smart decisions efficiently.
• Content needs, which have the most power to dictate the layout.
• Artistic point of view, the smallest but most distinctive part, where the brand gets its personality.

Once the design takes shape on screen, designers rapidly try many treatments of the content, discard most of them, and only polish the strongest few for review. Walking through the work is the designer’s chance to show that due diligence, and that several solutions were tested before the few on screen were chosen.

Without that context, clients tend to react to color and imagery first and miss the structural questions that matter more. A walkthrough also lets the designer hear hesitation in real time and ask a follow-up question, which is far more useful than decoding a one-line email that says “not quite there.”

Who should be in a design review?

Keep the group small enough to have a real conversation, but complete enough that decisions stick. A good design review usually includes:

• The designer who did the work, to present it and capture feedback.
• A project or account lead to manage time, scope and next steps.
• The client decision-maker, the person who can approve the work. If they can’t attend, the review risks being redone later.
• Key subject experts, such as the marketing lead or someone who knows the content, when their input affects the design.
• A developer for reviews where feasibility, interactions or performance are on the table.

The most common reason a project slips is a senior stakeholder who sees the work for the first time after it has been approved. Invite them early, even if only to the key milestones.

How to run a design review, step by step

A design review works best when it follows the same simple structure every time. Here’s how to run one:

1. Set the purpose. Decide which stage is being reviewed and what decisions you need by the end.
2. Invite the right people. Include the decision-maker and anyone whose input changes the design.
3. Share context ahead of time. Send the agenda, goals and previously approved work a day or two before.
4. Restate goals, then present. Open with the audience, goals and earlier decisions, then walk through the design and the reasoning behind it.
5. Open the floor to questions. Understanding comes before critique.
6. Capture feedback in one place. Note each comment and who made it, and leave pauses so nothing is missed.
7. Recap and assign. Agree on what changes, who owns each item and when the next round is due.
8. Follow up. Send a written summary, and in the next round show how each piece of feedback was handled.

Preparation is what turns a review from a show-and-tell into a decision. Both sides have work to do beforehand.

For the design team

• Restate the goals, audience and any decisions already approved at the start of the meeting.
• Present designs in context, on a real screen size and with realistic content rather than placeholder text where possible.
• Know which questions you need answered, and say what kind of feedback you’re looking for at this stage.

For the client team

• Revisit the project goals and the previous round’s approved work.
• Agree internally who is giving the final word, so feedback doesn’t conflict.
• Be very clear about expectations. If you want to choose from 10 design ideas, establish that before design starts, not at the review.

Design review checklist

Use this quick checklist to make sure the review covers what matters:

• Goals: Does the design support the project’s business goals and the needs of its audience?
• Content: Is the real content accounted for, with a clear hierarchy and obvious next steps?
• Navigation: Can users find key pages and complete key tasks without guessing?
• Brand: Are colors, type and imagery consistent with the brand and style guide?
• Responsive: Has the design been shown at mobile, tablet and desktop sizes?
• Accessibility: Are contrast, text size, focus states and alt text considered?
• Feasibility: Has a developer confirmed the design can be built within scope?
• Decisions: Are approvals, changes, owners and deadlines written down before everyone leaves?

How to give useful design feedback: a checklist

Reviews benefit the customer as much as the designer. They’re there to help you make informed decisions, so your feedback steers the work toward a result that serves your business or vision. If there’s one rule, it’s be active. Share your thoughts during each review or shortly after. These habits make the biggest difference:

• Give as much input as you can. More context helps the designer make better decisions in the next round.
• Treat it as a two-way street. Both sides of the table should leave a design review knowing more than when they came in.
• Ask questions first. Every design element has a reason behind it, so ask as many questions as you can think of. Understanding the reason often answers the concern, or reveals a real problem worth fixing.
• Tie feedback to goals. “Visitors won’t find pricing here” is more useful than “I don’t like it.”
• Describe the problem, not the fix. Let the designer solve it. You may get a better solution than the one you had in mind.
• Give guidance early. Designers need boundaries. Sharing your ideas up front won’t hold back the creativity of the final product.
• You don’t have to decide on the call. The review is for understanding. It’s fine to send consolidated feedback a day or two later.
• Allow some quiet time. On a call, pause so the designer can capture everything you’ve said.
• Speak up if something is missing. If the deliverables don’t meet your expectations, say what you expected to see.
• Follow up on your input. If you don’t see your feedback reflected in the next round, ask why. There is usually a good reason, and it should be explained.

Common design review mistakes

Most review problems are process problems, not design problems. Watch for these:

• Reopening approved decisions. The wireframe review is the best time to change or adjust elements that aren’t to everyone’s liking. Sometimes it takes a full-color comp to spot a problem, and that’s fine, but get it raised before the design goes into development.
• Design by committee. Collect every opinion without a decision-maker and you get compromises that serve no one.
• Feedback in fragments. Comments arriving from five people across email, chat and phone are hard to reconcile. Consolidate them in one place.
• Judging on personal taste. Your audience’s needs matter more than anyone’s favorite color.
• No recap. End every review by agreeing on what changes, who owns each item and when the next round is due.

How to run remote and async design reviews

On a lot of projects, remote reviews are now the default, and the same principles apply. Present the work live over video, share your screen, and record the session for anyone who couldn’t attend.

Collaborative design tools such as Figma make async design review practical too. Stakeholders can open a shared link, view designs and clickable prototypes in a browser, and leave comments pinned to the exact element they’re talking about. A few ground rules keep async review from turning into noise:

• Kick off with a short live walkthrough or recorded video, so reviewers understand the reasoning before they comment.
• Set a clear deadline for comments and name the person who will consolidate them.
• Ask reviewers to keep comments to the current stage of the work.
• Resolve each comment thread once it’s addressed, so the next round starts clean.

Agreed decisions also belong somewhere more durable than a comment thread. Capturing approved colors, type and components in a digital style guide keeps later reviews from relitigating settled choices. Our design team builds reviews like these into every project phase.

A design review is a two-way conversation, and it’s the least expensive place to fix a design. Your input is what makes the final product better, so ask for formal reviews on every project. Any good agency will welcome the request, and we’re grateful to the clients who make them part of the work.