There are lot of posts extolling the virtues of this omni-channel approach (e.g. lower operating costs and swift delivery), and leaders within the API-first content solution market such as Contentful emerge as viable alternatives when companies seek to adjust how they approach content management.
The shift towards approaching content as a service (CaaS) brings new challenges, which can sometimes dissuade people as the effort required seems too laborious. The truth is that these challenges are not as foreboding as they seem. The shift to these new platforms requires an internal shift in mindset, but clear processes can make the transition relatively painless.
Setting up content models
If you’ve seen the admin areas of tools such as Contentful, creating content models appears simple. And, to a degree, you’re right. Physically creating the content models is straightforward enough, but when you step back and consider the wider picture there’s a lot more to it. You’re no longer simply adding content for the website. The API-first platform has no real concept of a “content tree” (although you can mimic this with naming conventions and taxonomy). The content you create can be distributed on any number of channels.
Herein lies the first challenge. Content model creation cannot be handled by one party alone. Cross-functional teams are nothing new, and they exist in one form or another in many businesses. They have a big part to play when it comes to delivering effective content models. Typically, these teams contain developers, UX/UI/creative designers and content authors, but might also contain representatives from other areas of the business if necessary.
However, a cross-functional team can fall apart – e.g., when one person or department exerts too much influence on decisions. Based on MMT Digital’s experience, I’ve pulled together five practical recommendations to help you set up and run cross-functional teams to deliver content models that will power your channels.
1. Planning is not a dirty word
The benefit of the API-first approach is that it can deliver projects rapidly on any channel or technology stack. However, just because there’s a need to deliver quickly doesn’t mean that you should to dive head first into content modeling and put something together on the fly. At the same time, you should accept that things might change. Therefore, it’s imperative to create a solid foundation and framework that can evolve along with your project.
Holding workshops at the start of a project is invaluable. Paper and post-its or drawing things out on a whiteboard is an ideal start. That way, you can sketch out your content models and move things around before getting near the software – much easier than gathering around a computer screen.
2. Speak the same language
Unless you are very lucky, there is likely to be a disconnect in terminology when it comes to the components of content models and how certain elements are referred to. This is something that became very apparent in previous workshops.
Take the time at the start to establish a consistent content modeling vocabulary – e.g., what is a pattern, what is an assembly, what is the content hierarchy. That way, every member of the team will understand the conversations being held and pesky misinterpretations that might rear their heads well into the delivery phase of your project will be avoided.
3. Make sure everyone has a voice
Another key takeaway is that some members of a team are more vocal than others. They take charge in workshops and like to impose their views and take the lead on mapping content models. While we do want members of the team to drive the process rather than relying on a project manager dragging everyone behind them, each team member must get the chance to have their voice heard. Everyone has some level of insight into these models – what makes sense to a developer may not make sense to a content author.
Introducing a facilitator into the team (who may be a project manager, scrum master or product owner) to encourage participation and give everyone an opportunity to contribute to the discussion is highly recommended.
4. Think reusable
While your project may be to deliver a website, the important thing to remember is that this is not the only use case. The Internet of Things has exploded with possibility and there are many potential channels to consider.
This means stepping back from thinking about content in terms of pages in the tree. Each content model represents a “block” of content. Multiple blocks can be assembled together to build out a page.
During the planning phases, focus on these blocks and keep content models as reusable as possible. Being smart with content means seeing it as recyclable, and reducing clutter in the software makes it easier for authors going forward.
5. The great balancing act
Ultimately, creating content models is a balancing act. The ideal content model is easy for content authors to understand and use, easy for UX/UI designers to leverage in wireframes and creative designs, and easy for developers to pull out through the API and into websites, applications and channels.
Some content models will be nice and simple with little to no conflict. But there will be conflicts in other content models – the key to success is understanding the impact of decisions made for each of the roles within the team.
The facilitator can keep the project moving forward by leading these conversations and support the team in reaching suitable compromises or alternative solutions.
This is just a starting point for content modeling and there’s more to come as you delve into the activities that surround it (we’re looking at you, taxonomy). However, adhering to these five practical steps during your initial workshops will stand you in good stead for your content infrastructure projects.