Non-technical editors on client sites stall at a blank block editor canvas more often than at any technical obstacle we've ever tried to solve for them. Give a marketing coordinator a fully capable block editor and a content brief, and the limiting factor usually isn't whether they can figure out how to insert a columns block, it's the much simpler problem of staring at an empty page and not knowing where to start. A plugin we built this year addresses that directly: it suggests a full block-based layout from a short content brief, giving editors a real starting point rather than an empty page and a blinking cursor.
Why The Blank Canvas Was The Actual Problem
We'd assumed for years that block editor friction was mostly about editors not understanding what individual blocks did, and we invested accordingly in tooltips, onboarding tours, and documentation. That investment helped at the margins but never moved the needle on the support requests that actually mattered. When we finally sat down and watched real client editors work, session after session, the pattern was unmistakable: the hesitation happened before a single block got placed, not while configuring one. People who were perfectly capable of dragging a block around and typing into it once something existed on the page would sit for several minutes, sometimes longer, just deciding how to begin.
- Editors rarely struggled with individual block configuration once something already existed on the page to react to and adjust.
- The dominant friction point was the decision of how to start, not any specific block's settings or behavior.
- Tooltips and onboarding tours addressed a problem editors weren't actually having, which is why they never meaningfully reduced support volume.
- Watching real editing sessions, rather than relying on support ticket text alone, was what actually surfaced the real bottleneck.
How The Suggestion Engine Works
An editor writes a short brief describing what the page needs to communicate and roughly who it's for, and the plugin proposes a complete block-based layout: heading structure, appropriate content sections, image placeholders sized and positioned sensibly, and a call-to-action block where the brief implies one belongs. The suggestion draws on patterns from well-performing pages across our client base, filtered to the specific type of page being built, a landing page gets a different structural bias than a blog post or a services page. It isn't generating final copy, mostly placeholder text and structural scaffolding, because we deliberately kept the AI's role scoped to layout and structure rather than letting it write the actual voice of a client's brand.
- Editors submit a short content brief describing the page's purpose and audience rather than any technical layout details.
- The engine proposes heading structure, content sections, image placement, and call-to-action positioning based on patterns from comparable pages.
- Structural bias adapts to page type, since a landing page, a blog post, and a services page all warrant different default shapes.
- The suggestion stays scoped to layout and structure, deliberately avoiding final brand voice or marketing copy, which stays a human's job.
Editors Stay Fully In Control
Every suggested block remains fully editable, reorderable, or deletable exactly as if the editor had placed it themselves, and nothing about the plugin's output is treated as final or protected in any special way. This mattered enormously for adoption. An early internal prototype that made suggested layouts slightly harder to modify than manually placed ones, out of an overcautious instinct to protect the AI's suggestion from accidental damage, actively annoyed testers and got scrapped before it ever reached a client site. The lesson was straightforward in hindsight: a suggestion that feels like a cage rather than a starting point defeats the entire purpose, no matter how good the suggestion itself is.
What Changed For Support
The blank-page hesitation that used to generate a steady, low-grade trickle of support requests, "how do I start a new page," "what blocks should I use for this," "can someone just build the structure for me," has dropped substantially since rolling this out across client sites. It hasn't eliminated the category entirely; some editors still prefer to ask a human for reassurance even with a suggested layout sitting in front of them, and we don't think that instinct is unreasonable or worth engineering away. But the volume of that specific request type has fallen enough that our support team now spends noticeably more time on genuinely novel questions rather than the same handful of recurring blank-page questions we used to field on a near-daily basis.
What We'd Do Differently
If we were starting this project over, we'd invest earlier in letting the suggestion engine explain its reasoning briefly alongside the layout, something like a one-line note on why it chose a particular section order for a given brief. We added that only after noticing that editors who understood the "why" behind a suggestion were more willing to confidently deviate from it when their instinct disagreed, rather than either blindly accepting the suggestion or discarding the whole thing out of uncertainty. That small addition came later than it should have, and it's now one of the features client editors mention most often when asked what they find useful about the tool.
Rolling It Out Across A Varied Client Base
Our clients range from small local businesses to larger organizations with dedicated marketing staff, and the plugin needed to be useful to both ends of that range without feeling condescending to the more experienced editors or overwhelming to the less experienced ones. We handled this by making the suggestion prominent but entirely optional from the very first screen: a new page starts with a clearly visible "suggest a layout" option alongside the standard blank page, rather than forcing every new page through the suggestion flow whether an editor wants it or not.
Experienced editors at larger client organizations, we found, use the suggestion feature far less often than we expected going in, mostly reaching for it on unfamiliar page types outside their usual routine rather than on the pages they build every week. Smaller clients with less frequent, less specialized editing needs use it far more consistently, which matches the original motivation for building it in the first place: the feature helps most exactly where editing confidence is lowest and least frequently exercised, which is also where our support burden was concentrated before this shipped.
Guardrails Around What The Engine Won't Suggest
We deliberately built in a few hard constraints on what the suggestion engine will propose, regardless of what a brief seems to ask for. It won't suggest layout patterns associated with dark patterns, like a deliberately hard-to-find unsubscribe link or an oversized, misleading call-to-action styled to look like a neutral page element. That constraint came from an internal design review rather than any incident, but we consider it a genuinely important guardrail given how easy it would otherwise be for a suggestion engine trained on "well-performing" pages to learn that manipulative patterns technically perform well by some narrow metric, and to propose them without any of the ethical judgment a human designer would apply before doing the same.
Accessibility Considerations We Had To Build In Explicitly
A layout suggestion engine optimizing purely for visual pattern matching against well-performing pages will, left unchecked, happily propose heading structures that skip levels, color combinations with inadequate contrast borrowed from a source page that happened to look good despite its accessibility flaws, or image blocks with no meaningful alt-text scaffolding at all. We treat these as hard constraints checked independently of the layout-suggestion logic itself, not as something we hope the suggestion model learns to avoid on its own from its training patterns.
Every suggested layout runs through the same automated accessibility checks we apply to any published page before the suggestion is ever shown to an editor, and a layout that fails those checks gets adjusted automatically, correct heading hierarchy enforced, contrast ratios validated, alt-text fields pre-populated with a placeholder prompt rather than left empty, before an editor ever sees it. This matters more for a suggestion tool than it would for a fixed template, precisely because a suggestion is generated fresh for each brief and can't be manually accessibility-audited once ahead of time the way a static template library can.
Measuring Success Beyond Support Ticket Volume
Support ticket volume was our original success metric, and it remains the one client stakeholders care most about, but we've since added a second measure that's turned out to be equally informative: how often an editor keeps a suggested layout's overall structure while substantially rewriting its content, versus discarding the structure entirely and starting from a blank page anyway. A high discard rate for a particular page type is a clear signal that the suggestion engine's structural instincts for that category need work, independent of whatever the support ticket numbers say, and it's caught at least one page type, event landing pages, where the default suggestions were reliably missing the mark well before enough support tickets accumulated to make the same problem obvious through that channel alone.