Talk to the CMS end users: content editors
Have you ever delivered a project that was met by the content team with a collective sigh? There's a simple way to avoid that - talk to them!
As a former content editor, and victim of numerous terrible content management systems, I can tell you exactly where things go wrong on most CMS projects. The reason that no one ever delivered what we wanted or needed was simple: No one ever asked.
This lack of communication is quite common, along with being inefficient, frustrating and counterintuitive. Why aren't we talking to the end users? Yes, it's a content management system, so the content managers are your real end users.
The usual client/vendor communication flow puts a wall between the content team and the development team. Sometimes we assume that whoever we're talking to has already talked to the content team. This is most likely not true. If you aren't hearing directly from content editors, or seeing evidence that the information has come from them, chances are they are not involved.
There can be many different reasons that content teams are ignored. None of them are good reasons.
Reason: It's simply too hard. Everyone will have a different opinion, we won't be able to get a consensus, it will be a waste of time. (Implied here is that content editors don't know what they want, so talking to them is pointless.)
Reality: You're not really seeking opinions. You want input on how people spend their days, how they use the CMS, how you can maximise their efficiency and make things as painless as possible. Instead of asking broad questions that are likely to generate opinionated answers, ask specific questions to gain insight, and use that to inform the approach.
Reason: The person running the project is far removed from the content editors and has no idea what they do each day. Usability is perceived as a non-issue. If we build it, they will use it.
Reality: Oh, boy. I was in a meeting early on in a project, where we explained our approach of delivering features as quickly and simply as possible, then getting feedback and making improvements as needed. The consultant sitting across the table said, 'UI improvements? It ships with a UI, doesn't it?'
There are so many things wrong with that attitude, but let's focus on what's important here. If this is the person you are dealing with, insist on speaking to someone else. It is likely this person doesn't deal with the content team at all and cannot be trusted to make decisions that affect them. You want to talk to someone who will be in the line of fire if the end result is bad. Someone they will complain to directly (because they will complain).
Usability is not a public service. It is not hard to argue that usability in a CMS directly correlates to value. Given a CMS project, we can assume that creating content generates value. So being able to create content quickly and easily will result in more content. If editors have to spend less time fighting with the CMS, they can spend more time generating the actual content. We can logically assume that if they don't hate doing it, they will do it more.
So if you can't speak to someone else, try to educate as much as possible about why this is something that you as a vendor care about, and why they should too.
Reason: The budget is small and usability is perceived as a luxury they can't afford. Maybe we can worry about that at the end, if there's money left over.
Reality: The value conversation is related to this, but it's usually a perception problem. Some people are afraid to ask for things, because they assume it will be expensive or difficult. But if you ask first, and initiate the conversation, they will be empowered to provide feedback. And they will also likely get a feel for what's a small change (e.g., tweaking help text) and what's a large change (e.g., implementing a complex workflow approval system). These conversations might not always result in changes being made, but they almost always result in an increased understanding on both sides.
Especially for those of us lucky enough to build with Drupal, there are a lot of small changes that can go a long way just via contrib modules.
Reason: The CMS is inflexible, and we've already bought the licence, so we just can't worry about that.
Reality: Obviously you're not using Drupal. But maybe you should be!
As the experts, it's our job to ensure that we have the information we need to deliver the best result. This implies we know what the best result is! And the only way to (accurately) collect that information is to include the content editors in the conversation.
