How to Review a Website for Design-System Consistency

Compare behavior before comparing appearance

Choose repeated elements such as navigation, buttons, form fields, tables, and dialogs. Compare their names, keyboard behavior, loading and error states, and expected outcomes. Two controls can look alike but act differently; that is often more disruptive than a small visual variation.

Example: a shared button with two meanings

Suppose the same “Save” button closes a dialog in one flow but keeps it open in another, without explaining why. Record both pages, the state before and after activation, and what information the person needs next. The issue may be inconsistent behavior, or the flows may have different requirements; confirm the component contract and task before proposing a global change.

Use the component contract

For each shared component, locate the documented purpose, variants, content rules, and states. Check the rendered product against that contract and record where a team has made a local exception. If the documentation does not cover a real use case, capture the gap instead of treating every deviation as a defect.

Look for drift across the same journey

• Do primary and secondary actions keep consistent labels and emphasis?
• Do validation and confirmation messages follow the same useful pattern?
• Can users predict where navigation, help, and account actions live?
• Do mobile and desktop variants retain the same meaning and task order?
• Are content terms consistent across the interface and its supporting guidance?

Separate visual preference from user impact

A mismatch matters when it changes meaning, discoverability, accessibility, or the ability to complete a task. Record those effects and the affected pages. If the difference is only a stylistic preference, say so and let the system owner decide whether to standardize it.

Recommend a system-level fix only when evidence supports it

If the same issue appears in several places, link the examples and identify the shared component or content rule. A system change can reduce repeated defects, but may also affect every screen using the component. Verify one representative flow after the change before closing the finding.