Font renders 18px, should be 20px
You spent two weeks polishing a dashboard redesign in Figma. Every spacing token is correct. The component library is spotless. Your team approved the mockups with a row of thumbs-up emojis. Then the developer pushes the build to staging.
You open the URL, and something is off. The card shadows are heavier than expected. The font rendering looks different. On a 13-inch laptop, the sidebar pushes the main content into a layout that wasn't in any of your frames. You need to leave feedback, but not on the Figma file. On the actual page.
This is where most design review workflows break down. The tools that got you through the design phase have no way to handle what comes after.
The Gap Between Mockup and Browser
A design file is a controlled environment. Fixed viewport, perfect data, no browser quirks. A live website is none of those things. Fonts render differently across operating systems. Dynamic content stretches containers in unexpected ways. CSS interactions look nothing like prototype animations. And real user data rarely fits the placeholder text you designed around.
Designers know this. The gap between what you designed and what got built is where most visual bugs live. But the feedback tools available at this stage are surprisingly limited.
- Figma comments reference mockup frames, not live elements. If the issue only appears in the browser, there's nothing to comment on.
- Screenshots lose context. A cropped image of a misaligned card doesn't tell the developer which breakpoint, which browser, or which page state you're looking at.
- Slack messages get buried. 'Hey, the spacing on the settings page looks weird' disappears in a thread within hours.
- Spreadsheets and docs become stale before the developer opens them.
The result: designers either let small issues slide or spend 30 minutes per page documenting what should take 2 minutes to point at.
Why Figma Comments Don't Transfer to the Browser
Figma is built for design collaboration. It handles comments on static frames, component variants, and prototype flows. But once the design ships to a staging URL, Figma's role ends. You can't paste a staging URL into Figma and comment on it. You can't pin a note to a live DOM element. The tool simply wasn't built for that.
The Usual Workarounds
Most design teams fall into one of these patterns when reviewing deployed work:
The side-by-side comparison: Open Figma on one half of the screen, the staging site on the other. Spot a difference, take a screenshot, annotate it in a drawing app, paste it in Slack with a paragraph of context. Repeat for every issue.
The inspection meeting: Schedule a 30-minute call with the developer. Share your screen, scroll through the page together, point at things in real time. If you forget something, schedule another call.
The spreadsheet: Create a shared Google Sheet with columns for page, section, issue description, priority, and status. Add rows manually, cross-reference with screenshot filenames like 'settings-card-spacing-v2-FINAL.png'. Wonder why developers dread opening it.
Each of these approaches adds friction at the exact moment when feedback should be fast. The issue is visual, but the communication is textual. The problem is on a webpage, but the discussion happens somewhere else entirely.
What Design Feedback on Live Sites Should Look Like
When you spot a visual issue on a live page, the fastest path to resolution is the simplest one: mark the issue directly on the page, add context, and share. No tab switching. No file attachments. No extra tools to learn.
Effective design review in the browser comes down to three things:
- Precision: you can point to the exact element, not describe it with words. A circle around a button says more than 'the CTA in the hero section on the homepage'.
- Context: the feedback stays on the page where the issue lives. The developer sees the same URL, the same viewport, the same state.
- Speed: leaving feedback takes seconds, not minutes. No screenshot workflow, no image editing, no context-switching to another tool.
Web annotation makes this possible. Instead of leaving Figma comments on a mockup that no longer reflects reality, you leave annotations on the thing that matters: the deployed page.
Design Review in Practice: A Staging Environment Walkthrough
Here's a real scenario. You're a lead designer reviewing a newly deployed settings page on staging. The developer followed the Figma specs closely, but the browser tells a different story. You find four issues in under a minute:
Issue 1: The section headings use 18px instead of 20px. You circle the heading and drop a sticky note: "Font size should be 20px/1.5 line-height per our type scale. Looks like 18px in the computed styles."
Issue 2: The save button sits too close to the form fields on viewports below 1024px. You draw an arrow between the button and the last field, adding a note: "Need 32px gap here. Currently collapsing to ~12px at this breakpoint."
Issue 3: The avatar upload area has a visible layout shift when the image loads. You circle the area and write: "CLS here when avatar loads. Feels jarring. Can we reserve the space with a fixed aspect ratio?"
Issue 4: The toggle switches use the browser default style instead of the custom component from the design system. You draw a box around the toggle row: "These should use our Switch component from the UI library, not native checkboxes."
Four issues, each annotated in under 15 seconds. You share the annotated page with one link. The developer opens it, sees every issue pinned to its exact location, and starts fixing. No meeting needed. No screenshot deciphering. No back-and-forth.
When Browser-Based Review Matters Most
Responsive Breakpoints
Figma frames show two or three breakpoints. The real browser has a continuous range. Issues often appear between your defined breakpoints, in the in-between widths that no one designed for. Reviewing in the browser lets you catch these edge cases and annotate them in the exact viewport where they happen.
Font and Rendering Differences
Web fonts render differently on macOS and Windows. Subpixel antialiasing, hinting, and font-weight interpretation all vary. A heading that looks crisp in Figma might appear heavier or lighter in Chrome on Windows. These are issues you can only catch in the browser, and they need feedback that references the browser rendering, not the design file.
Dynamic Content and Real Data
Designs use placeholder content. Real applications display user-generated text, variable-length strings, and edge-case data. A card component that looks perfect with "John Doe" might break with "Dr. Alexandra Konstantinidis-Weatherford III". These layout issues only surface on live pages with real data.
Animation and Interaction Timing
Prototype transitions in Figma are approximations. Actual CSS transitions, scroll-triggered animations, and loading states behave differently in a real browser. If a modal animation feels sluggish or a skeleton loader flashes too fast, the feedback needs to happen where the issue is: in the browser.
Design Review Doesn't End in Figma
Figma is the right tool for designing. But reviewing what was built requires a different approach. The browser is where your users will experience the product, and it's where your design review should happen too.
The best design teams treat the staging URL as the final canvas. They open it in a browser, spot what's off, annotate it on the page, and share it in seconds. No screenshots, no spreadsheets, no synchronous meetings for asynchronous problems.
See a design detail that's off on this page? Try annotating it right now. Drop a sticky note, draw an arrow, circle an element. It takes a few seconds and you'll see why reviewing in the browser changes everything.