What designers catch in a preview that screenshots hide

For most of my career, design review meant looking at a screenshot in a pull request. Someone would paste two images, before and after, and I would say it looked right, because in the screenshot it did. Then it would ship, and a week later I would find the same screen in production with a customer name that ran to three lines and pushed the button off the card.

The screenshot was not lying. It showed one state, with one set of data, at one width, chosen by the person who built it. Everything I am paid to notice lives in the other states.

What a screenshot leaves out

These are the things I now catch in a preview, in rough order of how often they come up.

• Long and short content. Seed data from a masked production snapshot has the real distribution: the practice with a 61-character name, the patient with one letter for a surname, the invoice with 140 line items. Fixture data has "Test User" forty times.
• Empty states. A new account with nothing in it. Engineers rarely screenshot this, because their local database is never empty.
• Loading and error states. You cannot screenshot a spinner that stays up for two seconds, or see what the page does when a save fails. In a preview I can throttle my connection and watch.
• The path in and the path out. The screen is fine. Getting to it takes four clicks, and the back button loses your filters.
• The phone. I open the link on my own phone. Not a narrowed desktop window. The actual keyboard covering the actual form.

None of this needs a design tool. It needs the thing itself, running.

Real-shaped data matters more than real pixels

When people talk about previews for design review they usually mean pixel accuracy, and that is the smaller half. The bigger half is the data. A layout is a bet about content, and you only find out whether the bet holds when the content is somebody else's.

Canary seeds every preview from last night's snapshot, with names, emails and card numbers masked. The masked values keep their shape, so a long name is replaced by a long name. The awkward rows are still awkward, which is the point. I do not need to know the customer is real. I need to know the name wraps.

How Tessel gets designers into review

Tessel makes scheduling software for dental practices. They have 22 engineers and 6 designers, and 71% of their pull requests are reviewed by someone who is not an engineer. Jordan Ellis, a staff engineer there, told me it was not a process change. They did three small things.

1. The link is on the pull request, not in chat. Canary comments on the pull request when the preview is ready. Designers watch the repositories they care about and get the same notification engineers get.
2. Design review is a requested review. A pull request that touches a template or a stylesheet requests a designer through the code owners file. It is not a favor.
3. Comments go where the code is. A note pinned to the page in a preview lands on the pull request as a comment, with the URL and the viewport attached. The author does not have to translate "the thing on the left looks off."

At Tessel it takes 9 minutes to get from a push to a design review. Follow-up fixes after merge are down 43%, which is the number I would show anyone who thinks this slows engineering down.

A ten-minute review checklist

This is what I run through on a preview link. For most changes it fits in ten minutes.

1. Open the changed screen with the account that has the most data, then the one with the least.
2. Find the longest name on the page. Then look for the row where it is missing.
3. Do the main action twice: once correctly, once wrong on purpose.
4. Arrive from where a user arrives. Leave with the back button.
5. Open the link on a phone. Rotate it once.
6. Tab through the page without the mouse.
7. Pin a comment on anything that needs to change, then approve or request changes on the pull request itself.

What this changes for engineers

The quiet benefit is that nobody has to produce evidence anymore. No screenshots to take, crop and paste. The pull request is the evidence, because it comes with a running copy of itself.

It also moves the argument earlier. A layout problem found in a preview is a comment on an open pull request. The same problem found after merge is a ticket, a new branch, another review and a second deploy. I would rather be the annoying comment than the ticket.

Reviewers are free on every Canary plan, so there is no seat to request. If your designers are not in your pull requests yet, send them one link and this checklist. The features page shows how pinned comments sync back to the pull request.