Flawsnap
Free trial

Design review on the built site

Designers mark up the real page in the browser, and each note arrives with the viewport, pixel ratio and URL, so the developer sees the same screen they saw.

The problem: design QA happens on screenshots of screenshots

A product designer is checking a new pricing page before launch. In the design file the cards line up and the headline wraps after 'teams'. On the build, at 1280 pixels wide, the third card's button drops lower than the others, and on a narrow phone the headline breaks after the first word. The designer screenshots both, pastes them next to the design in a chat thread, and writes 'see above'. The developer fixes the desktop one and misses the phone.

Design review needs three things a chat thread doesn't keep: the exact element, the screen size it happened at, and a list that can be ticked off.

Set up a design review round

  1. 1

    Use the staging or preview domain

    Add the preview host to the project's allowed domains, for example *.preview.example.com if every branch gets its own subdomain. Designers then review each branch as it is built.

  2. 2

    Sign designers in

    Invite designers as members and turn on team sign-in, so each note carries their name. Restrict them to the projects they design for if you have several.

  3. 3

    Add design categories

    The default Design category is a start. For a review round, split it: Spacing and alignment, Typography, Colour, Copy, Responsive. Developers then batch similar fixes.

  4. 4

    Keep the spec next to the work

    Write the page spec or the design decisions in a project doc, link it to the cards, and @mention the developer. When a question comes up on a card, the answer is one click away.

Marking up the page

The screenshot is taken from the page itself, so there is no permission prompt and the widget's own button is left out. The annotation toolbar has Box, Arrow, Draw, Text and Blur, five colours, undo and zoom, and Select area to crop to the part that matters. A few habits make design notes easier to act on:

  • Crop to the component, then draw a box around the exact element. A full-page screenshot with a small circle is hard to read.
  • Use the Text tool for the value you expected: '24px gap', 'Heading 2', 'Brand green'.
  • One issue per report. Three issues in one screenshot become one card that is never quite done.
  • Say whether it is a deviation from the design or a new idea. Categories help, but a word in the title is clearer.

Responsive review

Every report records the browser, OS, viewport, screen size and pixel ratio. That is what makes 'the card breaks on my laptop' actionable: the developer opens the page at that viewport and sees it. For a responsive pass, resize the browser to each breakpoint you designed for and report at each one, rather than relying on device mode screenshots from memory.

Working the board in a design round

Filter the board by the Design label and by assignee to give each developer their list. When a fix is up on the preview, move the card to QA and the designer reviews it there. If it is still off, they choose Send back with a reason; the card returns to In Progress and gets the Rollback label automatically. Done means the designer has looked at it on the build, not just that the code changed.

What a good design note contains

  • A cropped screenshot with a box on the element and the expected value written next to it.
  • The breakpoint, which is attached automatically, and whether it also happens at other widths.
  • A link or reference to the frame in your design file, pasted in the description.
  • Priority used honestly: an off-brand colour on a button is medium, a layout that hides the call to action on mobile is high.

Pitfalls

  • Reviewing on production by accident. If production isn't listed, the widget won't accept reports there. List it only when you mean to.
  • Fonts and rendering. The screenshot is rendered from the page, so check anything subtle, like a single-pixel border or font smoothing, by eye on the build as well.
  • Pages you can't add the widget to. For third-party pages or a competitor's site, the Chrome extension lets signed-in team members capture any tab.

Questions

Can I compare the build with the design file inside Flawsnap?
No, Flawsnap doesn't import design files or overlay them. Paste a link to the frame in the report description, and keep the written spec in a project doc.
Can developers see the console for design issues?
Yes, every report attaches the console and network calls. For design notes they are rarely needed, but they help when a font, image or style sheet failed to load.
Do designers need a paid seat?
No. Plans are per organization with unlimited members, so designers can be invited at no extra cost.

Try it on your own site

7-day free trial, then $9 a month for Starter or $19 for Pro, per organization, with unlimited team members.

Start free trial Try the live demo

Related

Updated