How to Design for the WordPress Block Editor

Most WordPress tutorials show you how to make a site look polished on launch day. Almost none teach you how to keep it looking good six weeks later, after a client logs in and starts editing. That’s where well-designed WordPress projects quietly fall apart.

The difference comes down to process. Design in WordPress using a specific workflow – planning content structure first, configuring the design system second, building patterns and locks third, and testing with a real non-technical user fourth – and your site will survive real editing. Skip the workflow, and even a beautiful design breaks the moment someone edits it.

I’ve built this system through years of client theme work in the WordPress block editor. The seven steps below, done in order, produce a design that stands up to six months of client editing instead of just looking good in a demo.

Step 1: Map Your Content Before You Design Anything

Open the Site Editor last. The biggest mistake I see in rushed WordPress builds is jumping straight into visual design before mapping what the site actually needs to do.

Before touching a single block, sort your content into two categories:

Repeating structures appear on multiple pages: headers, footers, call-to-action bands, testimonial rows, pricing tables, staff bios. These are prime candidates for patterns or template parts.

One-off content appears nowhere else: a unique hero paragraph on the homepage, a specific case study layout, a one-time announcement. These stay as regular page content and don’t need to be systematized.

This sorting determines almost everything that follows. Skip it, and you build patterns for content that never repeats, or hard-code content that should have been editable.

Ask yourself: what will this client actually need to change once the site is live? Not what could they change, but what will they, specifically, actually touch. A restaurant owner updating a weekly menu needs a different structure than a consultant who updates one bio paragraph twice a year.

Map this in a two-column list before opening the editor: content type on the left, edit frequency on the right. Anything marked "frequent" gets built as an editable pattern. Anything marked "rare" or "never" can stay static or locked. This single step, done before any visual work, saves hours of rebuilding later.

Step 2: Configure Theme.json and Global Styles First

Once you know what you’re building, set up the design system before configuring any single page.

In a block theme, the design system lives in theme.json, a configuration file that defines color palettes, typography scales, spacing units, and layout defaults for the entire site. Global Styles is the visual interface built on top of theme.json – the place where you and the client interact with those settings inside the Site Editor.

Set this up before building a single pattern. Every color, font size, and spacing value a client will ever see should trace back to a value defined here, not a one-off value typed into a random block.

Here’s why order matters: if you build ten patterns first and configure theme.json second, you’ll spend the rest of the project reconciling inconsistent spacing and rogue hex codes that crept into individual blocks. Configure the system first, then build inside it.

Global Styles Setting	What It Controls	Effect on Client Editing
Color palette	Approved brand colors available in every color picker	Client can only pick from your palette, not arbitrary hex values
Typography presets	Font family, size scale, line height	Client can’t accidentally introduce a fourth heading style
Spacing scale	Preset gap and padding values (small, medium, large)	Client selects from consistent presets instead of typing custom pixel values
Layout width settings	Content width and wide/full alignment options	Prevents images or sections from breaking the grid
Block style variations	Pre-approved visual variants of a block (e.g., button styles)	Client picks from designed options instead of styling from scratch

Lock this down tightly and most layout drift never starts. This is also where you decide what belongs in a truly custom WordPress theme versus what a well-configured off-the-shelf block theme can handle.

Step 3: Build Block Patterns for Repeating Content

With the system in place, build the repeating structures you identified in Step 1 as actual block patterns, not as content you copy and paste page to page.

A block pattern is a predefined arrangement of blocks, saved and reusable across the site. This is different from a template part, which is a structural region like a header or footer that appears in the same position on every page using that template.

WordPress offers two pattern behaviors:

Synced patterns (formerly called reusable blocks) update everywhere simultaneously when you edit one instance. Use these for things that must always be identical everywhere: a newsletter signup block, a standard disclaimer, or a pricing table that never changes per page.

Unsynced patterns insert a copy that can be edited independently on each page. Use these as starting templates for things that share a structure but need unique content: individual case study layouts or testimonial rows.

Getting this choice wrong is a common early mistake. Sync something that needed independence, and a small tweak on one page silently changes it everywhere else. Leave something unsynced that should have been synced, and your pricing table drifts out of alignment across five pages within a month.

Ask these questions to decide: Does it need to look and read identically everywhere? Would an inconsistency damage trust or brand accuracy (pricing, legal text, contact info)? Is it updated centrally by one person rather than edited per-page? Would you be upset if someone changed it on just one page and not the others?

Answer yes to most, and sync it. If the section shares a skeleton but needs unique content per instance, leave it unsynced.

Step 4: Lock Down Structure, Leave Content Open

This step determines whether your design survives contact with a real client. WordPress’s block editor includes native locking controls that restrict moving and removing blocks, independently, per block. Lock the scaffolding, never the substance.

Lock these elements:

• Header and footer template parts
• Navigation menus and their container structure
• Section order on the homepage (hero, then services, then testimonials)
• Grid or column structures that hold repeating content
• Legal or compliance text blocks (footer copyright, business address)

Leave these open:

• Heading and paragraph text inside a locked section
• Images inside a locked gallery or hero block
• Button labels and links
• Individual items inside a pattern (the testimonial text itself, not the testimonial layout)

The decision framework is simple: lock structure, leave content editable. If a client action would change how the page is built, lock it. If it would only change what the page says, leave it open.

	Locked Block	Editable Block
What it protects	Structure, order, and layout integrity	Nothing; content is meant to change
Client can edit text/images	Yes, if only move/remove is locked	Yes
Client can delete the section	No	Yes
Client can reorder sections	No	Yes
Best used for	Headers, footers, nav, legal text, grid structures	Headings, body copy, images, button labels

Step 5: Design With Realistic Content Limits

Locking blocks stops structural damage. It doesn’t stop a client from typing a 40-word headline into a box designed for six words, or uploading a massive photo into a thumbnail slot. Content limits handle the damage that locking can’t.

Set realistic character guidance for headings and buttons. A hero headline designed for "Grow Your Business Faster" will break with "We Help Small and Medium-Sized Businesses Scale Revenue Through Strategic Digital Marketing." Document a rough word count next to each editable heading in your style guide, and where the layout genuinely can’t tolerate overflow, use CSS to truncate or wrap gracefully.

Set image aspect ratio expectations. Use the built-in image cropping and scale tools so a portrait photo dropped into a landscape slot still displays correctly instead of stretching or distorting.

Use spacing presets exclusively. Every gap, margin, and padding choice in the block editor can pull from the presets you defined in theme.json instead of a custom numeric field. When a client selects "Large" from a dropdown, the result is always consistent. When they’re allowed to type "47px," inconsistency creeps in immediately.

Cap gallery and repeater counts where layout depends on it. A three-column testimonial row breaks visually with a fourth entry. If the layout can’t gracefully handle a variable count, state it plainly in your documentation.

This is also where accessibility and content limits intersect. Oversized headings, low-contrast client-chosen colors, and images without alt text all originate here. Cross-reference an accessible website design checklist at this stage, since content limits and accessibility guardrails often solve the same underlying problem.

Step 6: Test With a Non-Technical User Before Handoff

This is the step missing from every generic tutorial, and it’s non-negotiable before any client handoff.

Before delivery, hand the finished template and patterns to someone who didn’t build the site and has no special WordPress knowledge. Ask them to make three or four realistic edits: change a heading, swap an image, add a new testimonial entry, update a phone number. Watch without helping, and take notes.

Watch for these failures:

• Does the person try to drag or delete something that should have been locked, and does the lock actually stop them?
• Does inserting new content break spacing or alignment?
• Do they get confused about which block is editable when nested blocks overlap visually?
• Does a synced pattern change unexpectedly somewhere they didn’t intend?
• Do they abandon the task, get stuck, or ask how to undo?

Every one is a design failure, not a user failure. If your non-technical tester breaks something, a real client will break it faster and with less patience. This test typically surfaces two or three fixable issues per project: a block that needed locking but wasn’t, or a pattern that should have been unsynced but wasn’t.

Before client handoff, confirm: Non-technical tester completed at least three realistic content edits unaided. No structural blocks were accidentally moved or deleted. Spacing remained visually consistent after edits. Tester could identify editable parts without being told. Any confusion points were fixed or documented.

Step 7: Write a Simple Client Editing Guide

A design system without documentation is a trap. The client will forget which patterns exist, forget what’s locked and why, and eventually ask you to explain the site from scratch. A short document prevents almost all of this.

A lightweight client editing guide, often one page, should include:

A list of available patterns with a one-line description of what each is for ("Testimonial Row: add up to 4 entries, don’t exceed this count").

What’s locked and why, in plain language, not technical jargon ("The header and footer are locked so the navigation doesn’t break. Everything inside them is still editable.").

Content limits, restated simply ("Keep headlines under 8 words for the homepage hero.").

Who to contact when stuck and what information to include in that request.

This doesn’t need to be elaborate. A single PDF or shared document with screenshots of the Site Editor, annotated with arrows pointing to editable versus locked regions, does the job. Treat this document as part of the deliverable, not an optional extra.

Five Mistakes That Break Client-Edited Layouts

These five mistakes account for most "the site looked fine until the client touched it" support requests:

1. Leaving structural blocks unlocked. Headers, footers, and navigation containers left fully editable invite accidental deletion within the first month.
2. Allowing custom spacing values instead of presets. One client-entered "23px" margin instead of preset "Medium" spacing, and suddenly every page has a slightly different rhythm.
3. Orphaned patterns. A pattern duplicated and edited so heavily on one page that it no longer resembles the original, defeating the purpose of using a pattern.
4. Missing or skipped documentation. Without a written guide, every question becomes a support ticket, and every small edit becomes a risk.
5. Skipping the non-technical test. Assuming the design is intuitive because it’s intuitive to you is the single most common failure point in this entire workflow.

Frequently Asked Questions

How do I start designing in the WordPress block editor?
Start by mapping content structure, not by opening the Site Editor. Identify what repeats (headers, testimonials, CTAs) versus what’s one-off, then move into theme.json configuration before building any patterns.

What is the difference between a block theme and a classic WordPress theme?
A block theme is built entirely from HTML template files made of blocks and configured through theme.json, editable visually in the Site Editor. A classic theme relies on PHP template files and typically requires code edits to change structure. Full Site Editing only applies to block themes.

What is theme.json used for in block themes?
Theme.json is the configuration file that defines a block theme’s available colors, typography, spacing values, and layout settings. It controls what options appear in the Global Styles interface and constrains what editors, including clients, are allowed to change.

What is a block pattern, and how is it different from a template part?
A block pattern is a reusable arrangement of blocks representing a piece of content, like a testimonial row or pricing table. A template part is a structural region, like a header or footer, that appears consistently across pages using a given template. Patterns are about content; template parts are about layout regions.

What is a synced pattern (reusable block), and when should I use one?
A synced pattern updates everywhere it’s used whenever one instance is edited. Use it for content that must stay identical across the entire site, such as a newsletter signup or legal disclaimer. Use an unsynced pattern instead when each instance needs independent content.

How do I lock a block so clients can’t delete or move it?
Select the block, open the options menu (the three-dot icon in the block toolbar), and choose "Lock." You can lock movement, removal, or both independently, which lets structural elements stay in place while their inner content remains editable.

Can I let a client edit text but not move a section?
Yes. Lock the outer structural block against moving and removing, while leaving the inner content blocks (headings, paragraphs, images) completely unlocked. This is the standard pattern for protecting layout while preserving editing freedom.

What is Full Site Editing (FSE) and how does it affect theme design?
Full Site Editing is the WordPress architecture that allows entire templates, not just post content, to be edited visually through blocks. It shifted theme design from PHP template editing toward a block-and-pattern-based workflow governed by theme.json and Global Styles.

How do spacing presets help maintain design consistency?
Spacing presets replace arbitrary pixel values with a fixed scale (small, medium, large) defined once in theme.json. When editors choose from presets instead of typing custom numbers, every gap and padding value across the site stays visually consistent automatically.

Should I limit how much text a client can add to a heading or button?
Yes. Document a rough word or character guideline for each editable heading and button, and where a layout genuinely can’t tolerate overflow, build in CSS handling like truncation or wrapping so an over-long entry degrades gracefully instead of breaking the design.

How do I test whether a client can safely edit a page before launch?
Hand the finished page to someone with no WordPress experience and ask them to make several realistic edits unaided. Watch for accidental structural changes, broken spacing, and confusion about what’s editable. Fix whatever breaks before delivery.

What should I document for a client after building their WordPress site?
A short guide listing available patterns and their purpose, what’s locked and why, any content limits, and who to contact for help. A one-page document with annotated screenshots is usually sufficient.

What are the most common mistakes that break client-edited WordPress layouts?
Unlocked structural blocks, custom spacing values instead of presets, orphaned or overly-edited patterns, missing documentation, and skipping a non-technical editing test before launch.

How many block patterns should a small business site have?
There’s no fixed number; it depends on how much repeating content the site actually has. A typical small business site might use somewhere between four and ten patterns (hero, services, testimonials, CTA, pricing, team) rather than a pattern for every unique section.

Can I restrict image sizes or aspect ratios in the block editor?
Yes, through fixed aspect ratio settings on image and cover blocks, combined with theme.json dimension controls. This keeps a client-uploaded photo displaying correctly even if its native dimensions don’t match the design.

What’s the difference between locking a block and simply restricting permissions?
Block locking is a per-block, per-page setting controlling movement and removal, applied by the designer during the build. User role permissions are account-level restrictions (like limiting a client to the Editor role) that control broader site access. Most client projects need both.

How do template parts (like headers and footers) work in a block theme?
Template parts are reusable structural regions, saved once and referenced across every template that uses them. Editing a header template part updates the header everywhere it appears, which is why template parts are typically locked against structural changes while their inner content stays editable.

Do I need coding skills to design in the WordPress block editor?
No coding is required for the core workflow described here. Configuring theme.json manually involves editing a JSON file, but the Global Styles interface lets you accomplish most of the same configuration visually, without touching code directly.

How is designing for the block editor different from using a page builder plugin?
The two approaches use different underlying systems, different data storage, and different long-term maintenance considerations. A full comparison deserves its own treatment.

What is a design system, and why does it matter for WordPress client projects?
A design system, in this context, is the combined set of theme.json settings, Global Styles, and patterns that define what a site can look like and how it can be edited. It matters because it’s the difference between a client casually breaking a page and a client confidently updating it within guardrails you built on purpose.

How often should I revisit a client’s theme.json settings after launch?
There’s no fixed schedule, but a light review after any major rebrand, new page type, or noticeable pattern-drift complaint is reasonable. Most stable client sites need infrequent revisits once the initial system is solid.

What tools help preview how a client will experience the editor?
The most reliable tool isn’t software at all: a real non-technical person testing the actual editor. Beyond that, previewing with a lower-privilege user role (Editor or Author rather than Administrator) shows you what the client will actually see and be able to do.

The Payoff

Designing this way takes longer up front than simply building a page that looks right on delivery day. It’s worth it. A theme that survives six months of real client editing, without a single frantic email, is worth far more than one that only looks good in the handoff call.

Sources

• Theme.json Reference, WordPress Block Editor Handbook

Related: WordPress block editor design