Designing a CMS that Explains Itself

The Hidden Cost of a Confusing CMS

It's a familiar scenario: logging into a legacy WordPress build only to be overwhelmed by clutter, with no clear sense of where the content you're looking for actually lives. As designers and developers, we can usually orient ourselves eventually. For a client sitting down to manage their own site for the first time? That moment of confusion can set the tone for their entire relationship with the CMS.

The problem isn't that clients aren't technical enough. It's that most CMS backends aren't designed with the end user in mind. Content gets organized around the platform's logic rather than the site's, so the person who knows their content best (the client) still has to learn an entirely foreign system just to change a headline.

That friction shows up everywhere: training sessions that run long, reference notes that go unread, and a steady drip of "how do I update the...?" emails long after launch. It's a bad experience for clients and an ongoing time sink for agencies.

It doesn't have to work that way.

Finding the Sweet Spot

Not all CMS builds are created equal, and we've worked across a pretty wide spectrum. On one end, platforms like Squarespace or Wix get a site up fast with minimal overhead, which is great for simple projects where the client just needs something that works. On the other end, headless setups like Contentful offer serious front-end flexibility and work well for complex, content-heavy products where content needs to flow across multiple surfaces.

But here's what we've found after building on both ends of that spectrum: the clients who feel most confident and comfortable managing their own sites aren't usually the ones on the simplest platforms or the most powerful ones. They're the ones whose CMS was built specifically for them.

Out-of-the-box platforms make a lot of decisions for you, including how the backend is organized, and those decisions are made for the broadest possible audience rather than your specific client managing their specific site. Headless and decoupled setups can produce the opposite problem: a backend that's technically robust but not very intuitive for someone who just wants to update their homepage hero or add a blog post.

The sweet spot is a custom CMS build where the editing experience gets the same design attention as everything else. While every client is different, and we support a range of content management systems—from Squarespace to Wix, Webflow to WordPress, Contentful and more—we most often recommend Craft CMS. (Read: Why You'll Love Craft CMS.) Its unopinionated architecture means we're not fighting the platform to organize content the way it actually makes sense for the client. We're just building it that way from the start.

The One Concept Clients Need: Everything Is an Entry

Before diving into any CMS we build, there's really only one concept a client needs to understand: everything is an entry.

An entry is just a chunk of content that lives in one place and can be managed independently. A page on your site is an entry. A blog post is an entry. That "About Us" blurb that appears in the footer across every page of the site? Also an entry, just one that gets pulled in wherever it's needed rather than copied and maintained in multiple places.

That's it. Once that clicks, the rest tends to follow naturally.

Where Content Lives: Landing Pages, Singles, and Channels

With the entry concept in place, we organize content into a few buckets that mirror how the site itself is structured.

Landing Pages are the straightforward ones. Each page on the site corresponds to its own entry in the CMS. The About page is an entry. The Contact page is an entry. Clients find these immediately because they already know their own site.

Singles are one-off entries that aren't tied to one specific page. Think of the site header, the footer, or a sitewide promotional banner. Rather than manage that content on every page it appears, it lives in a single dedicated entry that gets pulled in wherever it's needed. Update it once, and it updates everywhere.

Channels power any section of the site that lists repeating content: blog posts, team members, case studies, events, categories. Each item in the channel is its own entry, and the site pulls them in dynamically. Clients quickly grasp this one too, because the pattern maps directly to how they think about that content already.

Training That Runs Itself

By the time a client sits down for a CMS walkthrough, they've already been living in the content for weeks. During the build, we work from shared content documents: the same pages, the same sections, the same copy they've been writing and revising throughout the project. When the CMS is finished and they log in for the first time, the structure they see isn't new to them. It's just a better interface for content they already know by heart.

That familiarity does most of the heavy lifting. Instead of orienting a client to an unfamiliar system and then helping them find their content inside it, we're just showing them where their content landed. The About page they've been editing in a Google Doc is the About page entry in the CMS. The team members they've been adding to a spreadsheet are the team member entries in the Team channel. The header copy they signed off on last week is sitting right there in the Header single.

The result is a training session that's really more of a quick tour. We cover the basics, answer a few questions, and they're off. The CMS feels intuitive not because it's simple, but because it was shaped around content they were already familiar with long before they ever logged in.

A CMS shouldn't need a manual. If it's built right, the site it powers is the manual.