If you’re a content strategist, you have likely heard a lot about the importance of being part of designing and customizing content management systems. But if you’re a developer, you may not have the same perspective.
On a recent project, I witnessed this firsthand. While I made a point of creating content templates, identifying content types, and designing governance practices with an eventual CMS customization in mind, the (external) development team was not prepared for the same level of collaboration. They looked at my deliverables as options, and when my ideas didn’t fit, rather than open a discussion they unilaterally made decisions. Unfortunately, the result was a CMS that didn’t fit the content needs or the editorial team’s abilities.
I was furious. But once I calmed down, I realized that this is a recurring problem, and the only way to solve it is to get developers on our side, and make the collaboration process a simple one for them to engage in.
For starters, here are a few suggestions of how to explain the value of content strategy collaboration to a development team.
What’s the benefit to the dev team?
Developers have been building and customizing content management systems for years, and doing just fine without content strategists. What’s the benefit, from a development standpoint, to making time to discuss decisions with a content strategist, particularly given the time and budget increases that might result?
- While the development work is certainly important and difficult, and the content being put into a CMS is ”just content,” content needs to be formatted to appear on multiple devices, and the development work can’t properly be tested without content (or proto content) that fits the requirements. In other words, content demonstrates functionality.
- When the development is under way and a member of the editorial team asks for something like a table, or a dropdown on a page, the development team can easily hard code it into a page. But unless everything across the site is being hard coded, the editorial team needs to be able to add elements like that in the future. That means the content types of a certain page (which may include items in a dropdown menu, or content displayed in a table) need to be accounted for. Essentially, dev teams sometimes find it easier to give the team a fish than to teach the team to fish.
- What this all comes down to is that, for most editorial teams, the developers building their site won’t be there forever. Content strategists are considering future content updates and the governance models that enable them. Those future-friendly elements need to be communicated across the development team, and communicating it once is not enough.
How to involve content strategists
Even the development teams that agree with this concept struggle to put it in place. They have daily scrums, weekly deadlines, and a process they’re comfortable with. They have teammates (often other developers) who they work well with. Content strategists don’t fit nicely into the day to day.
Here are some tips for collaboration:
- Imagine that every CMS is being custom built. Don’t start by looking at the technology available. Instead, consider that an important constraint, but look for how the CMS can be updated, customized, or best used to accomplish the editors’ goals as simply as possible.
- Outline the user (author) flows. Make a point of keeping each process under 5 steps.
- Meet frequently, and ask questions as builds go through. The biggest mistake you can make is waiting, and assuming it will come together after the next sprint.
- Test with real content – and with the most likely content. We often design for the exceptions, but when it comes to CMS processes it’s not useful to be able to create the exceptions easily, but require 14 steps to accomplish the weekly content updates.
- Focus on simplicity of steps, not simplicity of systems. A great dev team understands the backend, and a CMS is often defaulted to be a simple system. But for authors who have no experience with CMSs, a simple system means nothing to them. They need their steps to content creation to be simple.
Collaboration needs to come from both sides, and we need to do what we can to make it easy for developers to work with us, for the good of the author’s experience.