Dog looking at empty containers
Illustration by

Choosing a CMS Your Organization Will Love

The internet doesn’t exactly lack for advice on how to pick a CMS platform. Go for the one with the most impressive feature set, advises one expert. Consider the costs of ownership, charges back another. Make sure it produces SEO-optimized pages, warns every SEO consultant everywhere. Unfortunately, picking the right CMS by consulting generic criteria is as effective as studying census data to improve your writing skills.

Article Continues Below

Experts often readily admit the importance of considering organizational needs in the CMS selection process, but they’re rarely willing to talk about those needs specifically. Understanding the varied departmental interests, psychological trade-offs, and political realities of your organization, however, is key—your CMS selection criteria should emphasize factors that will directly impact the success of the people who will use it. In other words, stop worrying about having a CMS and start worrying about having a usable CMS.

The curse of enterprise software#section1

A 2012 executive survey revealed that CMS projects are seven times more likely to fail because of internal politics and lack of cultural fit than from a lack of features. Anecdotal evidence further suggests that even projects that seem successful initially can quickly go off the rails if the CMS can’t accommodate how the organization works.

As Jason Fried and Karen McGrane have famously pointed out, these problems stem from the fact that the people who buy enterprise software aren’t the people who use it. Changing the sales process isn’t enough to truly overcome this problem, however; one also has to understand who will be using the CMS and what their key needs are.

Those users typically fall into three categories: developers customizing and running the software, editors producing actual content, and managers using online content to achieve specific business goals. To choose a CMS that can serve the organization, you need to understand how the CMS impacts their daily work and what challenges they have to contend with.

Tools maketh the developer#section2

All developers know that no two CMSes are created equal. On one end of the spectrum, you will find publishing platforms that carefully separate application data, presentation, and business logic, making them easy to extend and customize. On the other (more crowded) end, you will bump into CMSes whose innards consist of spaghetti code—unnecessarily intricate and poorly structured. What hides under the hood of a CMS matters a great deal, because poorly architected code slows down, frustrates, and demoralizes even the most accomplished developers, turning any promising new initiative into an endless grind.

Unfortunately, the difference between properly designed and haphazardly thrown-together software might be obvious in hindsight, but there is no way of telling them apart when you are still shopping. Businesses often hedge this risk by betting on CMS vendors boasting a big developer community. Indeed, a vibrant community addresses many of the shortcomings of a slapdash architecture: technical mysteries are solved with a quick googling session; there is a smorgasbord of themes, plugins, and extensions to supplement the standard functionality; and one never runs out of experienced technical contractors to recruit.

But the rise of API-centric services and the new approaches to publishing they spawn—from headless CMS and content-as-a-service to mobile backends and static site generators—has added a new twist to the old story. Rather than requiring developers to slog through the quirks of internal architecture or master a hodgepodge of tools and frameworks, the new breed of CMSes hides the complexity behind an API layer. All a developer has to do to fetch the content is issue an API call, and, milliseconds later, a neatly formatted response is returned. As long as a developer is working in one of the popular programming languages, the costs of integrating content delivered this way are trivial.

This means that technical stakeholders have to make a strategic architectural decision in addition to thinking about security, deployment, and performance. Traditional vendors offer complex software that takes months to master, but has a large developer community to turn to. New upstarts provide lightweight services with no programming overhead, but it will take years before they catch up in terms of social proof.

Here are some questions to help weigh the pros and cons of these options:

  • How much specialization is required to master the CMS? Does the CMS expose data in a standard way? Is there a clear separation of concerns? How well-documented is the code? Is customizing the CMS supported by default? What developer tools are available?
  • How big is the developer community? Are there many technical contractors specializing in the product? How easy is it to troubleshoot bugs and find answers to technical questions? Is there a marketplace catering in extras?
  • Does the CMS ship with a native API? What type of data is accessible programmatically? How detailed and well-illustrated is API documentation? How difficult is it to customize API endpoints? How does the API perform against the benchmarks?

The editor’s fear of manuals#section3

Developers usually find detailed software documentation a sign of quality. Busy editors take just the opposite view: the best publishing tools come free of manuals and are intuitive to use. Unfortunately, the generic interfaces they have to contend with today more often feel like a product of a violent database eruption rather than painstaking design. Some vendors have tried to address the problem by improving styles and layouts, adding descriptive labels, and tweaking interactions to take the friction out of using a CMS. But better interfaces alone won’t make a CMS intuitive—we need better authoring experiences (AX).

Getting AX right requires that software developers design the CMS around the way editors and content authors perform their tasks—for example, preparing and uploading responsive images, identifying stale content in need of refreshing, customizing field labels, or updating help text. A good AX comes from actively and carefully designing for those everyday workflows, so that editorial teams can define their content model and customize the authoring interfaces without touching the code.

This focus on AX dovetails with concerns about how to structure content inside the CMS. Traditional, page-centric tools store information in big blobs of data, where actual content is mixed with formatting styles and layout elements. Karen McGrane has illustrated the painful struggle to adopt such content to new mediums in all its gory details. The antidote to the majority of these problems is to disassemble undifferentiated content blobs into small, reusable chunks of data and keep this data strictly separate from the visual presentation.

The organization of content has a dramatic impact on the productivity of the team, because it provides editors with very distinct tools. Page-centric CMSes allow authors to assume the role of a designer and tinker with how things look in a desktop browser. Structured-content CMSes help authors act like architects, assembling individual pieces to fit the constraints of a specific medium. Editorial teams obsessing over the look of their content would feel sabotaged without a WYSIWYG editor, while teams working in multiple mediums expect content to come in LEGO-like chunks. The real question is, which use case is critical for your business?

When selecting a CMS, examine your use cases and editorial process, then consider these questions:

  • How customizable is the CMS? Can custom data types be defined without coding skills? What about UI? Can authoring experience be tailored to reflect the team’s workflows and culture? Can the CMS accommodate the needs of several user groups?
  • Does the CMS support high-fidelity presentation? Does the CMS include design templates? Can editors select layouts and style individual page elements? What preview options are there? Are assets auto-scaled for target viewports?
  • Does the CMS support structured content? Is content broken down into reusable chunks? Are inputs stored as specific data types? Are editors prevented from formatting and styling entries? Is it easy to define and maintain multiple content types?

Helping managers see the big picture#section4

Managers are rarely mentioned in the context of CMS selection; when they are, it is usually to tell a cautionary tale about the dire consequences of listening to the HiPPO. This line of thinking tends to ignore very valid concerns that decision-makers like senior editors, marketing VPs, or product managers have.

Managers orchestrate individual contributors to produce content serving an organization’s needs. It’s a tricky process that requires strong planning skills, lots of empathy, and attention to details. While a CMS is a poor substitute for empathy, it gets its chance to shine by helping busy managers see the big picture: what content is live, which pieces are scheduled for publishing, and who on the team has fallen behind. Contextual information also comes in handy when working with individual pieces, where the ability to visualize recent changes, enforce validations, and track down whoever deleted the cover image helps streamline internal discussions.

Juggling roles and permissions is another source of managers’ anxiety, largely because access management is often the last item in a CMS vendor backlog. Organizational culture dictates very different needs in this area: managers charged with coordinating a constantly evolving network of contributors want a one-click approach to onboarding new contributors and waving goodbye to old ones. By contrast, those working with stable teams are more interested in capturing in-depth author info.

The same goes for workflows: flat organizations can get by without elaborate checks and balances, while those in regulated industries might look for a way to enforce triple sign-off before new material hits the homepage. All this just goes to show that the goals a team pursues profoundly shape their expectations about how different parts of CMS will work. Even when CMS vendors reassure you that their tool comes packaged with roles and permissions, remember to investigate whether the way access control works really fits your needs or requires a computer wiz to operate it on a daily basis.

  • How can one keep tabs on CMS activity? How does one follow organizational activities? Are there notifications? If yes, how do they work? What filtering and reporting options are there? Is contextual information available under individual entries?
  • How are roles and permissions implemented? What default roles are available? What does it take to add custom roles? Can one review current access details? How easy is it to add/remove collaborators?
  • Does the CMS support specific workflows? Can the publishing process be automated? Does the CMS provide template workflows? How easy is it to add custom steps and values? Are there built-in notifications?

The human bottleneck#section5

CMS projects succeed or fail largely due to human factors. The CMS plays a different day-to-day role in different departments, necessitating strategic trade-offs. Some trade-offs are interrelated: an API-powered CMS is easy to combine with cloud-based analytics and A/B testing services; focusing on AX makes it a breeze for managers to set up custom workflows. But it is just as likely that in some situations, your organization will find itself at a crossroads, with key stakeholders opting for competing CMS vendors. How does one handle these sensitive situations?

In the past, a common way of resolving these differences of opinions was to defer to the IT department or gracefully accept the backroom deal engineered by the higher echelons of management. This approach incurs a lot of costs, with poor usability being the most obvious one.

Instead, it’s best to approach this problem by looking at your production process. Think of the steps performed by your different teams: developers doing custom development and providing daily support; editors creating, updating, and maintaining content; and managers overseeing processes and measuring how published content impacts the business.

Identify the weak links in the process, where risks abound and schedules get routinely delayed. These are your bottlenecks: they hold back organizational plans, drag down the bottom line, and put people under pressure.

The bottleneck is a relative concept: it always depends on a configuration of individual factors in a given situation. For a newly established business, it’s often the size of the IT bill that determines limitations; for a university department, the constraints may come down to the available time and technical savvy of the faculty members; and in a media company with evergreen content, the biggest productivity jump might come from removing the obstacles in the way of the marketing team.

Selecting a CMS with these obstacles in mind improves user productivity in a number of distinct ways—from eliminating mistakes and speeding up content creation to simplifying user onboarding and ensuring more enthusiastic reception. Helping the weakest teams unlock their potential goes far beyond eliminating the immediate bottlenecks—it also makes the entire organization more agile and resilient.

Setting up for success#section6

For a long time, selecting a CMS platform was treated as a technical problem, to be solved by an IT department or a trusted technical advisor. Resist this view. As a tool that defines your online presence, imposes idiosyncratic editorial processes, and affects the productivity of your team, the choice of a CMS platform is too important to be decided on technical criteria or imposed by a single stakeholder.

Approaching the CMS selection as an organizational problem, on the other hand, yields many benefits: selection criteria that flow from functional requirements, work patterns, and cultural expectations of future users ensure focus on the job-to-be-done, not features-to-be-shipped. Visualizing content creation as an organization-wide process helps avoid internal turf wars and prioritizes high-impact solutions.

Start by identifying who in your organization will be impacted by the CMS: we talked about developers, editors, and managers, but the stakeholder list can include other roles too. Next, understand the big trade-offs involved: is the size of a developer community a deal-breaker? How should your content be structured? What is the role of managers? Working through these questions should help you articulate the needs and expectations of future users, which can then be translated into a checklist of technical requirements.

Equipped with this knowledge, you can now reengineer the vendor selection to put the true needs of your organization at the center of all discussions. And once you do, adopting new software will no longer breed uncertainty, risk, and anxiety, but—on the contrary—help your organization become more agile, focused, and resilient. Just like those sales folks have always promised you.

About the Author

Artas Bartas

Artas Bartas is a product builder and writer based in Berlin. He spends his days understanding what makes products tick and businesses succeed. Most recently, he's been working his magic on making customers fall in love with Contentful CMS. A certified fitness freak, he loves to swim, cycle, and run. Find him under @artasbartas.

20 Reader Comments

  1. Good article and Contentful seems ambitious too. Seems like ProcessWire with CDN delivery. Can anyone here compare the ProcessWire API and the Contentful APIs?

    I have competely given up pushing Markdown to clients. It has, without exceptions, resulted in users finding the whole CMS experience un-intuitive. Even though I can make a very good technical argument for using it. Currently I avoid defining any wysiwyg-fields whenever possible. But when styling is needed I will allow a small set of WYSIWYG buttons (bold, italic, linking, headings). For example when an author wants to add an internal link to a body text it is hugely more reliable to provide a WYSIWYG tool with the ability to browse the site structure than first teach Markdown and then teach how to form internal links.

  2. mscore you are spot on with Markdown – it generates so much controversy among developers and users that one could write a book or two on the topic.

    At the end of the day, tools serve a specific purpose. So regardless of how much clients hate Markdown, if their target audience lives on mobile or they want the benefits of a static website, they have to warm up to this format. And vice versa, if the money are made on desktop websites, or there is no compelling reason to expand the reach of the content, then WYSIWYG should work just fine.

    Still, I like to remain optimistic and think that as we experience generational turnover and see more user-friendly implementations of Markdown editor, the popularity of Markdown is set to grow.

    As for your last point, concerning internal links, the approach you suggested is fairly common in the CMS world and indeed provides much friendlier way to reference entries. Heck, combine it with some content type validations and you will have a very intuitive way of making links.

  3. This article really hits home. “CMS projects succeed or fail largely due to human factors”, really highlights the fact that so many IT projects are seen as a binary problem, yes or no, 0 or 1. But the fact that living, breathing human beings are actually using what we build and it affects their productivity and emotional well-being tends to get glossed over. I’ve heard project managers say, “just ship the thing, we just need to hit the deadline”.

  4. @Bjarni given that we live in a self-service economy, this is not very likely.

    @Chen while majority of enterprise offerings suck, consumerization of enterprise software, where products loved by individuals are eventually adopted by companies, offers some hope. Evernote, Dropbox, Asana, Slack all went down this way. I hope CMS will eventually follow this trajectory too.

  5. I’m ok with a limited set of WYSIWYG elements. Mostly a good style sheet and training is all that’s needed. I find that if you inform your end users before, and periodically after deployment, they are ok with not being able to make purple text on a lavender background.

    I’m also not big on numerous templates for content. a good wyiswyg editor can handle that. I don’t necessarily care how the page is presented. Again, this is a training/communication issue.

    Political BS (I work for a college, I know whereof I speak) can be mitigated just by talking. Before that, simply asses your end user skillset and choose appropriately.

  6. I have a huge problem with this article: not once do you say what a CMS actually is. I know what the letters mean (“Content Management System”), but I’m less clear what that is or what it does.

  7. A lot of people are fine with off-the-shelf CMS systems, but why do so few companies think about building a system from scratch?

    Yes, there was a bit of upfront cost for my company (one day of labor) to get the basic system working, but now we have a system that can be tailored to whatever bizarre requirements come up.

  8. Thanks for an informative post! Someone asked for CMS definition: it’s a system to make your site run properly and serve your business interests fast and easy. I suppose, we all have dealt with all of them and we know – there’s no such thing, as a ‘perfect CMS’. Why? Because our web-world evolves so fast, that day to day we get updated and web-intelligent. I’d love to have everything done by geeks, as http://codingninjas.co/ and run all my projects by others =) However, I suppose none of the CMS can do your work as good, as you.

  9. @delray, building a fully-functional CMS is a big undertaking. Sure, creating a basic interface for editors and hook it up with a template on the frontend is a straightforward enough task. I would even go as far as to say, if your use case can be done on a static site generator, CMS becomes optional.

    The devil, however, lies in all other tasks that emerge as the content production gets going – scalable delivery, fast search, access control, input validations, content modelling, asset management, content versioning and so on. All those features take months and months to build and there is no good substitute for a CMS in this case.

    Hence, if any of those requirements become ‘a-must-have’ feature for an organization, buying off-the-shelf CMS is faster and cheaper than creating one yourself.

    @Mary, you are right; outsourced website management just adds another layer of costs, delays, communication overhead to an already complicated process, which is why organizations who produce content for a living move away from relying on web admins to having in-house editorial and dev staff.

    The bottom line here, as I stated in the article, is actually to think about the organization’s needs and understand what role content plays within the business model. This tends to simplify many other choices down the road.

  10. I don’t know why people opt for wordpress CMS no matter what their requirements are. When there are hundreds of options available, people just don’t care about comparing different options rather they blindly believe what they are told by their friends or some internet gurus

  11. Nice article.
    There is nothing like the best CMS, instead choose the one that supports the business requirements. Consider to use a CMS that is user friendly and provides number of options to create an effective website. CMS must be flexible to cater the changing business needs and should be able to create responsive designs that works well with any device, may it be mobile or desktop. CMS that can be expanded to multi-languages and is capable to handle multiple user permissions is an added value.

  12. One key non-technical decision point on choosing a CMS is whether your customer will be satisfied with a good-enough solution in most areas, or whether custom design and initial or ongoing specific functional requirements will have to be satisfied.

    Most CMSs (WordPress being the classic) whose strong point is to provide standardised web site sections or components will be a positive hinderance if a good-enough solution is not enough as you will wind up spending more time getting standard components to do what you want than you would have spent on custom development.

    However if you can get away with using standardised components, this is obviously a massive saving in terms of development time and resources

  13. We use two famous CMS tools i.e WordPress and magento to develop our eCommerce needs,working beyond our client’s expectations which also provide an easy and effective way to build a custom website. website design services toronto based company looking forward to use some other web tools available in the market.

  14. Hello Artas
    One crucial thing that you need to understand is that when ever you have to make an CMA you need to consider its visual impact. The colour scheme should match your products.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

Nothing Fails Like Success

Our own @zeldman paints the complicated catch-22 that our free, democratized web has with our money-making capitalist roots. As creators, how do we untangle this web? #LetsFixThis