Sitecore Developers: Get to Know Your Content Authors


Brandon Bruno


June 28, 2018


Sitecore Developers: Get to Know Your Content Authors

It’s no secret that I love working with and designing great content authoring experiences in Sitecore.

While I’ve talked extensively about the technical considerations of designing for the Sitecore Experience Editor, considerations for a quality content authoring experience actually begins by understanding who your content authors will be. When developing components for use in the Experience Editor, designing an information architecture (“IA”) for content, or configuring workflows for complex business logic, it is crucial to understand who will be using these tools, interfaces, and processes.

Design For the Role, Not the Person

Developing software is hard, and it’s notoriously difficult to develop against a moving target – project scope is a big concern for any development team. The Sitecore content authoring experience should be tailored to serve its content authors, but people themselves are moving targets. People come and go from organizations, but roles do not change as frequently. Before designing and developing an authoring experience, understand the role of a content author. Once you have defined the what, how, when, and why of content authoring, then components, IA, and workflows can be designed around the expectations of that role. There may be multiple roles that serve different purposes, and each role will likely have a unique authoring experience.

A role will help define both technical requirements and process governance, such as what authors can affect on a page (layout, component placement, field content, etc.), how much of the content tree is accessible to authors, and who can approve content to production. Once authoring roles and responsibilities are clearly defined and understood by both business and developers, it’s time to find the right people to fill those roles.

Integrate Author Feedback Into Your Development Process

No matter how well-design an authoring experience may be, content authors will ultimately decide if it’s worth using. When faced with a task, people tend to choose the path of least resistance. For example, if your Experience Editor is full of bugs or constantly throws errors, authors will likely fall back to using presentation details in the Content Editor to assemble pages and content.

To help prevent that possibility, developers should include content authors in the development process. Authors can provide invaluable feedback to architects and developers about component usability, IA discover-ability, and practical workflow processes. Integrating authors into sprint retros is a great starting point. Accepting and responding to user feedback into the development process will help ensure that design decisions are steering development down the right path, and ultimately to a successful launch. Feedback gained during user testing should be integrated into the next phase of development.

Let Training Create Confidence

While it’s important to build an intuitive editing experience, you should never assume that your content authors are idiots and thus oversimplify your tooling. For example, while the Experience Editor is a great tool, it’s still much more technical than Microsoft Word or other common WYSIWYG (pronounced “wizzywig”) editors. Content authors should always be well-trained on the tools they will be using in Sitecore.

Training provides reassurance to authors that they can accomplish their tasks and complete their work without risk of breaking the system. Training builds confidence, and confidence helps create productive people. On the technical side, training allows components to be designed and implemented with flexibility in mind. Some HTML content – such as tables – are notoriously difficult to create in a WYSIWYG editor, and this content will require complex component to provide a flexible and accurate authoring experience. Whatever may be lost in a component’s simplicity can be made up for with training.

Do you have questions, comments, or corrections for this post? Find me on Twitter: @BrandonMBruno