Somewhere around week four of a website redesign, someone finally looks closely at the homepage and says “wait, shouldn’t the pricing section come before the testimonials?” The build is 80% done. The developer has already coded the section order. What would have been a five-minute conversation at the wireframe stage is now a full day of rework — and it’s the third time this exact pattern has happened on this project.
The problem isn’t that the feedback was wrong. It’s that it arrived at the most expensive possible moment. Every website redesign moves through stages of increasing cost to change, and most of the pain in a review cycle comes from giving the right feedback at the wrong stage — not from giving bad feedback.
When should you start giving feedback on a website redesign?
At the wireframe stage, before any visual design work begins. A wireframe is a low-fidelity, black-and-white layout that shows structure, navigation, and content placement without color, imagery, or typography — and it exists specifically so structural problems get caught while they’re still cheap to fix. The Good’s guide to reviewing wireframes is direct about what that stage is for: “your job is to focus on form and functionality … nothing is as impactful as the site’s functionality,” and deliberately excludes visual feedback because “it comes later.”
That sequencing isn’t a suggestion — it’s the whole point of building a wireframe instead of jumping straight to a polished mockup. Windmill Strategy says the firm “doesn’t begin visual design work until the sitemap and wireframes have been reviewed, discussed, modified, and approved by all parties” — treating wireframe approval as a gate the project can’t pass through until the structure is settled. If a redesign skips straight from a kickoff call to a full mockup, there’s no cheap stage left to review at all.
Why is feedback so much cheaper at the wireframe stage?
Because the same structural change costs five to ten times more to make once development is underway than it does on a wireframe. Lowcode.agency’s analysis of website wireframes puts a number on the gap directly: “changes to approved wireframes during development cost five to ten times more than the same changes made at wireframe stage.” The same piece found that “teams that use wireframes correctly reduce design revision cycles by 30 to 50 percent” — not because the feedback is better, but because it lands before anything expensive has been built on top of it.
The mechanism is simple. A wireframe is disposable — deleting a section and redrawing the page order costs a few minutes. A coded page section has CSS, responsive breakpoints, and content already wired into it; moving that section means re-testing everything downstream of it. The Good frames the tradeoff the same way: “iterating at the wireframe stage (where changes are quick and easy) saves time and resources you would spend updating a high-fidelity mockup or a live site.” Every stage the redesign moves through adds more that has to be undone to make the same change.
What should you actually give feedback on at the wireframe stage?
Structure, flow, and content hierarchy — not how anything looks. Studio Simpatico’s client guide to wireframe feedback lists what belongs in this pass: whether “navigation aligns with user personas and their mental models,” whether storytelling pages “hit the right narrative notes,” content hierarchy, call-to-action placement, and whether layouts leave room for planned future content. The same guide is explicit about what to leave out: “refrain from premature emphasis on visual aesthetics, allowing the wireframes to establish a solid foundation first.”
In practice, that means catching things like: the contact form sitting below three sections nobody will scroll to, a pricing table that assumes desktop width with no mobile fallback plan, or a navigation structure that buries the page most visitors actually came for. It does not mean commenting on the shade of blue in a wireframe that’s rendered entirely in grayscale — that comment isn’t wrong, it’s just early. Note it if you must, but don’t hold up the wireframe pass waiting for an answer to a question the visual design stage will actually settle.
What happens if you skip the wireframe review and go straight to visual design?
The structural problems don’t disappear — they surface later, disguised as design feedback, at a stage where they’re much more expensive to fix. This isn’t a hypothetical: Refactoring.fm’s 2026 State of Product Development report found that “59% of engineering teams discover missing tasks, stories, or dependencies mid-cycle” — and that “this rate is flat from 10-person startups to organizations with 1,000+ engineers.” Skipping the early structural pass doesn’t make a team immune to finding gaps late; it just means the gaps get found once the cost of fixing them has already gone up.
This is the pattern behind Simpl_Markup’s post on stopping scope creep from turning one revision round into five: new structural ideas keep getting absorbed into whatever round happens to be open, because there was never a dedicated earlier pass where structure was the entire subject. Simpl_Markup’s companion post on setting the revision-round count before a project starts solves a related but different problem — how many rounds to budget. This is the problem upstream of that one: which stage each round of feedback should actually be spent on, so a wireframe-stage question doesn’t eat a visual-design round, and a visual-design objection doesn’t eat a development round.
What should you review once the site is actually built, not just designed?
Functional behavior and cross-device rendering — the things a wireframe or a static mockup can’t show you. A wireframe tells you the pricing section comes third; it doesn’t tell you the pricing table breaks at tablet width, or that the contact form’s submit button is unreachable with the keyboard, or that a hover state hides the one thing a mobile visitor needed to tap. Thoughtgenic’s breakdown of hidden agency costs puts a number on why this pass is worth doing carefully rather than rushing it: “a layout change that would have taken two hours in Figma can take two days to implement and test in a live build” — the same gap that makes wireframe-stage feedback cheap is what makes built-stage feedback expensive if it’s still about layout instead of function. Simpl_Markup’s pre-launch review checklist covers this pass in detail across desktop, mobile, and tablet; Simpl_Markup’s post on the mobile review gap covers why this specific pass gets skipped more often than any other — reviewers check the site on a laptop and assume mobile is fine, when it’s usually the viewport where the actual traffic lands.
This is also the stage where a tool built for reviewing a live page earns its keep over a Figma comment thread. Once there’s a real URL to click through — even a staging URL, before public launch — a team can paste it into Slack and get Simpl_Markup’s auto-generated desktop, tablet, and mobile screenshots in the same thread, then click directly on the page to leave a comment pinned to the exact element with the problem. Each pin tracks its own status — open, fixed, approved — so a functional bug found at this stage doesn’t get relitigated the way a structural comment made three stages too late tends to. That’s a different shape of review than drawing an arrow on a screenshot in Slack, where a functional bug and a leftover structural complaint scroll past looking identical.
What happens if your first round of feedback arrives after launch?
It stops being a revision and becomes a rebuild — with a rebuild’s timeline and a rebuild’s cost, whether or not anyone calls it that. A structural objection raised at the wireframe stage costs a redraw. The same objection raised after launch means re-opening code that’s already shipped, re-testing everything that touched it, and doing it under the added pressure of a site that’s already live and being judged by visitors in the meantime. None of the cost multipliers from the earlier stages apply anymore, because there’s no cheap version of this fix left to reach for.
This is why naming the request honestly matters more than being generous about it. Simpl_Markup’s post on getting final sign-off without an endless email thread makes the same point from the approval side: once something is marked approved, reopening it should be a deliberate decision, not something that happens by default because a founder finally noticed the page order six weeks after launch. It also tracks with how agencies price the same request: Thoughtgenic’s guide to hidden agency costs warns that when post-launch support terms aren’t “established upfront,” an agency vague about them will “be charging you at an uncomfortable rate the first time something breaks” — because nobody budgeted for structural work after launch in the first place. If the ask is structural, it deserves a new timeline and a new estimate — not a guilt-driven “quick fix” squeezed into whatever the developer is already doing.
How do you know which stage you’re actually at, if nobody told you?
Ask directly, and use fidelity as the signal if nobody answers clearly. Productiveshop’s explainer on wireframe fidelity names this exact confusion as a recurring project failure point: “a developer asks if the design is final when it’s still rough,” or “a client complains that ‘nothing works yet’ while looking at a static screen” — because nobody named which stage the file actually represented. If what’s in front of you is grayscale boxes with placeholder text and no working links, you’re at the wireframe stage — comment on structure only. If it has color, real copy, and brand elements but nothing is clickable, you’re at the visual design stage — comment on layout, hierarchy, and brand feel, and hold structural objections unless something is genuinely broken. If you can click through it, submit a form, or view it on your phone, you’re looking at a build — that’s the stage for functional bugs and device gaps, not “what if we moved this section.”
The stage question sounds obvious once it’s named, but most redesign friction comes from a founder or client applying wireframe-stage scrutiny to a near-final build, or applying build-stage nitpicking to a wireframe that was never meant to be pixel-perfect. Naming the stage out loud — “is this a wireframe or a working build?” — before sending feedback costs one Slack message and saves the developer from guessing which kind of comment just landed in their queue.
Give feedback at the stage it’s cheap, not the stage you noticed
The wireframe stage is where structural feedback costs the least and matters the most — a five-to-ten-times cost gap that only grows the longer a structural question goes unasked. Reserve visual design feedback for the visual design pass, save functional and device-specific bugs for the built stage, and treat anything that surfaces after launch as new scope rather than a stalled revision. The stage a comment belongs to isn’t usually a mystery; it’s just a question most reviews never think to ask before the feedback goes out.