If changing a heading feels risky, uploading an image takes multiple attempts, or adding a new page involves messaging the developer for help, something's wrong.
The people managing a website use it too. They just happen to use a different side of it.
The editing experience matters
When we talk about user experience, we usually mean the person browsing the website. Can they find what they're looking for? Is the navigation clear? Does the contact form work?
Those questions matter, obviously. But the person logging into the CMS has questions of their own.
Which field changes this bit of text? Why are there three fields called “Copy”? Will this image get cropped? What happens if I leave this empty? Can I preview the page before everyone else sees it?
If the answer to every question is “ask the developer”, the CMS isn’t doing its job.
A good editing experience should give people the confidence to make ordinary updates themselves. It shouldn’t feel like one wrong click could bring down the whole site.
Flexibility needs some boundaries
It’s tempting to give editors complete control. Add any block, move everything around, change every colour and build whatever layout you fancy.
That sounds great until someone is faced with fifty options just to publish a news article.
Too much freedom can make a website harder to manage. It can also lead to pages that look completely different from each other, even though they’re part of the same site.
I’d rather give editors useful choices. Let them choose the type of content they need, while the site handles the layout and styling. They should be able to create a page that works without having to think like a designer or developer.
We can give them colour options, but maybe just the background and we change the text colour to make sure it's accessible and still on brand.
Good field labels help too. “Introduction” is clearer than “Content Block 1”. A short instruction beside an image field can save someone from uploading the same file five times and wondering why it looks wrong.
They’re small details, but they make a difference when you’re the person using the CMS every day.
Think about what happens after launch
During a build, it’s easy to focus on how the finished pages look. The homepage gets reviewed, the mobile menu gets tested, and everyone checks that the buttons go to the right place.
But a website isn’t finished being used when it launches.
Someone will need to add a team member, replace an old PDF, update prices or publish an article. Content won’t always fit perfectly into the examples used during development, either. A heading might be longer than expected. An article might need a video instead of an image.
That’s when you find out whether the CMS was built around the people who actually have to use it.
Whenever possible, I think it’s worth letting those people try making real updates before launch. Ask them to add a page or change some existing content. If they get stuck, that’s useful feedback. It might mean a field needs a clearer name, an instruction is missing, or the content structure needs another look.
Easy to manage is part of easy to use
I love building a frontend that feels effortless for visitors. But that care should carry through to the CMS.
Editors shouldn’t need to understand the code behind a page to keep it up to date. They should know what they can change, see what they’re about to publish, and feel confident that the result will still look right.
I'm a firm believer that as little as possible should be hard coded into templates. That's not saying you should never do it, however weighing up options is always something I do before handing over to clients.
Because if a website is a nightmare to update, sooner or later people stop updating it. And even the nicest website isn’t much use if its information is out of date.
