Accepting a UI implementation: visual differences or data problems?

Establish repeatable comparison conditions

Record the design version, running version, browser, viewport, operating-system scaling, language and account role. Prepare reusable test records and identify the expected state: fully loaded, empty or failed. A short name in the mockup and a long company name in the application are not equivalent conditions. A line break alone does not demonstrate an implementation defect.

Long real content is not an excuse for every broken layout either. If the agreed scope includes long headings and narrow screens, the implementation must follow its wrapping rules rather than cut off information. Controlled comparison should help locate a problem, not reduce the requirement for readable content.

Route each difference to the right investigation

• Visual implementation: hierarchy, size, color, spacing or alignment differs from the agreed design or shared rules.
• Resources: a font, image or icon is missing or comes from the wrong version.
• Interaction: clicking, returning, focus movement or loading feedback behaves differently from the agreement.
• Data: a field, amount, unit, permission or state is incorrect.

One defect may involve several categories. If a very long amount pushes a button away, first establish whether the amount is correct, then examine layout limits. Shrinking the number to hide an incorrect value is not a repair. Preserve the input, action, observed result and expected evidence in the issue record.

Check fonts and loading separately

Text can wrap differently because the browser substituted another font, not because the container changed. Engineering can inspect font-request failures, the font actually used and the layout before and after loading. The MDN CSS Font Loading API documentation describes mechanisms for observing font loading. Waiting for fonts to settle can improve screenshot consistency, but does not prove that the intended font succeeded or that every image and business request has finished.

Review the settled page and the first-load experience. If incoming fonts or images significantly move a control, treat that as a stability issue rather than selecting only the attractive final screenshot. Compare a cached visit with a first visit so that cached resources do not conceal the problem.

Write an actionable difference record

Suppose a hypothetical English record title covers an action button. Record the page, role, language, viewport, test-record identifier, steps and screenshot. State the expected behavior: the complete title wraps, and the button remains visible and operable. This can be reproduced. “The English page looks wrong” cannot establish the same conditions. Remove personal information from illustrative test records and shared evidence.

For differences such as font smoothing across platforms, determine whether readability or hierarchy changes before deciding that a defect exists. Different systems need not be pixel-identical. That flexibility does not excuse missing characters, covered controls, invisible focus or broken actions.

Retest the repair and its neighbors

1. Repeat the original conditions and record. Confirm that the problem disappeared rather than that the sample text became shorter.
2. Check another page using the same component so that a local patch has not broken shared behavior.
3. Try a different boundary sample, such as a missing value, long value or restricted record.
4. Complete the relevant click, submission and return path. A correct-looking screen is not evidence of a correct business result.
5. Record the repaired version and outstanding items, distinguishing defects, missing inputs and new requirements.

Design acceptance can approve the source designs, specified states and handoff material. Implementation acceptance establishes how the actual page behaves. Fees and revision rounds follow the agreed scope; a single screenshot cannot determine responsibility for an entire rework. A useful review ends with reproducible issues and verified corrections, rather than an open-ended demand to make the page feel closer to the mockup.

Report a mismatch with its design revision, actual record and reproduction path. The prototype handoff agreement helps distinguish a styling omission from a missing state or function; the existing-software redesign guide identifies behavior that must remain. Reviews within UI design services (Chinese) should produce reproducible findings rather than an unbounded request to make the implementation look more similar.