Every WordPress site has two products: the one visitors see and the one editors use to keep it running. Most agencies ship the first one to high standards and leave the second one to whatever the default theme settings happened to do. The cost shows up immediately — editors avoid the CMS, content goes stale, the site that looked great at launch starts decaying within months.
Every WordPress site has two products. The one visitors see on the front end: designed, prototyped, A/B tested, signed off by stakeholders. And the one editors use every day to keep it running: whatever the default admin happens to look like after you turn on Custom Fields and call it done. The first one gets all the attention. The second one is treated like a wiring closet: ugly, ignored, behind a door nobody opens. And then six months in, the marketing team stops updating the site because using the admin is a chore, and the beautiful front-end product starts to rot.
What “designing the admin” actually means.
It doesn’t mean theming the WordPress dashboard with brand colors. It means treating the editor’s workflow as a user experience problem with the same rigor you’d apply to the visitor’s experience. Specifically:
- The post editor only shows fields that matter for that post type. If you’re editing a Case Study, you should see the fields a case study needs, not every field that exists for every post type. Fields you don’t need on this screen are friction.
- Field labels are written for the person filling them out. “Hero subtitle” is fine. “Sub-text appears beneath the H1 on desktop and is hidden on mobile widths below 768px” is what you actually want the label to say. Half-tier of effort, full tier of less Slack questions.
- The structure on screen matches the structure on the page. If the live page reads “Hero → Pull-quote → Body → CTA,” the admin fields should be in that order with those labels. Editors should not have to mentally translate the admin to the rendered output.
- Required fields are required. If the front-end breaks visually when a field is empty, that field is required at the schema level — not enforced by a Slack reminder.
Why this gets skipped.
Three reasons it gets cut from scope, in roughly the order they’re cited in kickoff meetings:
- The client doesn’t see it during sales. Pitches are visual. Mockups, Figma walkthroughs, motion prototypes. Nobody pitches the admin. So when budgets get squeezed, the admin work is the first to get trimmed because nobody’s eyes are on it.
- The agency doesn’t dogfood it. The team that builds the admin rarely uses the admin in production. Developers see the post editor for 20 seconds during QA, then never again. The editor’s day-to-day pain isn’t visible to the people who could fix it.
- It’s incremental. Polishing the admin is dozens of small calls — this field needs a help text, this section needs a heading, this taxonomy needs reordering. None of them are heroic. All of them add up.
What good looks like.
A few patterns that consistently land for editorial teams:
- One screen per content type, with everything an editor needs and nothing they don’t. ACF’s flexible content fields handle this cleanly — one place to add the next section, hidden complexity behind it.
- Image fields with the live aspect ratio enforced on upload. If the hero image is rendered at 16:9, the upload field should crop to 16:9 in admin. Editors should not have to learn what dimensions the theme expects.
- Preview that works. Out-of-the-box WordPress preview is fragile — ACF flex layouts sometimes don’t render in preview mode without configuration. Either configure it to work, or build a custom preview surface. Don’t ship a button that says “Preview” and produces something different than the published page.
- Errors that are written for humans. When a field’s value is invalid, the message should say what’s wrong and what the editor should do instead. “Required field” is the floor. “Hero subtitle is required because the layout breaks if the title sits alone” is what you actually want.
The compound effect.
This is one of those things that doesn’t matter for the first month and matters enormously for years two and three. A site whose admin was designed gets updated regularly because using it is pleasant. A site whose admin was an afterthought decays because every update requires the editor to remember a half-dozen workarounds, and the marketing team learns to route around it. The CMS that costs the same to build either way will earn you very different returns depending on which way you went. That’s the whole calculus.
This is part of why we treat editor experience as part of platform architecture, not a finishing pass at the end of a build.