How to Compare a Design With Its Implementation Without Arguing Over Screenshots

"It doesn't quite look like the design."

That feedback can be accurate and still leave a developer unsure where to start. The heading seems close. The colors look right. Something about the page feels heavier than the mockup, but nobody has named it yet.

A good design comparison makes that feeling easier to explain. It gives the designer and developer a shared reference, then turns visible differences into decisions they can act on.

The first step is making sure the two sides deserve to be compared.

Use the intended version of the design

Get the actual reference for the screen you're reviewing. That could be an exported image, a supplied screenshot, or an existing saved capture.

Check that it represents the current decision. An early mockup and a later implementation may differ because someone changed the design, not because the developer missed it.

Record the relevant context: the intended viewport, theme, language, content, and component state. If the reference is a desktop product page with three images, compare it with that screen and content before drawing conclusions about spacing.

When a matching source is missing, resolve that first. Generating a guessed "before" image makes the comparison look complete while weakening every conclusion that follows.

Match the conditions you can control

Capture the implementation at the reference viewport. Use the same text and images where possible, and wait for the page state you mean to assess.

A heading with different copy will wrap differently. A fallback font can change both line length and height. An open cookie banner can shift the entire first screen.

Those differences might be bugs worth investigating. They can also distract from the comparison you intended to make. Identify them explicitly so everyone knows what they're looking at.

If exact matching isn't practical, state the mismatch. You can still review broad hierarchy or content order, while treating fine spacing judgments more carefully.

Organize the pair in Preveo

Preveo's Design vs Implementation Use Case supports supplied image evidence and reachable page URLs, among its discovered source options. Through MCP, the agent can configure a comparison with separate named layers for the design and implementation.

For example:

Compare this supplied checkout design with the current implementation at the design's viewport. Put both in a Design vs Implementation thread under this project's Checkout folder. Run without macros, inspect the captures, and list the visible differences with a reference to the affected area.

The agent should discover the current configuration first. For an uploaded image, the workflow reserves an upload, sends the bytes, and creates a layer using the resulting blob path and capture viewport. The implementation side can use a reachable URL.

Supplying an export doesn't imply a live connection to the design tool. Be clear about which asset is the reference and where it came from.

Describe differences at the right level

Start with structure and hierarchy. Does the same information lead the page? Are sections in the intended order? Does the primary action have the intended prominence?

Then inspect typography, spacing, alignment, images, and component details.

This order helps avoid spending a review on a border radius while the main content column is the wrong width.

A useful observation sounds like this:

In the implementation, the order summary begins below the form heading. In the supplied design, their top edges align. That changes the balance of the two columns on desktop.

This is an illustrative example, but the structure is useful: location, visible difference, and effect. You can discuss whether the difference matters before choosing a fix.

If exact measurements are important, inspect the underlying layout values with suitable tools. A visual impression alone doesn't justify claiming a precise pixel discrepancy.

Separate a missed detail from an intentional change

Some differences are straightforward implementation issues. A missing icon, an unintended font weight, or a container using the wrong width can often be traced to a specific rule or asset.

Other differences need a conversation. Perhaps the design has no example of a long address. Perhaps the implementation wraps a label because the real translation needs more space.

Keep those decisions visible. "Matches the mockup" is a useful requirement only when the mockup covers the conditions the product actually has to support.

After an agreed fix, capture the implementation again against the same reference. Preserve the source pair if you need to keep the original review, since cloud reruns can replace captures.

The Preveo MCP reference explains how to connect your agent. Whether you use an agent or review directly, the end result should make the next conversation easier: here is the reference, here is the implementation, and here is the difference we decided to address.