The biggest project failures are the ones that forget the end user.
We know the stories. Healthcare.gov. The charging port on the Apple Magic Mouse. Gerber Singles.
For this reason, the web design and development world is hyper-focused on reaching the right audiences and building systems for clients and customers. We do all of the research, and we do all of the interviews, and we do all of the prototypes and the A/B testing and the focus groups and on and on until we’ve built something we’re sure will hit all the right notes at all the right times.
We do this for all important user audiences except for one. The people we hand the keys to. The people who will become more intimately familiar with the site than anyone other than the developers themselves: the marketing and editorial team.
These sites are for them, too. So, let’s make sure they’re ready to go.
Alignment is Everything
Anyone who has tried to create a Rube Goldberg machine or set up a complicated set of dominos knows that complex systems take a lot of time. It’s not enough to start laying out pieces and pray for the best. Environmental and situational factors are at play — a set of stairs or a gentle breeze — each affecting the system itself. They’re complex for a reason.
At its best, A content management system is a complex communication system. It allows us to go beyond a simple and singular message by connecting with and adjusting to environmental and situational factors. It allows us to reformat our message for specific devices, and it allows us to edit, improve, and promote our message over time. It takes a unique mix of content, design, functionality, awareness, and best practices — a mix that does not just make itself usable out of thin air.
Preparation for a new content management system, therefore, needs input from more than just the Umbraco development team:
- It needs input from content strategists and editors. They will help identify the purpose of site templates and the need for additional content types.
- It needs input from information architects. They will help determine how content is structured for reuse and portability and help users find their way toward the right outcomes.
- It needs input from designers and front-end developers. They will help maintain consistency and usability, guide the design system, and ensure the message is understandable by anyone who arrives on the site, regardless of ability.
- It needs back-end developers and QA managers. They take all of these recommendations and make them real, balancing creativity with possibility.
And, it needs input from the editorial team. While the four groups mentioned above do the hard work of ensuring the site works toward the goals of our audiences, the editorial team is the audience we already have on-site. We’re already working with this team, and aligning content strategists, information architects, and QA managers with the workflow and process needs of the marketing department is the most obvious first step to creating a usable and valuable tool.
This alignment will make the new content management system a welcome addition to the workflow rather than a hindrance to overcome.
Timing is Everything
Of course, alignment isn’t a thing that happens. It’s part of a larger system and needs to be planned in advance. The thing about web work and complex systems is that the work begins long before you might think the work should begin.
First, remind yourself that a website has no ending. The launch is not a finish line: a website lives on until the next one comes along, and the process starts over. But there is an end to what we might call the “website project:” a launch date for the move to a new content management system, the point where the keys are handed over and the site shifts from “project” to “product.”
From the point of that initial spark, this launch is represented as an abstract date months or years in the future, and there is so much to do in the meantime. It’s easy to push launch-adjacent items off, addressing them with that “Yeah, yeah, we’ll get to that when launch gets closer” mindset.
Don’t do that. Things take time. So take the time you need, as early as possible.
Discovery is Research for the Future
For example, project discovery involves wholesale research of site users, sales funnels, UX needs, and overall requirements. However, it should include more than just sales funnels and requirements — the project team needs to understand how the editorial team will be managed and what role this tool will play in their day-to-day work.
For this reason, during discovery — and especially as we begin thinking about how this code will save the needs of the editorial team — existing workflow and potential improvements to that workflow need to be understood. How is content created — not just how it’s entered into the CMS, but how it’s ideated and assigned, from scribbles in a notebook to shared Word documents. How long does it take? How many people are involved? Who tracks engagement, and who owns it once it’s published?
More than that, the dreams of the website need to be mapped to the people who will make those dreams happen. Promising better data tracking is exciting, but who will be tracking that data? Will it be a new employee or thrown on the pile of someone’s existing workflow? It’s thrilling to know that articles can be populated with the help of AI tools, but who will be responsible for ensuring the AI hasn’t gone rogue and promised a new world order? Is that something you really want tacked onto someone’s existing job description?
Content Models Require Reality
How the editorial team uses the site means more than logging in and training on features — it also means understanding the mental models we create around content itself.
Take the idea of an event calendar, for example. It’s easy as a development team to understand the strengths and limitations of various models — the difficulties of recurrence, the quirks of time zones, the frustration of one-off event models — but an editorial team has an entirely different model in mind, in which the flexibility and understanding of time, and the standard Gregorian calendar have been taught to us since we were five. We, as humans, know how calendars work. Robots don’t, at least not without a full project team dedicated to only focusing on that one problem.
This may — haha, just kidding … this WILL — cause frustration for developers. A developer’s idea of how this content is modeled fundamentally differs from how a writer, marketing manager, or graphic designer understands it.
Here’s the thing: neither side is entirely correct. Instead, these modeling discussions need to worry less about which way is correct and more about how to align so that the development team can model things the way they know will work while still preserving the real-world model that editorial teams understand. And that discussion must happen early enough that significant changes aren’t being forced close to launch.
If You’re Teaching the CMS Before Launch, You’re Too Late
Speaking of things happening too late in the process, let’s talk about training the CMS, a process that we for some reason keep pushing too late in the process.
Haha, why do we do this to ourselves?
CMS training is our second layer of quality assurance. It’s a second chance at understanding those mental models. And, more than anything, it’s our chance to ease the editorial team into this new tangled monster of a content management system.
At Blend, we get clients into the CMS immediately. Sprints and epics are designed to provide a set of templates that work together toward a common goal, a goal that we then hand off to the editorial team. For example, the work that goes into migrating, editing, and launching a profile directory requires a handful of templates, a few blocks, and a lot of time. Getting the client into the system to work on these templates — even if they’re the only things we’ve been able to complete! — gets them comfortable with the CMS long before launch while providing a valuable layer of testing data and real-world usability.
If your client is seeing the back office for the first time as you’re demoing features, it’s already too late. If your client hasn’t started entering content until three weeks before launch, it’s really already too late.
People are Everything
Of course, when it comes down to it, a new website — and all of the trappings therein, from the content model and strategic vision to the system it’s built upon — is created in service to actual people. Even with the onset of artificial intelligence solutions, the strategic vision of digital communication comes from real humans with real ideas and real thoughts.
This makes things messy. It is not a problem that can be programmed away. As we’ve already talked about, it requires planning and early access. But, more than anything, it takes patience and understanding.
First, the shift in thinking from one website to another is more than just learning a few new login URLs and passwords — it’s a wholesale shift in how we do our work. Moving from an older static site or more “tenured” content management system to a brand new Umbraco install means learning and understanding the general concepts of content management as a whole. For a team that might be used to sending this content off to IT via Word Documents and PDFs, this is not just a new process but a new skill.
And while this move toward modern technology seems difficult, it can be harder to make more subtle changes. The editor learning about CMS for the first time is doing just that: learning. But someone who is moving from a modern CMS to Umbraco is actually relearning — they come to this system with their own entrenched idea of how things work. It’s no longer a case of “how do I create an accordion,” but a case of “I’m used to an accordion being created in a slightly different way.” One creates new work, while the other requires changing habits.
Habits are hard to change. They make us rethink how we do our work, and in extreme cases, they make us rethink our entire relationship with the work itself. We might feel too old. We might feel bad at our jobs. We want things to work well, and we feel stupid when they don’t.
This might not always be the mindset of your editorial and marketing team, but it is the mindset of many. It’s the world of organizational change, which is difficult and slow and impatient. It’s our role, as stewards of this technology, to make sure the transition doesn’t cause wholesale panic. To make sure everyone is brought along with us. To make things work — for the users, yes, but also: for everyone.
