Our redesign feels like it is going badly — how do we intervene before launch?

Most people wait for the design to look wrong before they act. That is the wrong instrument. Design quality is subjective and arrives late. Process quality is objective and arrives early.

In our projects, the difference between a redesign that lands and one that slips shows up in the first two or three weeks, in how work is shown and how decisions get made. Here is what to watch for.

• **Work only appears when it is polished.** If you have not seen a rough layout, a grey box wireframe or a half-built page, the team is hiding progress until it is defensible. That habit hides problems until they are expensive.
• **Nobody can say what problem a page solves.** Ask what the pricing page is for. "Showing the plans" is a description. "Getting a self-serve buyer to pick a tier without contacting sales" is a purpose. Without the second, there is no way to judge the design.
• **Your feedback reappears unaddressed two rounds later.** One missed comment is human. The same comment surviving two review cycles means feedback is being collected, not tracked.
• **Meetings are about process, not pages.** Three consecutive calls spent on tooling, timelines and who reviews what, with no page on screen, means the work is not moving.
• **Content and build are never discussed together.** If nobody has asked who is writing the careers page copy by which date, the build will stall waiting for text that does not exist.
• **The date has not moved but the scope has grown.** A launch date that survives three added pages is not a date, it is a wish.

You do not need to audit the work to know whether a project is healthy. You need three questions, asked at every review, in this order. They take four minutes and they are hard to fake.

**What decision are we making today?** A healthy checkpoint has one. Approve the homepage layout. Choose between two navigation structures. Sign off the content model. If the answer is “just showing you progress”, the checkpoint has no purpose and neither does the week that follows it.

**What is blocked, and who unblocks it?** Every real project has something blocked. The answer should be a specific thing and a specific name, including yours. “Waiting on the case study copy from Maria” is a healthy answer. “Nothing really” from a project that has slipped twice is not.

**If we lost two weeks tomorrow, what would we cut?** This is the most useful of the three. A team with a plan answers instantly, because they already know which pages are core and which are nice to have. A team without a plan says everything is important.

Read vague answers as an absence of a plan, not a slow week. A slow week has a reason attached to it. “We are still working through the design” three weeks in is not a reason, it is a wall.

This is the part worth checking before you write a complaint. In our experience the most common cause of a stalled redesign is on the client side, and it is nearly always one of three things.

**Decisions with no owner.** Feedback arrives from four people who disagree, so the studio picks a direction, and the fourth person overrules it a week later. That page gets built twice and paid for twice.

**Copy that never arrives.** Real content is the hardest input to produce and the easiest to postpone. A layout designed around placeholder text usually breaks when the real headline is three lines instead of one.

**A goal that moved.** A redesign briefed to support a fundraise is a different site from one briefed to drive self-serve signups. If the company changed direction in month two and nobody restated the brief, the studio is still building to the old one.

None of that excuses a studio that goes quiet. But if you intervene without fixing your own side, you will get the same result two weeks later with more emails attached.

Start with the one that costs nothing and takes an hour. Escalate only if it does not work.

The written reset does most of the work. It is one page you write, not the studio: the goal in a sentence, the pages in scope, the dates, and who decides what. Send it and ask for written agreement or written correction. If the reply disagrees with your understanding of the scope, you have found the problem, and you have found it in writing before launch instead of during it.

1. **Write the one-page reset and ask for agreement.** Goal, page list, dates, decider. Ask for a yes or a correction in writing. Disagreement here is the diagnosis.
2. **Name one decider on your side.** One person whose approval ends the discussion, with the others advising. This single change fixes more stalled projects than any other, because it removes the rework loop.
3. **Ask for the unpolished version every week.** A screenshot, a link to a staging URL, a half-built page. Set the expectation that rough is welcome. You are trading comfort for early warning.
4. **Cut scope rather than extend time.** Extending a date rarely recovers a project, because the same rate of progress applied to the same scope produces the same slip. Dropping four pages from a fourteen-page build gives the team something they can actually finish.

A pattern we see: a marketing site briefed at fourteen pages, three weeks scheduled, and at the end of week five nothing is approved. The homepage has been through four rounds. Six pages have no copy. The founder, the head of marketing and a board advisor all comment on every review.

Trace the cause. Three reviewers with equal standing means every approval can be reopened, so the studio keeps reworking the homepage instead of moving on. Missing copy means the remaining pages cannot be built even if the homepage were signed off. Nothing here is a design problem, so more design rounds cannot fix it.

The intervention: name the head of marketing as sole decider, cut the page list from fourteen to six templates that cover the pages with finished copy, and move the rest to a second phase after launch. Six templates can drive far more than six URLs through a CMS, so the site is not necessarily smaller, just decided.

The counterexample is the version where you extend the deadline by three weeks instead. The three reviewers still disagree, the six pages still have no copy, and week eight looks like week five with a larger invoice behind it.

Pause when the goal changed mid project. If the company pivoted, raised, or dropped a product line, finishing a site built for the old story means paying to launch something you will redo within six months. Stopping to rewrite the brief costs weeks. Launching the wrong site costs the whole project again.

Push on when the only problem is speed. A late project with an agreed goal, a named decider and copy in hand is a scheduling problem, and scheduling problems get solved by cutting scope.

Consider a partial launch when some pages are genuinely finished. Shipping a homepage, a product page and a contact page on the new design, with the old blog and old case studies left in place, is usually better than holding everything back. It is not elegant. It puts real work in front of real visitors and it gives you an honest read on whether the new direction is working.

Get four things before the relationship ends, and get them while people are still replying to email. Once an engagement closes, response times go from hours to never.

**The repository and the deployed code.** Whoever you hire next starts from what exists rather than from zero. Check your contract for who owns it. At Glasspage the client owns the design, the code, the repository and the deployed site from day one, including if the relationship ends, but that is a contract term and not an industry default. Read yours before you need it.

**Design files with editable source.** Exported PNGs are worthless to the next team. You want the working file.

**Research and decisions.** Any audit of the current site, analytics findings, or notes on why the navigation was structured a certain way. This is often the most valuable thing produced and the easiest to lose, because it lives in someone’s head or a call recording.

**Access, back in your own hands.** Domain, hosting, CMS, analytics, Search Console, email. Confirm you can log in yourself, today, without asking anyone.

Paying for work you will not ship is sometimes the right call. A $5,000 build you abandon in week four is cheaper than a $5,000 build you launch, dislike, and replace next year. Sunk cost is not a reason to ship a site you do not believe in.

Every intervention here is designed to produce a launched site, not to establish who was at fault. Those two goals pull in opposite directions once the emails get long.

The practical version: ask the three checkpoint questions this week, write the one-page reset, name your decider, and cut scope before you move the date. If the answers you get back are vague, act on that. A quiet project does not get better on its own, and everything that is cheap to fix in week three is expensive to fix in week nine.