Most website designs are approved in a meeting. Someone shares the Figma file, stakeholders scroll through the frames, and the design gets signed off because it looks right. Nobody has checked whether visitors will notice the main call to action, whether the light grey body text is readable, or whether the hero still works once the real headline replaces the placeholder.
Those questions get answered later, after the build. By then every fix is a development ticket, a QA cycle and often a delayed launch. Most of them can be answered on a static design instead, in a few hours, with tools many design teams already use.
Why Problems Found After the Build Cost More
A change in Figma takes minutes. The same change on a staging site passes through several people before changes occur. The designer updates the file, a developer rebuilds the component, QA checks it across breakpoints, and someone reviews it again. If the component is reused across templates, one fix can touch dozens of pages.
The problems that slip through are rarely technical. They are design decisions nobody tested. A secondary button pulls more attention than the primary one. A feature grid reads as a wall of equal cards with no clear starting point. A demo form looks fine on desktop but sits under a sticky cookie banner on mobile.
Each of these is visible in the design file. Someone just has to look for them in a structured way before handoff.
What You Can and Can’t Test On a Static Design
Be honest about the limits. A static design can’t tell you how fast the page loads, how it renders in Safari on iOS, or how real visitors scroll and click. Those questions need a build, real devices and behavioural tools such as Hotjar or Microsoft Clarity once the site is live.
What a static design can tell you is how the page communicates. You can test visual hierarchy, first impressions, readability, colour accessibility and whether the layout survives real content. These are the areas where most redesign complaints start. They are also the cheapest to fix while the page is still a frame in Figma.
Timing matters too. Run the tests on high-fidelity frames with final typography and colour, not on grey wireframes. Attention models and five-second tests react to contrast, size and imagery, so a wireframe gives a misleading picture of what visitors will see first.
Treat pre-development testing as a filter, not a verdict. Its job is to remove the obvious problems so that post-launch testing can focus on behaviour.
The pre-development test sequence
The sequence below takes a few hours for a typical set of templates. It works best as a formal gate between design approval and development rather than an optional extra. B2B teams that hand their rebuild to an outside partner such as Veza Digital often write this gate into the project plan, so the developer receives frames that have already passed review.
Run the steps in this order:
- Check attention and hierarchy. Upload each key frame to a predictive attention tool such as the Attention Insight Figma plugin and look at where the heatmap concentrates. If the headline and primary CTA are not among the strongest areas, adjust size, contrast or spacing before anything else.
- Run a five-second test. Show the frame to 15 to 20 people in Lyssna or Maze for five seconds, then ask what the page offers and what they would do next. Vague answers usually point to a headline problem, not a layout problem.
- Check contrast and accessibility. Use a plugin such as Stark to test text and button colours against the WCAG contrast guidance. Body text needs a ratio of at least 4.5:1 for AA, and large text needs 3:1. Also check focus states and make sure no information is carried by colour alone.
- Replace placeholder content. Swap lorem ipsum and stock headlines for the real copy, the longest product name and the actual customer logos. Layouts that looked balanced often break when a headline wraps to three lines.
- Test the mobile frames separately. Repeat the attention and five-second checks on the mobile designs. Stacking changes the order in which elements are seen, and a CTA that leads on desktop can end up below three cards on a phone.
- Record every result. Save each heatmap and note each change in Figma comments, so the reasoning travels with the design.
Turning test results into a clean handoff
Testing only pays off if the results reach the developer. Place the before and after heatmaps next to the final frames, and mark which elements changed and why. Annotations in Figma Dev Mode let developers see that a button size or colour is a tested decision, not a detail to approximate.
If a test forced a trade-off, such as shrinking a hero image to lift the CTA, write that down as well. Otherwise the original version tends to come back during development, when someone decides the image looked better at full size.
Agree on what counts as a pass before you start. For example, the primary CTA must sit in the top attention areas on desktop and mobile, all text must meet WCAG AA, and at least two thirds of five-second test participants must describe the offer correctly. Clear criteria stop design review from turning into a debate about taste.
Keep the test files after launch. When behavioural data arrives, compare real click and scroll maps with the predictions. The gaps show where your team’s assumptions need updating before the next redesign.
Conclusion
A design that looks right in a review meeting is not the same as a design that works. Testing attention, first impressions, contrast, real content and mobile layouts before development turns sign-off into a decision based on evidence. It costs a few hours at the design stage and saves far more time than it takes once the build begins.
