How to conduct a design review? Don't wait until it goes live to start looking for pixel differences

By the time all the development is completed, it is usually too late to ask the designers to focus on picking out "two pixels missing here". If a component is implemented incorrectly, dozens of pages will follow suit. Once the real interface is connected, the empty state, errors and long data are exposed. If only screenshots are taken before going online, the complete operation will be missed. Design review should accompany the development progress. The earlier systemic problems are identified, the lower the repair cost will be.

01 Design walkthrough is not another name for visual acceptance

It needs to confirm whether the design intent has been fully implemented, including information hierarchy, interactive feedback, business status, responsiveness, accessibility, content and visuals. Pure comparison of color and spacing can only reveal surface differences. Only going through business processes may gradually distort the brand and components.

02 It is recommended to set five check nodes

03 When conducting the first check, look at systemic issues first. Don't start with a specific icon

If the font loading method, container width, spacing Token or button component implementation is incorrect, the same deviation will occur on every subsequent page. In the first round, priority should be given to checking the basic components, raster, responsive and interactive patterns. Once a systemic issue is confirmed, the development team should fix the underlying problem instead of applying patches one by one on dozens of pages.

04 Be sure to use real data and real characters

Design drafts often use perfect data: short names, neat amounts, three lists, and users having full permissions. When conducting walkthroughs, it is necessary to prepare long texts, empty data, extreme values, expired content, interface failures, different roles, and multiple languages. The enterprise system also needs to check the data range, field-level permissions, operation records and status conflicts.

If the screenshots match, it only proves that they are similar at a certain moment. Only when the complete task runs smoothly can it be close to a true reproduction.

05 First, fix the lookup benchmark to prevent both parties from seeing different pages

Before starting the review, it is necessary to unify the environment, version, browser, viewport, account role, test data and design draft version. The issues that designers encounter on a 1440px desktop may be completely different in the developed scaling ratio or in the old cache. It is recommended that the benchmark be clearly stated at the beginning of each round of review tasks, and standard screenshots or screen recordings be retained for key pages.

• Confirm the pre-release address and build version, and prohibit recording issues simultaneously in multiple old environments.
• Prepare representative accounts such as regular users, administrators, and users without permissions.
• Use real or desensitized long data, empty data, and failed data, not just the default Mock.
• Clarify the scope of this round of inspection: structure, status, responsiveness or visual details.
• Record the pages, components and versions of the design files to avoid having no basis to find after the repair.

06 Problems must be classified; otherwise, everyone will mark their own problem as "urgent".

07 Each question should be written so that others can reproduce it

"It's not right here" or "It's different from the design draft" are not executable issues. The more specific the records are, the easier it is for development to locate and the more objective the re-testing will be. If adjustments are needed regarding the design itself, new design decisions should be established instead of attributing all differences to development bugs.

08 Do not check all dimensions simultaneously in one check

It can be advanced in layers: first structure and process, then status and permission, then responsiveness and accessibility, and finally visual details. Complex projects can be checked by role, module or platform. Each time, the scope and approval conditions must be clearly defined; otherwise, the meeting may easily turn into the designer browsing the page on the spot, with problems scattered in the chat records.

09 What are the responsibilities of design, product, development and testing respectively

10 Closing the issue does not mean the developer says "fixed"

• Retest in the designated environment following the original steps to confirm that the problem has indeed disappeared.
• Check whether the repair affects the same components, other roles, and other sizes.
• Update design files, components or specifications to avoid using old rules again next time.
• If it is not to be repaired for the time being, record the reasons, risks, responsible persons and plan versions.
• After going live, randomly check the official environment to confirm that there are no new differences in resources, cache, and third-party configurations.

11 The quality of the walk check can be reviewed in this way

Observe the proportion of systemic issues, the number of repetitions of similar problems, the time from discovery to closure, the defects exposed after going live, and which design descriptions are most frequently misunderstood. The goal is not to make the problem list longer and longer, but to ensure that the next round of development generates fewer similar problems.

Frequently Asked Questions

At what stage of development should the design review start?

It should start when the basic components or the first complete process can be run. The earlier the implementation method is confirmed, the more it can prevent errors from being copied. It is most costly to wait until all the pages are completed before checking.

Do designers need to check the code?

Not necessarily. Designers mainly verify performance and behavior, while developers are responsible for code quality. However, for the design of tokens, component mapping, reactivity and accessibility, both sides need to jointly confirm the implementation rules.

The project time is very tight. Which steps cannot be skipped?

At least retain the inspection of basic components, the core end-to-end process, the real interface status, and the multi-device retesting before going live. Visual details can be graded, but critical tasks, permissions and error recovery cannot be skipped.

What is the difference between design review and test acceptance?

Testing pays more attention to whether the functions meet the requirements and whether there are any defects. The design review focuses on whether the design intent, interaction, state, responsiveness and visuals are fully implemented. The two overlap but cannot replace each other.