Every project has this moment. The staging link arrives, the client opens it beside the approved design, and something is off. Sometimes that is sloppy work. More often it is the gap between a static picture of one screen and a living document rendered by an unknown browser on an unknown screen at an unknown width. Knowing which differences are defects and which are the medium doing its job makes the review far more productive.
A design file describes one width. A website has all of them.
The mockup was drawn at 1440 pixels. Real visitors arrive at 1366, 1280, 1194, 390, and a few thousand widths in between, on windows they resize while reading.
So between the artboards, the browser is following rules rather than reproducing a picture. A three column grid becomes two somewhere; a headline that fits on one line at 1440 wraps to two at 1280; a section with generous space at desktop cannot keep it at 375 without pushing the content off screen. Those are decisions made during the build, and they are the reason the phone layout has to be designed rather than derived.
If the design file did not specify what happens at those widths, someone decided. The right review question is not “why is it different” but “is this the right behaviour here”.
Type renders, it does not paste
Text in Figma is laid out by Figma. Text on the web is laid out by the browser, with different hinting, different subpixel rendering, and different line breaking.
The consequences are consistent: text often looks very slightly heavier or lighter in the browser, line breaks land in different places, and letter spacing set to a fraction of a pixel in the design will not survive. Line height rounds differently. A font that is not loaded yet is swapped in later, so the first paint may show a fallback face at a different width, which is why headline positions can shift for a moment on load.
Most of that is normal and invisible to everyone except the person holding both files. What is not normal: the wrong weight, the wrong font entirely (usually a licensing or loading problem), or type sizes that ignore the scale.
Content is real now, and real content is untidy
The design used a nine word headline and a perfectly cropped photograph. Production has a nineteen word headline, a client logo with a transparent background that vanishes on white, and a testimonial three times longer than the box.
This is the most common source of “it looks wrong”, and it is rarely a build error. It is the design meeting the actual content for the first time, which is why real copy belongs in the process early and migration is planned rather than assumed.
Images shift too. A photograph placed by hand in a frame gets cropped by a rule on the web, so faces can land differently at different widths unless someone sets the focal point.
The states a static file never showed
The mockup shows the resting state of everything. The live site has hover, focus, active, disabled, loading, error, empty, and overflow.
If those were not designed, the developer invented them, and inventions look inconsistent next to a carefully art directed page. That is a real defect worth logging, but the fix is usually to design the missing states rather than to blame the build, which is why every screen should ship with its empty and error versions. The same applies to motion: a transition timed in a prototype feels different on the tenth repeat with real data behind it.
What is a genuine defect
Worth fixing, always: wrong spacing scale or inconsistent rhythm between sections, wrong colours or weights, components that differ from the design system, broken alignment, elements that overlap or clip at any width, contrast that fails, missing focus states, layouts that break between the designed breakpoints, and anything that shifts while the page loads.
Not worth fighting: a two pixel difference in a shadow, text rendering weight, or a line break that lands differently on Windows. Chasing pixel identity across platforms costs days and buys nothing a visitor will ever notice.
How to stop the argument happening at all
Review in the browser, not in a comparison with the file. Once code exists, the built site is the truth and the Figma file is history; keeping both authoritative guarantees confusion.
Design the system rather than the page, so the build has rules to follow rather than proportions to eyeball, and specify the awkward cases up front: the longest realistic headline, the smallest supported width, what each component does when it runs out of room. That specification is what makes a handoff work, and it is what turns review comments into useful, actionable feedback.
Then check the built site on a real mid range phone before anyone signs anything, because that device is where the differences that matter actually live, and where a site can score well and still feel wrong.
Want a build that holds up against the design at every width? hello@beconfidency.agency, and the live work is the proof.
If you want design and build under one roof so this gap never opens, that is exactly what our web development service is for.