Developers and editors play on equal footing in headless CMS endeavors; one provides the framework and the other provides the content that frameworks it into a functional digital experience. However, because these two teams operate under different philosophies, software and processes, the chance for miscommunication exists and easily causes confusion, extended timelines or expectations that go unmet.
Intentional communication efforts between developers and editors establishes a foundation for collaborative ease, successful implementation and functional, extensible content strategies down the line. By acknowledging common objectives and common deliverables, a blended project approach can be established with communication touch points throughout.
Early Alignment on Content Models and Use
There’s a lot of overlap between what developers and editors work on during a project, but one of the essential pieces early on in any headless CMS experience is content models. Developers know what they need to build; editors know what they’re going to need to access and manage within the content models daily.
It’s crucial to bring in content creators to relevant workshops or planning sessions to gather their feedback and opinion on the best use of the structure, which fields are needed, and how items relate to one another. Collaborative product development labs are an ideal setting for these discussions, allowing teams to co-create flexible content structures that meet both technical and editorial needs.
As long as these two parties the building side and the editorial side can come together and agree upon a flexible content type roadmap, they can circumvent rigid and unknowable boundaries which only serve to create content creation stalemates and subsequent unintentional workarounds.
Human Language Documentation of Content Schemas
Following the definitions of the content models, projects tend to keep these functional decisions between the developers in locked code or CMS settings. The problem is that the editors won’t know what’s going on unless documented in human language outside of code.
Therefore, content schemas should be documented in accessible terms, human language, and not code. This means fields, purposes, formatting requirements, sample entries, etc., and intentions from where it came.
Developers should make these available in shared drives, CMS manuals, or notations in the CMS (if possible) so that editors feel empowered with context about each content type and assurance that they’re following the correct use.
Glossary Of Common Terms Across Teams
Developers may think that they’re communicating effectively with editors because they’re using common terms. But for the most part, developers and editors are discussing the same concepts in entirely different manners.
For example, a “component” to a developer is a UI component that displays a page correctly on the front end but an editor’s “component” is a repeatable block of content within the CMS.
A glossary reduces the opportunity for communicative errors as everyone can agree on terms associated with content types, components, APIs, workloads, etc. This can help simplify training guides and get everyone on the same page faster because once a consistent language is established, it’s much easier to solve issues.
Defined Roles and Responsibilities
A headless project may have many different teams involved in the process at different stages within product, design, content, and development. Without defined lines of responsibility, some actions might go unfulfilled while others exist redundantly.
If developers are responsible for setting up the CMS, frontend integration, and schemas, then editors should be responsible for ideation, creation, and optimization of content.
The more that’s documented about who does what, the more collaboration can occur without redundancy and without out-of-whack expectations of timelines and deliverables. This is especially helpful for teams working across time zones or scaling.
Feedback Loops
Just because a project has been pushed to production does not mean that reverence to CMS changes for editors and developers is put on hold.
Editors may find UX unresolved limitations or authoring gaps that need fixing; developers need to know how content structures are performing in the wild and if any developments can be offered to better the editorial side.
Establish feedback loops stand ups, retros, CMS feature requests so that the other side can present feedback to ease the situational reality of the project. Two-way feedback builds trust and is more likely to help sustain a content management oasis down the line.
CMS Permissions for Editorial Ease
Editors should never feel like they can break the frontend by creating or managing content but at the same time, they don’t want unnecessary fields that overwhelm.
Developers can provide for this by creating CMS permissions that allow editors to do what they need from easier access. This means restricting access to schema edits to keeping custom views that simplify fields instead of overwhelming activity to labeling content types by team or campaign to ease access to finding information.
When things are set appropriately across roles, mistakes can be prevented. Editors work with more confidence without developer intervention and both teams can focus on what they do best.
Developer Availability for Non-Technical Editors
Editors, even with a well-functioning headless CMS, will always have questions regarding content delivery on various channels or the relation of fields in a structured environment to the front end.
Developers should be available and approachable for onboarding, training documentation, or office hours for supplementary queries. While it may seem like a waste of time to teach the content team something that can be learned later, it minimizes issues and misunderstandings down the line and helps ensure the proper use of the headless CMS.
The faster support comes for editors, the less likely this content will devolve into a developer concern down the road.
Content and Code Connection with Work Management Solutions
Wherever there are opportunities to bridge the gap between content planning and development efforts, this is an excellent way to keep both teams in sync. Whether it’s through Jira, Notion, Trello, or Airtable, a cross-functional roadmap can help everyone establish project expectations and ongoing productivity for content-focused and development endeavors.
For instance, if a piece of content is “Ready for Integration,” it can mean that developers need to start an API call or need to refresh a certain component. When workflows are unified, editorial and development timelines can stay on track more efficiently without silos or miscommunication.
The Content Journey from Input to Rendering Experience
Editors may never see how content is rendered across all devices and offerings just as developers may not understand how content exists draft, publish, archive.
By creating a visual from entry through approval to API delivery to rendering on the front end, both teams will better understand how their pieces retain value. This avoids confusion during the handoff and establishes buy-in for a more collaborative endeavor.
Regular Syncs for Priorities
Even with an async component, having live catch ups every so often keeps developers and editors on the same page. Weekly or bi-weekly syncs can open up time to discuss content that’s launching months down the line, dev-related improvements, or UX changes that affect how content is rendered or what’s shown when.
That kind of transparency keeps teams aligned regarding blockers they can anticipate and promotes mutual interests and priorities to be conveyed and comprehended across either side of the engagement.
Documenting Component Behavior for Content Teams
Where editorial content creation can feel very disconnected from the front-end dev world, it’s essential for developers to document how content appears across component areas. This means visual behavior, responsive renderings and conditional elements.
If writers understand how their entries appear in the rendered UI character counts, image ratios, field that create layouts vs. non-deterministic presentation they’re better able to create their own content without need for QA or dev assistance.
A System for Change Requests and Schema Changes
Over time, editors are going to want to update the content models, too. Whether that means adding new fields, altering field types, or experimenting with new content types altogether, to avoid making changes live unannounced, a system for change requests should be established.
Doing so allows for schema changes to be submitted via template process that ensures change requests are acknowledged, logged, assessed and approved via set standard operating procedure.
A Living Knowledge Base for Ongoing Partnership
Thus, because your project must scale beyond anticipated deliverables and inevitably, team members will enter and exit along the way, a centralized, living knowledge base repository ensures continuity and captures time-saving efforts.
Over the life of an engagement especially for cross-functional teams in fluid situations some tribal knowledge and living documentation exist, but without everyone aware of what’s already been done, achieved or started, it breeds confusion, redundancy and onboarding hiccups.
Developers, editors, designers, strategists, etc. should all bring their expertise to and grow from a singular source of truth that lives in a repository within the project over time.
Beyond code commentaries, this living knowledge base includes appropriate user guides for the CMS desktops, links to justifications for content modeling (i.e. why certain components were created instead of others), visual documentation of component libraries and associated DOs/DON’Ts for each, various links to articles/libraries/guides used often throughout the project, API documentation and FAQs which start small but build upon itself. This not only provides clarity for what has been achieved technically and strategically to date, but also, insights for future governance and alignment.
This knowledge base supports new team members to independently onboard without intervention from existing team members. It empowers those currently engaged to use as a reference guide for daily execution no matter where someone is located or what time zone, they’re operating in empowering all contributors with the confidence, consistency and context with which to operate.
Ultimately, over time and through a living, documentation approach to daily work, this repository enables resiliency, accountability and collaborative operations at scale as your digital ecosystem continues to expand.
Conclusion: Building a Stronger Dev-Editor Relationship in Headless CMS
The developer and editor are two halves of the same whole relative to functionality required for effective headless CMS implementation as they contribute essential elements to what will be a top-tier, optimized, scalable experience. Yet where in a traditional CMS avenue both might need to take on one another’s responsibilities to achieve content generation efficiency, a headless environment allows for a lean independence yet dependence on specialization.
Therefore, they need to communicate all the more. When the two roles do not communicate clearly or intentionally, integration becomes reactive instead of proactive leading to more friction through delayed deliverables, time lost in translation and missed opportunities to take such learnings further. Yet intentional communication does just the opposite turning headless projects into well-oiled machines that run like well-oiled machines.
Common language clarifies requirements between teams. For example, the developer and editor must refer to “components” in the same way to understand the nature of what it does versus a content type. What’s an asset vs. a deliverable? When does something go into a workflow and what prescribed steps are they recommended to take afterwards? One person’s definition of a “component” may be different than another’s so establishing the established is imperative. Therefore, it’s critical for the developer and editor to collaborate early on to clarify content types and approval flows. Developers generate documentation for reference; editors use guidance tracking for their front-end approvable efforts. Systems are more successful with rules established from both sides.
Boundaries also provide clear demarcation of responsibility/accountability. Developers will “own” schema structure and integrations as well as UI component actions; editors will “own” messaging, media application, and timing of placements. This prevents duplication of responsibility and overreach, provides accountability in one arena as the inevitable progress won’t be stalled by someone across the aisle without ownership.
Intra-team check-ins allow for boundary discussions while shared documentation provides transparency for reduced miscommunications. Shared tools show everyone process and progress without unnecessary back-and-forth.
The synthesis of best practices leads to higher quality efforts when finalized as well more editors will avoid typos knowing a developer is about to launch; more developers will ensure proper placement of components if they trust their editors’ direction. Such trust allows both parties to co-create effective content systems that not only operate based on their capabilities but are malleable enough to change over time and expand.
Ultimately, it’s this relationship between developer and editor that creates a purposeful idealized end result. There’s no need to operate as separate entities hoping for the best way to get to a project conclusion at the end after thousands of developments and edits. This mentality incentivizes collaboration across teams fostering nuance to be transmogrified into actionable, quantifiable steps. It’s headless with heart.
