How to review a redesign before it ships

Review a redesign against the brief, before you review it against your taste. A website design review checklist is a pass for three things: the phone, the primary action, and words a stranger understands. If those pass and the work still matches what you asked for, the remaining notes are preferences.

Taste still matters. It is a bad instrument for the last review, because everyone in the room has a favorite site and a color they have wanted for a year. The brief is the document that said what this page was for. Hold the new site up to that. Ship the preferences that serve it. Park the ones that would restart the project.

Read the brief out loud, then open the page

Start the review by reading the one-sentence offer and the one action the project was supposed to earn. Then open the page and stop at the first screen. You are looking for that sentence and that action, in language a new visitor can use.

If the first screen shows a different offer, the review stops. The concept is not ready for notes about type. Send it back with the sentence from the brief pasted at the top of the feedback. "We said we help operations teams see the week's work. The page currently introduces a platform for modern companies." That is a useful note. "Can we try a serif?" is a different meeting.

Do this with the people who can approve. A review that collects comments from six stakeholders who never saw the brief will produce six directions. One owner reads the brief, then the others react to whether that owner’s goal is on the page.

Bring the old site only to check facts you meant to keep: the name, the offer if it did not change, and any path regulars use. The old site is a poor scorecard for taste. You are replacing it because something failed. Score the new one against the failure you named.

A pass for words a stranger understands

Sit with someone who does not work on the project. Ask them what the company does, who it is for, and what they would click. Give them the first screen and one interior page. Write down their words. Compare those words to the brief.

Nielsen Norman Group's research on how long people stay is the reason this pass is short. Users often leave within 10 to 20 seconds. To earn several minutes of attention, the value proposition has to be clear within 10 seconds. People also have time to read only a quarter of the text on pages they actually visit. A review that praises a long, clever hero and a dense second section is praising copy the visitor will not finish.

Cut in the review, not after launch. If a paragraph does not help the stranger say what this is, it waits for a later page or it goes. Buttons should say the action. "Book an intro call" is reviewable. "Get started" requires the stranger to guess what starts.

Read the title of the page as well. It should describe the page. A room that cannot tell the homepage from the pricing page by the title will not be able to tell them apart in a list of links either.

A pass for the primary action

There is one action the project exists to earn. A conversation, a purchase, a signup. In the review, find it on the first screen, on the phone, and once more near the end of the page. It should look like the same action. It should go to a place that works.

Click it. Fill the form with realistic information, or place the test order, or open the calendar. The review includes the arrival, not only the button. A beautiful page that posts into an inbox nobody checks has failed the brief.

Count the competing actions in the first screen. A second, quieter path is fine when the brief asked for it, such as a way to see the work. Three equal buttons are an unfinished decision. Pick the one the business needs this quarter and make the others visibly secondary.

Note the empty and error states if the action can fail. A form that only looks designed in the success case is half reviewed. Submit a blank field. Submit a bad email. The message should say what to fix.

A pass for the phone

Open the staging site on the phone you actually use. Read the first screen without pinching. Reach the primary action with one thumb. Scroll the proof. Open the menu and get back.

The W3C's WCAG 2 overview is the reference for this pass, and it is a standard for content, not a certificate you can claim because a review felt careful. WCAG 2.2 organizes its guidelines under four principles: perceivable, operable, understandable, and robust. The overview also states that WCAG applies to web content on mobile. In a pre-launch review those principles become plain questions. Can the text be read without the picture carrying the only meaning? Can the controls be used without a precise desktop pointer? Does the page still make sense when it stacks? Does the name of a button tell you what it does?

You are not issuing a conformance claim in this meeting. You are refusing to ship a page that only works when the window is wide and the reviewer already knows the offer. If something fails, write the screen and the principle in ordinary language. "The close control on the menu is a gray icon with no name" is a fix. "Make it pop" is not.

Check two devices if you can, a smaller phone and the one in your pocket. A layout that only works on the designer's handset is a lab result. The visitor will bring a different one.

How to write the notes

Separate the review into three piles so the studio can act.

• Changes that block the brief: wrong offer, broken action, stranger cannot explain the page, phone path fails.
• Changes that meet an agreed quality bar: contrast, focus, names on controls, reduced motion if the page moves.
• Preferences: a different crop, a color you miss, a section you would have ordered another way.

Ship blockers get fixed before launch. Quality-bar items get fixed before launch unless you have explicitly deferred them. Preferences get a decision from the one owner: accept, or save for a later pass. A channel full of unranked screenshots is how a review restarts the design.

Time-box the meeting. An hour is enough for the first screen, one interior page, the action, and the phone. Longer sessions drift into redesigning in the margin. If the brief itself was wrong, stop and correct the brief. Do not disguise a new strategy as launch feedback.

After the notes are resolved, the work shifts from approval to use. The team has to know how to edit what just shipped. That is covered in the handoff that makes a redesign usable.

If you want a second set of eyes on a redesign before it ships, book an intro call. The call is where we decide whether a review, a revamp, or a build is the right next step.