Theme design review checklist #

This page is for theme designers who review a design: their own before handoff, or a colleague's. It checks the design (mockups, tokens, components and the decisions behind them), before or alongside the build. To check the built pages, use the Design QA checklist; to review template code, use Checklist: code review for templates.

Contents #

1. How to run the review
2. Concept and scope
3. Content fit
4. System consistency
5. Accessibility in the design
6. Languages and brands
7. Editor experience
8. Project rules
9. Outcome

How to run the review #

Review in one sitting of one to two hours, with the mockups, the token table, the component inventory and the mapping sheet open. Write findings as you go, each with the frame and the item below it fails. A second reviewer who did not make the design finds more.

Concept and scope #

• To do: The design answers the brief's goals, in a sentence you can say.
• To do: Every item of the inventory is designed: frame, class views, special pages, blocks (From mockup to theme).
• To do: Nothing is designed that has no content behind it.
• To do: The number of layout types, view modes and block view types is as small as the site allows (Designing view modes).

Content fit #

• To do: Every visible element maps to a field (Mapping a design to content classes).
• To do: Shortest and longest content shown for headlines, intros, names and labels.
• To do: Every optional field has an empty design (Designing for editors).
• To do: Rich text elements all styled.
• To do: Lists for zero, one, few and many items.
• To do: Images in any shape handled (Designing image crops and art direction).

System consistency #

• To do: All values come from the token table; no one-off colors, sizes or spaces.
• To do: One accent and one component radius.
• To do: Every color token has a dark value, and every key frame is drawn in dark.
• To do: Each component appears the same everywhere it is used; near-duplicates merged (Component inventory).
• To do: Names match across design tool, inventory and planned class names.

Accessibility in the design #

• To do: Contrast ratios measured and written down for both themes (Color contrast).
• To do: Focus state designed for every interactive element (Designing interactive states).
• To do: No meaning carried by color alone (links, errors, current page, required fields).
• To do: Heading structure makes sense when read in order (Landmarks and headings).
• To do: Targets large enough to tap; layouts work at 200% zoom.
• To do: Motion has a reduced version (Motion and interaction).

Languages and brands #

• To do: Longest language tried in navigation, buttons and headings (Designing for many languages).
• To do: Mirrored layout considered for right-to-left languages.
• To do: No text inside images.
• To do: For several brands: only matrix items vary (Designing for several brands in multisite).

Editor experience #

• To do: Editors can achieve every designed look without remembering special rules (Designing for editors).
• To do: Block view types have clear names (Designing layout blocks).
• To do: Field guidance written where lengths or image shapes matter.

Project rules #

• To do: Nothing in the design needs inline styles or inline scripts to build (CSP-safe design).
• To do: Fonts self-hosted, licenses checked; third-party embeds listed with placeholders (Designing for performance budgets).
• To do: The design overrides shipped designs in its own extension, never by editing them.
• To do: Administration styling, if touched, uses the shared admin components and tokens (admin4 components).

Outcome #

End the review with one of: ready for handoff, ready after listed fixes, or needs another round. Record the result and the findings next to the design in the theme's repository.

Related pages #

• Handoff checklist
• Design QA checklist
• An accessibility audit for every release
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.