Once the mockups are approved and the build is done, you ask for a review. Posting a folder of screenshots is convenient, but screens that pass a screenshot review routinely misbehave after launch. The reason is simple: a screenshot is one moment under ideal conditions, and a real site spends most of its life outside those conditions.
What screenshots hide
Real content length is the clearest example. The title in the mockup was written to fill exactly two lines; the titles editors write were not. In a row of three cards, one title running to three lines breaks the row. That never appears in a screenshot and always appears on a page carrying real data.
States behave the same way. What a link looks like on hover, where the Tab key goes, what a form shows when validation fails — these are rarely drawn. Focus indicators that existed on the old site frequently vanish in the new design, and nobody reviewing with a mouse will ever notice.
Staging has conditions
Staging is not merely “a copy”. A staging site without these conditions becomes an incident of its own.
Blocking search matters most. An indexed staging site puts the same content at two addresses and leaves search engines unsure which is the original. Have that happen mid-redesign and diagnosing anything becomes twice as hard.
Outbound mail is the other common miss. Testing an order or an enquiry on staging sends the notification to a real customer address. Stop sending, or funnel everything to a single test inbox, before anyone touches a form.
How to ask for a review
Send only a URL and you will get “looks good” back. Include three things and the answers change: which screen, what to look at, and what decision you need. “This is the single post template. Please look at a three-line title and a long pull quote. I need a decision on whether to narrow the text column.” gets you a specific answer.
Order the review by the entry list from part one. When time runs short, which screens get looked at first is then already decided.
More on staging setups and deployment lives in the development workflow archive, and how we use staging in practice is written out step by step on the process page.
Next part
The review is done. Deployment is next — but not all at once. The following part is rolling out one template at a time.