If Your Website Requires a 20-Page Manual, Your CMS Has a UX Problem

Yesterday, I was helping a client make what should have been a very simple update to their website. They were confused, not because the update was complicated, and not because they weren’t capable. The more useful question was one we should have asked much earlier in the build:

Is updating this page or element going to be intuitive for the client?

In this case, most of the site was edited through Pages in WordPress. But this particular content lived somewhere else, under a different post type, with a different editing path. To a developer, that distinction is trivial. To a client, it can feel like the website suddenly changed the rules halfway through the game.

If 90% of a site is edited one way and 10% is edited another, the burden should be on the interface to make that difference obvious. It should not depend on the client remembering a detail from a training session six months ago or digging through a multi-page help document to rediscover where we hid the thing.

The Norman Door of the CMS

There’s a classic UX example called the Norman Door: a door designed so poorly that you have to stop and figure out whether to push or pull it. If a door needs a sign explaining how to use it, the problem probably isn’t the person opening the door. The same principle applies to a content management system.

If a client has to remember:

• “Most things are edited here, except this one.”
• “You can edit this from the front end, but not that.”
• “This content is actually controlled somewhere else.”
• “Don’t click there. Go three menus down and look for this other thing.”

…we’ve built a Norman Door. Writing a longer help document about the Norman Door does not make it a better door. It just means we documented the friction instead of removing it.

They Aren’t Trying to Become Web Developers

Our clients are subject matter experts. A chiropractor knows chiropractic care. The people organizing a balloon festival know how to put thousands of people, pilots, volunteers, vendors, and balloons in the right place at the right time. They should not also need a working knowledge of WordPress content architecture just to change a date, swap a photo, or update a paragraph.

That’s our job. A good website isn’t only attractive and easy for visitors to use. It should also be easy for the people who have to maintain it after we leave. Backend UX is still UX, even if nobody is putting it in the portfolio screenshots.

Training Is Not a Substitute for UX

Sometimes the answer is better labels. Sometimes it’s removing unnecessary menu items. Sometimes it’s putting editing controls where people naturally expect to find them. Sometimes it means adding a clear path from the content they are looking at to the place where that content is managed.

And sometimes it means accepting that the technically elegant way to structure something is not automatically the most intuitive way for the person who actually has to use it. “That’s just how WordPress works” may explain the problem, but it doesn’t solve it.

sometimes it means accepting that the technically elegant way to structure something is not automatically the most intuitive way for the person who actually has to use it

The goal shouldn’t be “We trained them how to use it.” The better goal is “There wasn’t much to explain.” Training can be useful, of course. But if routine edits require a recurring tutorial, institutional memory, or a treasure map through the admin, that’s not really onboarding. That’s a workaround.

If a client repeatedly gets lost trying to perform a routine task, that isn’t evidence that the client needs more training. It’s evidence that we still have some UX work to do.

The front end isn’t the only part of the website with users.

And while we’re talking about Norman Doors: even bananas have a UX quirk. The stem looks like the obvious handle, but the other end often opens more easily. The lesson is simple: the easy path should also be the obvious one.