WordPress Web Design That Survives Being Edited

Why does our WordPress site look worse than the design?

Usually because pages have been built since launch by people working without a system. The original templates still look right; everything added afterwards was improvised.

The mechanism is ordinary. An editor needs a section that does not exist as a pattern, so they build one from generic blocks. The spacing is close but not from the scale. The heading is one size off. Done a dozen times over a year, the site develops a second, accidental design language.

The fix is not stricter rules for editors. It is giving them patterns for the things they actually need to publish, so the on-brand option is also the easy one.

Should we use a page builder like Elementor or Divi?

For a site you will edit yourself with no developer available, a builder is a defensible trade. For anything else, the costs outweigh the convenience and they do not go away.

Builders load their own CSS and JavaScript on every page whether that page uses their components or not, which is a permanent performance tax. They also store content in their own format, so moving away later is a rebuild rather than a redesign.

The native block editor now covers most of what builders were originally needed for, and patterns give editors the same assemble-from-pieces experience without the weight or the lock-in. That is what we design toward.

How is WordPress design different from designing any website?

The design has to survive other people. A static site is built once and changes when a designer changes it. A WordPress site changes whenever anyone in the business publishes something.

That shifts what you are actually designing. Alongside the pages, you are designing the set of moves an editor can make — which sections exist, what they allow, where flexibility is safe and where it will cause damage.

It also means designing for content you have not seen. A headline twice as long as the mockup, a portrait image where a landscape was assumed, a section with two items instead of six. Designs that only work at the intended content length break the first time reality differs.

Do we need a custom design or will a theme do?

A good premium theme is genuinely fine when budget is the binding constraint and the site is straightforward. It is not a lesser answer for a small brochure site, and we will say so.

Custom becomes worth it when the brand needs to look like itself rather than like a template, when the content structure is unusual, or when performance matters commercially — themes built to sell to thousands of businesses carry features you will never use and cannot fully remove.

The middle option is often best: a lightweight base with a custom design system and pattern library on top. That gets the distinctiveness without paying for a full bespoke build, and it is what most projects in this range should probably choose.

What are block patterns and why do they matter?

A pattern is a prebuilt arrangement of blocks an editor inserts as a unit — a hero, a three-column feature set, a testimonial with an image. They matter because they are the difference between an editor assembling a page and an editor designing one.

Without patterns, every new page is built from scratch by someone making layout decisions under time pressure. The results are inconsistent, and they get more inconsistent as more people contribute.

With a good pattern library, building a page becomes choosing from a small set of known-good arrangements. The design holds because the decisions were made once, by a designer, rather than repeatedly by whoever is publishing.

The library should cover the layouts your site actually uses, which is usually a smaller set than anyone expects. Six to ten patterns covers most business sites, and a library much larger than that stops being scannable and starts being ignored.

How much flexibility should editors get?

Enough to do the things they legitimately need, and nothing beyond that. The specifics matter, because both extremes cause real problems.

Too much flexibility and the design erodes. Colors get picked outside the palette, spacing gets set by eye, and within a year the site has drifted somewhere nobody chose. This is what an unconstrained block editor produces by default.

Too little and people work around the system entirely. They paste formatted content from a document, or stop using the site and put things in a PDF, or ask a developer for every change — which is exactly the dependency the build was supposed to remove.

We resolve it by looking at what actually varies. Section background alternating between two defined options is a real need. Arbitrary color selection is not. The first becomes a toggle, the second is simply not offered, and nobody misses it.

Why do WordPress sites drift from the design?

Because the design described a moment and the site continued after it. Every page added since is a chance to diverge, and enough small divergences add up to a different site.

The specific mechanisms are consistent. Images uploaded at the wrong aspect ratio and cropped by the browser. Headings chosen for size rather than for structure. Spacing adjusted by eye on one page and not another. Blocks used for something they were not designed for because nothing else was close.

None of these are anyone's fault. They are what happens when a system leaves decisions open and busy people make them quickly. The design file is not present at that moment; the editing interface is.

Which is why the interface is where the design has to be enforced. Documented image dimensions, a heading control that reflects hierarchy rather than size, spacing as fixed steps, and patterns that cover the real cases — those hold up over a year in a way that a style guide never does.

What does handover to a WordPress build require?

A design expressed as a system rather than as pages, mapped to what the block editor can actually do.

That means every design token — color, type size, weight, spacing step, radius — named and listed, so the theme can define them once as theme settings rather than have them measured off a mockup per component.

It means each pattern documented with what varies and what does not. Which fields does an editor fill? Which arrangement is fixed? What happens with one item, three, or seven? A pattern designed only at three items will be used with seven eventually.

And it means designing within the editor's grain rather than against it. A layout that is beautiful and cannot be expressed in blocks will either be rebuilt as something else at build time or implemented as a rigid block nobody can edit — and both outcomes waste the design work. Where the build side is also ours, WordPress development closes that gap directly.

What should be documented for the editors?

The specific things about your site, in the place they will look, written for people who are not designers.

Generic WordPress guidance is freely available and not what your team needs. What they need is which patterns exist and what each is for, what image dimensions to use, which heading level to pick, and what to do when nothing quite fits.

Image dimensions in particular save more trouble than anything else on the list. Most layout problems on an established WordPress site come from images uploaded at the wrong ratio and cropped unpredictably, and the fix is a documented size next to the upload field.

The last item — what to do when nothing fits — is the one always omitted and the one that determines whether the design holds. Without an answer, someone improvises, and the improvisation becomes precedent.

And the documentation should live inside the site rather than in a file somewhere. A help page in the admin, or short notes on the patterns themselves, gets read; a document in shared storage does not.