You approved a sharp design, but the live site feels cheaper. Compare both at the same width, find the usual differences and name exactly what to fix first.
You approved the design weeks ago. The headings were crisp, the spacing felt calm and the photos sat neatly in their frames. Now the live site is up and something is off. You can't say what, only that it looks cheaper.
"It doesn't feel like the design" is hard for anyone to act on. The differences behind that feeling are usually specific and measurable, and you can find most of them yourself in half an hour.
How do you compare them fairly?
Put the design and the live page side by side under the same conditions first. Otherwise you'll report differences that aren't there.
A live website usually looks worse than its design for a handful of specific reasons: a different font or weight, looser or tighter spacing, images cropped differently, longer real content and widths the design never showed. Compare both at the same width, with the same content, and each difference becomes something you can point to.
- Find the design's width. In Figma, click the frame of the page (the outer box) and read its width in the right-hand panel. Desktop designs are often 1440 pixels wide; mobile designs often around 375 to 390.
- Set your browser to that width. In Chrome, open the developer tools (Ctrl+Shift+J or Cmd+Option+J), click the phone-and-tablet icon to open device mode, keep "Responsive" selected and type the same width into the width box.
- Take a full screenshot. In the same toolbar, open the three-dot menu and choose "Capture full size screenshot". Export the same page from Figma.
- Put them next to each other. Open both images at the same zoom and go down the page section by section.
Your laptop is probably narrower than 1440 pixels, so comparing it with a scaled-down Figma frame compares two different layouts. Device mode is still an approximation; do a final check on a real phone.
Is the font the one that was designed?
Start with type, because it changes everything else on the page.
Fonts go wrong in two quiet ways. The font file doesn't load and the browser shows a fallback, or the regular weight loads but the bold doesn't. In the second case, the browser draws a fake bold by thickening the regular letters.
We tested both on a local page. With only the regular file available, a bold headline was smudged and slightly uneven, and Chrome reported it was really using the regular font. With the font name misspelled, the browser used a fallback that made the same headline about 5% wider, enough to push words onto a new line and change how the whole section sits.
To check yours: right-click a heading, choose Inspect, open the Computed tab and scroll to "Rendered Fonts". Chrome lists the font it actually used. If it names Arial, Times or another font the designer didn't choose, or "Regular" where the design uses Bold or Semibold, you've found a difference worth reporting.
Do the sizes and spacing match?
Next, measure the gaps. Spacing is where "calm" turns into "cramped" or "empty".
In Figma, select an element and hold Alt (Option on a Mac) while hovering over its neighbour. Figma shows the distance between them. In Chrome, hovering over an element with the Inspect tool shows its size and the space around it.
Compare a few things on each section:
- The gap above and below each heading
- The space between cards, and inside them
- Button height and the space around the text in it
- Line spacing in body text and the width of a paragraph
You don't need to check every pixel. Look for a difference that repeats, such as every section having less space above it. That usually comes from one setting, so it's one fix rather than twenty.
Are the images and texts the same as the design?
Designs are made with ideal content. Live sites get real content.
Images are often placed in fixed frames that crop them to fit. A tall photo in a wide frame loses its top and bottom, so a face or product can end up cut off. A photo heavily compressed to load faster can look soft. Compare each image's crop and sharpness with the design, and check whether the design used the same photos at all.
Text in a design is often shorter and tidier than the final copy. A headline that fit on two lines in Figma might need three on the live site, and a card with an extra sentence pushes the row out of line. If the live text is longer than the design's, that's a content decision as much as a build problem. Decide whether to shorten the text or ask for the layout to cope with it.
What happens at widths the design didn't show?
Most designs show two or three versions of a page: desktop, mobile and sometimes tablet. Visitors use every width in between.
Drag the device mode width slowly from narrow to wide. Watch for headings that wrap awkwardly, images that suddenly change size and columns that squeeze before they stack. Note the width where it happens.
Behaviour is the other gap. A static design doesn't always show what a button looks like when hovered or pressed, how the menu opens on a phone or what the header does when you scroll. If the design never specified it, the developer had to decide. You can still ask for a change, but describe it as a new decision rather than a mistake.
When is a difference not a defect?
Some differences are normal. Knowing them saves you a frustrating round of feedback.
- Text rendering. Browsers and Figma draw letters slightly differently, and Windows and Mac differ too. Small differences in sharpness or thickness are expected.
- Real content. If you changed the copy or photos after approving the design, the layout will differ.
- Widths between designs. The developer has to make choices there. Judge whether it looks intended, not whether it's identical.
If a difference isn't one of these, it goes on the list.
If you'd rather the live site match what you approved, design and build should come from the same place. At Aruno, you approve every screen before development starts. Mihai handles most design and build work himself; on larger projects, collaborators work under his design direction. If your current site was built by someone else and you'd like an outside view of what visitors see, our website audit reviews design, UX, speed, copy and SEO. Book a free intro call, nothing to sign, or message us at hi@aruno.studio, on WhatsApp or Telegram at @mihaipostelnicu.
How do you write feedback a developer can act on?
Good feedback names the page, the width, what you see now and what the design shows instead.
Here's the difference in practice.
| Vague | Specific |
|---|---|
| "The homepage feels cheap" | "Homepage hero at 1440px: headline shows a fake bold, Rendered Fonts says Regular. Design uses Semibold." |
| "Spacing is off" | "Every section at 1440px has about 40px less space above the heading than the design" |
| "The photos look bad" | "Team photos are cropped at the forehead. Design shows the full head and shoulders." |
| "Mobile is weird" | "Between 768px and 900px, the three service cards squeeze to 200px wide before stacking" |
Number each item and attach the two screenshots, cropped to the same section. That turns one long conversation into a list someone can work through and tick off.
Send it as one list rather than a stream of messages, so you can check the result in one sitting.
How do you confirm it's fixed?
Repeat the same comparison with the new version, at the same widths.
- Rendered Fonts shows the designed font and weight on headings, body text and buttons
- Section spacing matches the design at the design's widths
- Images show the same crop and look sharp
- The layout holds at every width between the designed ones
- Buttons, menus and the header behave the way you agreed
- The site looks right on your own phone, not only in device mode
If the mobile layout has bigger problems than design details, our guide to sites that look broken on mobile covers those. If the images are sharp but slow to appear, see why a site loads slowly on mobile.
Frequently asked questions
These answers help you agree what needs correcting and how to review it.
Should a website look exactly like the Figma design? At the widths the design shows, it should be very close: same fonts, sizes, spacing, colours and crops. Pixel-for-pixel matching isn't realistic, because browsers draw text differently from Figma and real content changes.
Why do fonts look different on the website than in Figma? Usually the browser is using a different file or weight than the design. Check Rendered Fonts in Chrome's developer tools. If the font is correct, small differences in sharpness come from how browsers and operating systems draw letters.
Is it the designer's or the developer's job to fix this? If the design specified it and the site differs, it's a build fix. If the design never showed that width, state or piece of content, it's a decision for the designer and developer together.
Can I check the design myself without Figma skills? Yes. Ask for a view-only Figma link or exported images of each page at their full width, then compare with full-size screenshots from Chrome's device mode at the same width.
The site you approved is still in that Figma file. Compare one page at the design's own width today, and you'll know exactly what to ask for.
