Interface design

When to use it

Design, implement or review WordPress user journeys, responsive layouts, UI states, design tokens, editor/front parity, RTL and visual-regression checks. Not for WCAG criterion audits (wcag-review), theme.json internals (theme skill) or wp-admin implementation (admin-ui).

Boundaries and hand-offs

• WCAG criterion-by-criterion conformance: wp-devkit-wcag-review ; accessibility defects in code: wp-devkit-accessibility-review .
• Theme templates, theme.json mechanics: wp-devkit-theme-development ; wp-admin screen implementation: wp-devkit-admin-ui-development ; block internals: wp-devkit-block-development .
• Speed measurement and tuning: wp-devkit-performance-review .

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

/wp-devkit:design-review <target-path>

The short form /wp-devkit:design requests an implementation; use the review form to stay read-only.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

$wp-devkit-ui-design
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

• acceptance-checklist.md : Acceptance checklist
• analytics-and-experiments.md : Analytics and experiments
• design-systems-and-tokens.md : Design systems and tokens
• localization-and-content-design.md : Localization, RTL and content design
• research-and-usability.md : Research and usability evidence
• responsive-states-and-interaction.md : Responsive layout, states and interaction
• ui-design-workbook.md : WordPress UI design workbook
• visual-regression-and-devices.md : Visual regression, devices and performance
• wordpress-ui-surfaces.md : WordPress UI surfaces and ownership

How a review runs

1. Capture the current journey and content (URLs, viewports, screenshots). Define the user outcome; separate visual polish from structural reconstruction.
2. Locate the owner of each surface and token ( references/wordpress-ui-surfaces.md , references/design-systems-and-tokens.md ). Preserve working navigation, links and content.
3. Check states, forms, layout and interaction against references/responsive-states-and-interaction.md : loading, empty, error, success, long content, 320 px to wide, zoom, keyboard, focus visibility, target size, reduced motion.
4. Check locale and RTL with stress data ( references/localization-and-content-design.md ).
5. Identify the evidence available for any usability, conversion or performance claim ( references/research-and-usability.md , references/analytics-and-experiments.md ); mark unsupported claims "not measured".
6. Report observed rendered and interaction evidence, plus proposed acceptance checks. A review does not authorize a redesign. Read references/ui-design-workbook.md for the decision table, symptoms, false positives, severity and worked example. Use references/acceptance-checklist.md for delivery acceptance and references/visual-regression-and-devices.md for the rendering matrix, Playwright baselines, Core Web Vitals evidence and axe automation.

What you get back

Lead with the result and what was observed (viewports, browsers, locales, assistive tech actually used). Confirmed concern: location (file:line or URL+viewport), actor, trigger, reachable path, impact, confidence, minimal fix, regression check. Keep candidates and unmeasured claims separate. For implementation include the user flow, responsive and keyboard checks, screenshots when available, empty/loading/error/success states, commands with exit codes and unexecuted checks. A visual pass does not prove usability, conversion, screen-reader behavior or conformance.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.