Design

Designer Guide – Design Requirements for Human Made projects #

Download: Designer Guide – Design Requirements for Human Made projects V1 PDF

Status V1 – Rolled Out_Sep 8, 2026

This document sets out what we require of designers on a Human Made WordPress project. Your designs are translated directly into the WordPress theme, which powers both the front end and the editing experience the client uses every day. 

The guide has three parts, which match the three layers of the design system: foundations, components, and pages and templates.

Three principles apply throughout:

• We’re building a system for making web pages, not just designing a few fixed pages. What we deliver is a WordPress theme that lets editors build many different kinds of pages, not a small set of pages that never change. Your designs should show how the system solves the problems the client has right now, and also leave room for it to solve new problems later.
• Each layer builds on the one before it. Components use the values (“design tokens”) set in the foundations. Templates are built from components. If you create one-off values that break an established pattern, it adds extra work and makes things harder to manage.
• Naming matters. Names get used everywhere: in the designs, in the code, in project tools, and in what editors see. Using the same names in all these places avoids confusion. Choose names that describe what something is for, not what it looks like. “Primary” and “Large” will still make sense after a rebrand. “Dark Blue” and “18px” won’t.

Foundations #

These are the set of rules that every component and template follows. Think of it as a schema, not just a reference document: every value you define becomes a named token used in the build, and everything in your designs has to use those tokens. More and more, this process is automated—but that only works if tokens are defined and named the right way, as explained below.

Typography #

Font families and weights #

• List every font family used on the site. For each one, list the exact weights and styles used (for example: Regular 400, Semibold 600, Italic 400).
• For custom or licensed fonts, give us the font files (WOFF2 is preferred) or a way to get them, along with any licensing rules we need to follow when hosting them ourselves.
• Keep the list small. Every extra font weight is another file visitors have to download.

Font sizes #

• Pick a fixed list of font sizes—at least 6. Every piece of text in the design must use one of these sizes.
• Name the sizes by what they do, not by their pixel value. For example: Small / Medium / Large / X-Large / XX-Large / Huge, or a numbered scale. Editors in WordPress will see these names.
• Sizes should be fluid. That means you set a minimum size (for small screens) and a maximum size (for large screens), and the text scales smoothly in between. This is built into WordPress already, and it’s our preferred way to handle responsive text.
• Mobile text should use the same named size as desktop, and rely on the fluid range to adjust. Only use a different size token on mobile in unusual cases, and only after agreeing it with the engineering team, since it’s tricky to build and maintain.
• Confused about fluid typography? Check out these resources for Figma:
  • Simulating fluid design in Figma: a practical guide
  • Fluid Typography Generator Figma plugin

Line heights #

• You can define a set of line-heights to pair with font sizes and families.
• However, WordPress doesn’t automatically pair line heights with font sizes, so we build that pairing ourselves—but only where you’ve defined it in the designs. Be sure to include both font size, family, and line-height in your Figma files.
• Unitless line heights (like 1.2 or 1.5) are better than pixel values.

Spacing #

• Define either a spacing scale (a base number and a multiplier, like 4px × 1–16) or a fixed list of named spacing sizes (like 2X-Small through 2X-Large). Either approach works. Most projects use 6–10 named values.
• Spacing tokens can be fluid too, so gaps and padding shrink a bit on mobile. Set a min and max for each value, just like you do for font sizes.
• Every margin, padding, and gap in the design must use one of these defined tokens. This includes space between sections, between components, and inside components.
• You also need to define the default spacing value used for blocks. WordPress calls this blockGap. To change this value per-block, we need to override the spacing manually.
• In Figma, label spacing with the token name instead of the raw pixel number whenever you can.

Colour #

• Make a named list of every colour used on the site.
• Use names that describe the role of the colour, not what it looks like: Primary, Secondary, Accent, Surface, Contrast—not Dark Blue or Off White. Role-based names still make sense after a rebrand, and they show up correctly in the editor.
• Include neutral colours (like backgrounds, borders, and muted text) and status colours (Error, Success, Warning, Info) as named colours too—don’t create these on the fly.
• If your design uses gradients or duotone image effects, define those as named presets as well.
• For every colour, think about how it works both as a text colour and as a background colour (see Accessibility below).

Borders and shadows #

• Define the border styles used across the site: widths, styles, corner roundness, and which colours borders use. If there’s a standard set of corner sizes (like Small 4px / Medium 8px / Pill), name those too.
• Define box shadows as a small set of named presets (like Low, Medium, and High elevation). WordPress already supports named shadow presets, so avoid making up a new shadow for every component.

Element styles #

Using only the values you defined above, create a labeled example of every basic content element. These are the default styles that apply across the whole site, before any component-specific styling is added:

• Default text styles
  • Body / paragraph text (the default text style)
  • Headings 1 through 6
  • We recommend including or testing your styles with a variety of content and lengths. Sometimes designs look great for a short headline like “GODZILLA DEFEATS KONG” but fail at “Markets tumble as iconic domestic gorilla unseated by foreign competitors.”
• Links, including hover, focus, and visited states
• Buttons, including default, hover, focus, active, and disabled states
• Lists, both ordered and unordered, including nested lists
• Blockquotes and pull quotes
• Images with optional captions 
• Tables, including the header row, body rows, and any striped-row styling
• Code or preformatted text (if the site will publish any)
• Horizontal rules / dividers
• Basic form elements: text inputs including dropdowns, textarea, and search inputs, along with labels, help text, and error state (if forms are part of the project)

A good test: paste a long, messy article into your design—one with headings, lists, quotes, tables, and images with captions—and see how it looks. Real clients publish real content, not placeholder text.

Grid and layout #

Designs are usually built around a grid, and WordPress gives us layout blocks (Group, Columns, Grid) to build with. Here’s what we need from you to set those up:

• WordPress layouts are built around a standard “content” width and a “wide” width. Define both, plus how things behave at full width (full bleed).
• The grid itself. Tell us the number of columns, the gutter width (using a spacing token), and the outer margins at each screen size.
• Fluid or fixed. Tell us whether your layouts stretch smoothly with the screen size (fluid) or jump between fixed sizes at set breakpoints (fixed), and list the screen widths you designed for.
• Stacking behavior. Explain how multi-column layouts change based on context—when do they stack, and in what order? What happens when the block has plenty of space around it, and what happens when it’s in a tightly-packed grid, or on smaller screens?
• Note that WordPress’s Grid block can also work by setting a minimum column width instead of fixed breakpoints, letting columns wrap naturally. Designing with that idea in mind (“columns are at least this wide, and wrap when needed”) often leads to simpler, sturdier results. Familiarize yourself with how the grid block works.

Responsive design #

• Design responsively. Design one layout that works across all screen sizes—huge monitors, small laptops, tablets, phones, and everything in between—instead of thinking about desktop and mobile as separate designs. You can combine variables and modes in Figma to design components that scale responsively.
• Keep the same content order across all screen sizes. Rearranging content between screen sizes adds a lot of complexity.
• Don’t set separate values for desktop and mobile unless you have a good design reason. Use fluid values instead, so they resize automatically. This keeps things simple and avoids extra complexity.

Iconography #

• If your design uses a set of icons, give us an SVG file for every icon, named consistently using kebab-case (for example: arrow-right.svg). 
  • These SVGs should be a single, flat color, unless your design calls for multi-colored icons (such as FontAwesome’s “duotone” icon style).
• Tell us what sizes icons appear at, keep the stroke width consistent, and note any rules for pairing icons with text (spacing, alignment, shadows—using the spacing values you already defined).
• Include the full icon library with your designs, or provide a link to an external icon library.

Accessibility baseline #

We aim to meet WCAG 2.2 AA accessibility standards. This should be part of the design system from the start—not something checked at the end.

Design with accessibility in mind, and think about how other people will use your design system. 

Start by thinking about who will use the site, and what situations they’ll be in. This includes people with different vision, movement, and thinking abilities, as well as people using the site in tricky situations (like bright sunlight or a shaky internet connection). Thinking about real users like this is better than just following a checklist.

Be sure to keep in mind:

• Adequate font sizing
  • Your site’s body copy shouldn’t be smaller than 16px.
• Color contrast
  • WordPress will warn editors if they pick colours that don’t work well together, so make sure your colour palette offers good, accessible combinations. 
  • You can test these with Figma’s native color-contrast checker, or use something like WebAIM’s contrast checker and the official APCA contrast checker.
  • Keep color blindness in mind when designing. There are community plugins in Figma that simulate different 
• Icons
  • Don’t rely just on icons to convey meaning in your designs. As often as possible, include text alongside your icons to help users understand what information you’re communicating.
• Forms
  • When it comes to designing forms, clear beats clever. Include visible labels, and place them directly next to or above each input field rather than relying on disappearing placeholder text.
  • UI components like form fields should meet a minimum 3:1 color contrast ratio.
• Interactions
  • Make interactive elements large enough for people to easily tap or click—at least 24x24px is recommended
  • Design link and button interactions, including focus states
    • Don’t rely on color alone to convey information (for example, hover states)
    • Link and button color combinations should meet minimum color contrast requirements (4.5:1 for normal text, 3:1 for large text or UI borders)

Think about integrating an accessibility checker Figma plugin like Stark into your workflow to help you test your designs throughout your process.

Components #

Building components will take up a large part of the work on any project. The word “component” is used loosely on purpose—it isn’t an official WordPress term. Technically, a component might end up being built as a block, a pattern, or part of a template. Keeping the term general means your design doesn’t need to decide that in advance.

For example, a component could be:

A customized Latest Posts block

An dynamic opinion grid

A newsletter promo

Your site footer

Think generic and reusable #

Each component should work on its own. You should be able to place it on any page, in any order, and still build many different layouts with it. 

Every component is tracked as its own item in Jira, and each one is built and approved separately. This is how we measure the design work—by counting components. We’ll usually suggest a rough number that fits the project timeline. 

It’s better to have a smaller set of polished components than a big, messy one. Think about how flexible each component needs to be so it can handle different kinds of content.

Everything is a component  #

This includes headers, navigation menus, footers, and sidebars—not just content blocks. Nothing on the page should sit outside this system.

• Reuse core blocks. WordPress comes with many built-in blocks already. Since editors can use these too, make sure they look good in your design. Reusing them also saves development time.
  • Be sure to check the WP version you’re designing for, as new core blocks and capabilities ship with each new version.
• Keep each component complete and standalone. Every component design should show its responsive behavior, any animations or interactions, and all its variations and options.

Follow our design system rules  #

• Build your designs using the values from the design system’s foundations. If you break from the design system on purpose, write a note explaining why—otherwise, we’ll just use the closest foundation value instead. 
• Use clear, consistent names for components, since these names show up everywhere.
• Keep one source of truth. The component in Figma is the master version: use it inside your page layouts, but don’t edit a component directly on a page design. Instead, update the original component, so every place it’s used stays in sync.

Pages and templates #

Even with all this systems thinking, it’s still important to think in terms of pages: a page usually reflects a key thing a user is trying to do or find. Page templates show how components come together to meet those needs. 

As with components, we’ll agree on a set number of templates to design and build for the project.

• Templates should be built entirely from your components. You can also use WordPress’s built-in blocks.
• Approach adding any new component for a template as if you’re adding a new generic and reusable component that can be used in any context. 
• Use templates to show off grid layouts and any interactive behavior that doesn’t apply at the component level.
• Your designs will be built either as a WordPress template, or as a pattern people can pick when creating a new page.
• We also need templates for WordPress’s core functionality, along with any custom page templates. At minimum, this includes:
  • Single post
  • Single page
  • Post archives, including category and tag pages, date archives, author pages, and search results
  • 404 page
  • If you don’t know how the WordPress template system works, read up on it. You don’t need to understand the code, just the basic idea of how templates work.

Even here, keep thinking generically. Ask yourself: could this design be reused for other kinds of content too?

Animation and interactions #

Any animations or interactions should be reviewed with the dev team before they’re finalized in the design or shown to the client—especially if you’re assuming the use of a specific library or framework. If an animation is more complex than a simple transition or hover effect, talk through the approach with developers early, and share examples like a reference video or a link to a similar site. Where possible, build your animations into your components in Figma. 

If time allows, build a clickable prototype in Figma. This helps in two ways: it gives the client a realistic feel for the site before development starts, and it gives developers a clear starting point for understanding hover states, transitions, and other interactive behavior that a static design can’t show.

Design system organisation #

Put everything in one place. Typography, colour, spacing, icons, element styles, and components should all live in a single design system file in Figma. This matches how the system gets built: 

• Templates are made from components
• Components are made from foundational design tokens

Keeping everything together makes it easier to catch problems early—like a colour or spacing value that’s drifted off—or a component that no longer matches its original. Catching these early stops them from spreading across many page designs.

The design system isn’t just a handoff document. Developers use it as a reference throughout the whole build, not just at the start.

Treat it as a living document. If you change a token, element, or component later—even after design has moved on to templates or build—update the design system too. That way, it stays a source developers can always trust, instead of an outdated snapshot.

Design system structure #

The design system should be organized so anyone opening them for the first time understands how they’re put together:

• Foundations
  • Typography (font families, weights, size scale with token names visible)
  • Colour (the palette with semantic names)
  • Grid and spacing (spacing scale, grid and breakpoints, gutter annotations)
  • Iconography (icon set at documented sizes, labels visible on canvas)
  • Content elements (body text, headings, links, buttons, lists, blockquote, tables, forms, etc.)
  • Any additional styles used, such as border-radius and elevation
  • Any additional project-specific assets, such as logos
  • Publish this file as a Library
• Blocks
  • Individual blocks not covered in Foundations, patterns, and template parts
  • Show responsive states side-by-side for comparison (for example, if a navigation bar is full-width on desktop, and collapses down to a hamburger menu on mobile)
• Patterns
  • Reusable groups of blocks curated into specific, small layouts. Not full pages, but pieces that you can use to create templates.
• Templates
  • Both default WordPress template pages (like posts, search, 404, etc.) and site-specific templates (landing pages, custom post types, e-commerce, etc.)

Depending on the size of your project, you might want to have all of these sections in one Figma file, or you might want to break them out into separate files.

You can also work in a separate file for ideation and experimentation, but make sure all of your final files follow these guidelines.

Handing off design systems to developers #

• Keep the design system as a clean handoff file, separate from your working or exploration files. Remove any rejected ideas or work-in-progress before it reaches Dev Mode—a messy file makes it unclear what’s actually final.
• Publish the foundations and components as a Figma library, rather than just sharing raw files, so that page and template files reference them instead of copying them. 
  • This keeps the component as the single source of truth: edits made directly on a page will show up as clearly out of sync, instead of quietly creating a separate version.

• Every color, spacing token, and type value should point to a named Figma variable or style from the library—not a raw hex code or pixel number.
• Note any place where you’ve intentionally moved away from a token or component.
• Add annotations to your designs to communicate interactions, link destinations, and other important information that might not be obvious from the designs alone.
• Check the file in Dev Mode before handing it off. This shows you what a developer will actually see, which is often less than what seems obvious while you’re working in the design file.

Handoff isn’t a one-and-done step. Talk with your developers regularly throughout the project—not just at the end—to make sure what you’re designing is actually possible to build in WordPress. Catching issues early saves rework later, and keeps the whole team on track to deliver what the client expects.