Why did our new design look great in Figma and worse once it was built with our real content?

A window display looks perfect because the boxes are empty. Same size, same weight, stacked flush, no dented tins, no odd shapes. Then the real stock arrives and nothing sits square.

A mockup works the same way. The designer types the heading, so it is the length that fits. They place nine team members, because nine fills the grid. Every card has a photo, because they picked the photos. None of that is dishonest. It is just that the content in the file was chosen to suit the layout, and your content was not.

So the built site is not badly made. It is the first time anyone has seen the design holding your actual stock.

In our projects, almost every “it looked better in Figma” complaint traces back to one of four mismatches. They are worth naming because each has a different fix.

Headings are the most common. The mockup says “Built for growing teams” at six words. Your CMS says “Built for growing teams who need compliance reporting without hiring a compliance officer” at fourteen. The heading wraps to three lines, pushes the paragraph down, and the hero that was balanced is now bottom-heavy.

Counts are second. A grid designed around nine items looks composed. Load it with three and you get a row of cards floating in a field of white space, with a hole where the second row should be. Load it with eleven and the last row has two cards where the others have three.

Missing images are third. The mockup gave every case study a photo. In reality four of your eleven have none, so the CMS renders a grey rectangle, or worse, collapses the card so it is shorter than its neighbours.

Numbers are fourth and the quietest. The dashboard mockup said £12k. Your real customer’s figure is £1,240,000. The number no longer fits its container, the label beside it drops to a second line, and a stat block that read as clean now reads as cramped.

If one thing on your new site looks visibly wrong, it is probably a row of cards. In Figma a designer can drag three cards to the same height by hand, so the row has one clean bottom edge. The browser does not do that by default. It sizes each card to its own content.

So the card with a two-line title and forty words of description is taller than the card with a one-line title and twelve words. The bottom edge goes ragged, the buttons inside the cards sit at three different heights, and the eye reads the whole row as sloppy.

This one is genuinely fixable in the build. Equal-height cards, buttons pinned to the bottom of each card, and a minimum height so a short card does not shrink to nothing. Ask for it by name. If the person who built it says the content varies too much, that is a design question, not an excuse: the answer is usually a character limit in the CMS.

The emptiest version of a page is almost always the version no one has designed. A search with no results. A blog category with one post. A customer dashboard on day one, before they have done anything.

We ask for these on purpose now, because they show up in real traffic more than teams expect. A new user’s first screen is the empty one. It is the page that decides whether the product feels finished.

An empty state needs three things: a line saying what would be here, a line saying how to get it, and a shape that holds the space so the page does not collapse to a header and a footer. It takes ten minutes to specify and it is the single cheapest thing you can add to a design review.

Every element can be correct and the page can still feel cheap. The reason is rhythm.

A mockup has even gaps. Same space between every section, same space between every card, edges lining up down the page. Real content breaks that. One section has a three-line heading and the next has one line, so the vertical gaps stop matching. One row of cards is ragged at the bottom. One image is a slightly different crop.

Nobody consciously notices any of this. They notice that the page feels unconsidered. Uneven spacing reads as carelessness, and carelessness reads as an unserious company. That is why the reaction to the built site is emotional rather than analytical. Your team is not saying the heading is too long. They are saying it does not feel like the thing they approved.

This is a process failure, not a build failure, and you can prevent it in an afternoon. The mistake is reviewing mockups filled with the content that flatters the design. Review them with the content that attacks it.

Do these five things, in this order. The first four happen before a line of code is written. The last one happens at review.

The whole method rests on one swap: judge the design against your content, never against its own.

1. Pick your three worst real pages, not your three best. The service page with one item. The case study with a forty-word title. The team member with no photo.
2. Ask for those exact three as mockups, with text pasted from your CMS. Not shortened, not tidied, not placeholder copy.
3. For every list and grid, write down the minimum and maximum count it must survive. "Between 2 and 14 integrations." That single number changes how the grid is built.
4. For every image slot, say what happens when there is no image. A colour block, a fallback, or the card hides itself.
5. When the build lands, check it against those same three pages. Checking it against the mockup only tells you the developer copied the file.

Rebuilding rarely fixes this, and it is worth saying before you pay for it. If the layout assumed regular content and your content is irregular, a second build makes the same assumption again. You get the same ragged row, sharper.

There are two real options. Make the content regular, which means writing character limits into the CMS and holding to them, and that is a standing cost your team pays forever. Or make the layout tolerant, which usually means plainer: a single column instead of an asymmetric grid, a consistent card instead of a feature mosaic, one image ratio instead of three.

If your content genuinely varies, take the plainer layout. A design that always holds is worth more than a striking one that holds on a good day. We would rather ship a simpler page than hand over a grid your team has to fight every time they publish.

And you do not always need new design at all. If the mockup was fine and only the cards are ragged, that is an hour of front-end work, not a project.

What content would make this page fall apart, and do we have any of it?

Ask it of every screen, out loud, in the review. If nobody can answer, the design has not been tested yet. If somebody can answer and the answer is “the pricing page, we only have two plans,” you have just found the page that will look wrong at launch, while it is still free to fix.