Editorial workflows require more clarity

Consider this common reality for a site owner or manager: You’ve bought, built or inherited a website or application. And well, it’s a lot. And it’s not perfect. So you’ve had to customize it all to fit your needs.

Well, perhaps your frontend code in your doesn’t work 100% perfectly, and some boxes in your editor doesn’t work the way it was expected. Perhaps a common setting you’d like to see isn’t there. So you chisel a solution together—fire up the machines.

But by the end of all your good work, your platform’s tools work fine. It’s fine. Just fine. Juuuust fine. (It’s not fine at all, it seems to be missing something.) What happened?

These customizations have past the limits of maybe what you understood. Now you’ve got a plugin to mitigate another plugin. And why not two more to make the performance of your site better? Just another page builder won’t hurt!

These inefficiencies have become hard, and maintaining this application is like driving some crazy car that requires three feet. Possible, and maybe doing so matches some of your goals, but the total cost of ownership and operation (plus risks to sanity) must be insane.

Well, this time you might’ve gone too far, and you can’t see the scale of the situation anymore.


In MOST cases, prioritizing simplicity will be a key to your success.

For example, I will, by default, struggle to understand the choices that led one of the site networks I worked with to implement a data lake as part of their pipleline to publish what was effectively blogs.

Even crazier, a major European publisher required 22 tabs to publish with 46 unique steps to get breaking news articles out the door. Isn’t the point to make it fast and easy for the authors to get the word out?*

* That said, their visibility into the story process was incredible… And the section editors could make it easier to share to their bosses about what was published… And it was really cool to see the “forgotten” stories that never ran…

Okay I get it. They wanted more.

Perhaps there’s a better way?

It’s important to strike a balance between customization and simplicity, ensuring that your CMS serves your needs without creating unnecessary complexity. Customizing your CMS can be a double-edged sword:

  • On one hand, tailoring your system to fit your unique needs can streamline workflows and improve efficiency. For example, creating custom post types and taxonomies can help organize content and enhance user experience, as demonstrated on this website.
  • However, customization can also come with its own set of challenges and costs. Some publishers find themselves buried under layers of complexity, with workflows that require an excessive number of steps and tabs to publish content. While this level of customization may seem necessary, it’s essential to weigh the benefits against the potential drawbacks.

Avoid grabbing a “shiny” new thing, or over-engineering for the future. Dave Thomas, one the original Agile Manifesto drafters, did a talk almost decade ago that really stuck with me, and I think his key guidance will resonate with you, too.

First, he declares that “Agile is Dead,” primarily because of a complicated industry who mostly had good intentions, and the jargon we use gets in the way.

And to do better, Thomas argues our language should be simplified language dramatically. Consider this the next time you have to make a decision:

How do you know what to do? You don’t! You…

  1. Take a small step toward your goal
  2. Adjust your understanding based on what you learned
  3. Repeat

And of course, you actually have to make a choice, too—indecision is the choice of being stuck in the hole. Taking steps is the answer. Instead of wallowing, evaluate the situation and proceed with caution toward the better.

Thomas has an answer, too, on how to choose what options might be best:

When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.


By considering future change, you facilitate better collaboration. Fine-tuning your decisions isn’t about shipping features, it’s about talk to your actual users—to understand the Venn diagram, not just who’s the loudest voice in the room.

Scenario 1: The users who wish they could

Using Dave’s advice, let’s consider a scenario that could be better ironed out with such an approach.

  • You have tool (be it a website or application). It’s wide reaching, and has many users and many stakeholders. Perhaps a multifaceted marketing-sales’ team CRM with lots of data fields, an appointment manager for a doggie daycare, or a dashboard built for a team.
  • Within these, you have some power users, some executives, some outside staff and a variety of contractors. Some people are new to the team, or might be joining soon.
  • Most of the people appreciate the complexity it provides, but also admit they’re overwhelmed or annoyed at the complexity and density.
  • Some also think that sections “don’t apply to me,” and move on when there was a conscious decision. Maybe it’s many due to annoying interfaces (Some might have accordions, tabbed lists, widgets, and some other doodads), maybe it’s just because of some bug.
  • When any of these users admit these frustrations to a colleague, superior, or to the help desk staff, the typical responses are variations “well, there’s a tutorial video/handbook/training you should have got when you started,” which might be true.
  • But how these the result of some rigid documentation that isn’t being used reflects a broken company culture: It team likely isn’t actively documenting its status and tools (so, it’s outdated), and as such the tool is also not being prioritized.

Just as “tests” can reflect the test giver as much as the test taker, poor user adoption can reflect the build and structure of the application. Are there ways a user could selectively turn “off” features? Perhaps rename annoying labels, or rearrange those boxes? Maybe that spiffy dashboard the CEO needed isn’t required for every person.

Since it’s obvious there’s complexity in any of these organizations, it reveals a critical axiom: Every choice comes with a “tax” you’ll need to pay for it over the long term. There is an advantage to so-called “hardcoding” and rigid design decisions, but there are great tradeoffs.

Try to encourage the outcome of efficient and effective workflows that maximizes creativity and productivity. And if it both enables more on your team to do better (and perhaps celebrate their uniqueness in role, personality, or situation.) Don’t go crazy, but definitely do more. Maybe there are benefits to loosening up, to harmonize content creation, editing, and distribution tools in ways that mirror your team.

Scenario 2: The users who can

Considering the previous example, let’s think of a way to apply Thomas’ ideas.

And given that many software applications are built with a Model-View-Controller paradigm, oftentimes a different “view” might be the thing you really want. If future flexibility was a decision made early in the process, think about the “view” options that allow for significantly better options for future change without people forcing others to change:

  • The Sales Development Reps don’t need the dashboards, and the supervisors don’t make sales calls. Let’s ✂️ Remove this View it on down.
  • The CEO doesn’t need to edit a post often, but wants to know how the company is doing. We built a great interface to simplify navigation like it’s the next concept car, so for her we 📌 Pin this View to the top.
  • Perhaps there’s a legally-required accessibility accommodation that your developers “forgot” to account for. As an idea, MVC provides for an alternative way to hook in, and good software might even provide options for the rest of us. A user might select 🔲 Prefer High Contrast Colors or 🎨 Minimize Color Palette due to color blindness, and some might prefer ⚫️ Dark Mode. Heck, maybe you offer (on Valentine’s Day?) a 🩷 Pink Mode!

The risk is, of course, not everything should be customized, and you have to strike a balance:

  • Too focused: Over-personalized experiences might mean that some inherently isolate their interfaces into echo-chambered shells of their colleagues, just as some people experience the same effect of hyper-personalized social media. Is there a way to balance it so there’s some level of customizations in some places?
  • Or lack thereof: Inversely others might have (for some unknown reason) all 26 features turned on like an unhinged chaos without any order. But… why would you set a limit in the first place? Maybe the aforementioned help desk needs all 26 features? You should probably talk to them before you set arbitrary limits or remove them.

In any case, there’s ways you can this interactivity fun, inclusive and cheaper to live with—Just make sure it’s done by design, at the start of your build.

If you want to reduce your total cost of ownership, wrestle with the real complexities, which are probably the people powering your organization, not the software they use.