Developing Websites So Content Editors Leave You Alone

Table of Contents

    Subscribe for Email Updates

    You’ve been here before. You build an amazing, beautiful website that matches the designer’s specs perfectly. And you even had time to build in some new innovations that will save you time and effort on future projects. 

    Everybody is happy and corks pop out of champagne bottles with fanfare and gusto. It all goes on until you have to train those pesky content editors whose demands don’t mesh well with the efficient and intelligent ways you built the site.

    They just don’t get it. No matter how many times you show them.

    Internal vs External

    It’s one thing if those content editors are internal staff within your agency. You have a little more flexibility to tick them off because they are immersed in the same outcome you desire - an effective, speedy website.

    But co-workers will harbor resentment which can inevitably strain your working relationship with them. Nobody wants to deal with toxic feelings from co-workers.

    On the other side, external editors (i.e. clients) will not only harbor resentment but have direct lines of communication with whomever is writing the checks. If they get mad enough, they might just recommend finding a new agency partner.

    Two Dimensional UX

    What we need to do is establish a two dimensional UX plan. One dimension is for the website visitors we hope give us all their money. The other is the for content editors who put out the amazing content that makes those visitors give us all their money.

    Dimension One

    It is no surprise that the first dimension, the one for public website visitors, should come first. After all, this is the primary mechanism for capturing and growing business. Strategy, design, and messaging for this should be at the forefront of any design plan. I’m pretty sure nobody will argue this point.

    Dimension Two

    The UX plan for content editors typically takes a back seat, but as we’ve all seen, back seat riders can yell and scream and drive us completely bonkers. We have to look at the front-end requirements and develop a data plan that fits the design. From this, we develop a strategy around how editors will create and update that data. 

    Let’s discuss some key considerations to keep in mind when building a site for editors.


    With our data plan, we need to minimize the number of steps an editor must take to make changes. This can be a difficult balance, especially if you have a lot of relational data that can create many different locations where data is edited.

    Some professional content management systems allow editors to create new related data without navigating away from the data they’re currently editing (fig. 1). This is quite helpful in keeping the editor focused and not lost in the weeds.

    Figure 1 - Ability to create new content without leaving your current editing view

    If you’re able, keep as much content in one view as possible. Content editors mostly associate the content on pages with a single item, even though that may not be the case. If you can keep most of the content in one spot you’ll make it easier on them.

    Don’t Over Engineer

    As developers, we love to make code and content reusable. Anything else goes against what we stand for. However, that kind of thinking can get us into trouble because we want to iterate again and again until things are just perfect. And they may be perfect from a structural standpoint but they can easily end up a convoluted mess for the editor.

    Making some sacrifices in structure and even speed enhancements (if minimal) are okay if they improve a content editors’ ability to get in and get work done without your help.

    Provide a Website Blueprint

    So many websites are built without a real plan that it becomes a guessing game for all parties involved. You don’t build a house, even a modular home, without some sort of blueprint. So why would you build a website and its many interconnected parts without one?

    When we build internal sites or new Marketpath CMS templates, we assemble what we call a detailed design document. This has all sorts of information about the site, like personas, branding, calls-to-action, sitemap, page templates, and page and section details. What’s most important for this post is the page and section details. This looks like figure 2 below. 

    Figure 2 - Website detailed design document, section details

    Your client has to receive and sign off on this document before any development begins. This avoids unnecessary development delays and scope creep.

    The best part about this document is that it can be handed to you and you can hit the ground running. If the planning was done right there will be very few questions and few needs for revision.


    Plugins can be wonderful tools that add much needed capabilities to your site. Some plugins, however, have an entirely different user experience. Your best bet is to find plugins that accomplish your goals but don’t deviate much from your CMS platform’s user experience.

    Talk with your Editors

    Whether the editors for the site you’re building are pros or novices, you should chat with them and ask them about pain points they’ve had with other sites they work in. Their pain points will help guide you into making different decisions that help them be better, more efficient editors.

    And ultimately, when you can appease your content editors, you’ll keep them off your back so you can do what you do best.

    Time for a Consistent, User-Friendly Experience

    Marketpath CMS has a consistent user experience for content editors - finding content, creating new content, and making updates are a breeze.

    Create a Site for Free

    About the Author

    Matt Zentz

    Matt Zentz launched Marketpath from a small Broad Ripple bungalow in February 2001 with a focus on custom web application development. He built the first, basic version of a hosted CMS called Webtools and shortly afterward expanded his team and created the first version of Marketpath CMS.

    Matt has worked for a national consulting firm, taught computer programming to high school juniors and seniors , and led the information technology arm of the auxiliary business units at Indiana University.

    Matt graduated from Indiana University in 1999 with a B.S. in Computer Science and has built custom web applications since 1995. Matt is husband to an amazing & supportive wife, has three beautiful children, supreme master to Archimedes (Archie) the dog, and mostly tolerant victim of 2 flying rats (cockateils).

    He coaches various kid sports, enjoys furniture and home renovation projects, and plays guitar and piano. Matt is also active with his church as a parishioner, technical advisor and board member on the festival committee.

    Subscribe for Email Updates