To ensure the authoring experience receives proper attention, we’ve incorporated these content author centric development best practices in our development definition of “done”:

1. Support the Experience Editor mode by using Experience Editor friendly controls (i.e. fieldrenderers) whenever possible (e.g. <sc:text />)

When it comes to content editing in Sitecore, the Experience Editor interface is king because of its ease of use when it comes to working with Sitecore's component/datasource based content model. With that in mind, supporting inline content editing via Sitecore's fieldrenders is a must. For fields not supported by fieldrenderers, try using field editor buttons.

2. Sublayouts/renderings are intuitively named

Sublayout/rendering names are exposed to content authors when they use the component wizard in Experience Editor mode. The name you give your sublayout/rendering will be the name the content authors see in the component wizard.

3. Placeholders are intuitively named

Similar to sublayouts/renderings, placeholder names are exposed to the content author in Experience Editor mode. Use intuitive names. Avoid placeholder names such as Content in favour of more descriptive names like Footer or Right Rail.

4. Components are properly assigned to placeholders to enforce the design (e.g. A slideshow should not be available in the right rail)

Hero Banner or Marketing Slideshow components are likely not components you want your content author to add to the Footer or Right Rail placeholders. Expose component availability so that content authors are prevented from deviating from the intended design/organization of your pages.

5. Thumbnails have been added to the components (viewable in the "Add Component" wizard/dialog)

Thumbnail images added to sublayouts/renderings are presented to a content author when they use the Component wizard. In addition to intuitively naming your component, the thumbnail can act as a visual cue as to the underlying functionality of the component. For best results, use examples from designs of the component as your thumbnail.

6. Insert Options are only available where absolutely necessary

Understand your content tree and where specific types of content should be created. Too many options can lead to confusion. Only expose the options that are necessary for the specific location in the tree. As a rule of thumb, if a template is only used once to create a single item (e.g. a unique Contact Us template), insert options should not be configured for that template. Instead, a Sitecore content administrator should be responsible for the one-time creation of the item.

7. Fields are consistently ordered across templates (e.g. the Page Title field is always at the top)

I've seen this particular issue cause lots of frustration with content authors. If you are sharing fields across templates, those fields should be found in the same relative vicinity (i.e. top, middle, bottom) across those templates.

8. Fields are properly validated (e.g. required)

If you are expecting content in a field, or expecting a specific format, be sure to make use of Sitecore's field validation. You can even prevent the page from being passed through workflow if fields fail validation. Content authors are happier when they know what is expected of them.

9. Load enough and varied test content to test your code and markup properly

In our experience, the best content to use for testing is real content, either from the existing site, or content that has been specifically created for the new site. It can be frustrating to add content only to see the design of the page break because the text provided in the field is too long, or a single or multiline text field has been used to output content when a richtext field that allows for addition of markup should have been used.

10. Provide field-level help text for your content authors

Add help text to your fields via the Short Description and Long Description fields directly on the field template.

11. Where appropriate, ensure sub-folder creation is possible in your repositories for additional organization

A flat repository organization can get unwieldy as the number of content items in the folder grow. Allowing for subfolder organization can help alleviate this issue.

12. Use unique icons for each template

Icons identify the template used to create an item in the content tree. They act as a quick way to identify different types of content.

13. Ensure naming continuity with terminology used in requirements with artifact names in Sitecore

If you spend the discovery phase of your project talking about a Subpage artifact as the most common page in the site, be sure to name that template Subpage in Sitecore. This helps accelerate a content author's learning curve when they start using the system for the first time.

14. Your frontend HTML/CSS should be Experience Editor friendly.

Editing a slide that auto-transitions off the screen does not make for a pleasant content author experience.

15. Use workflow!

Without workflow, when you hit the save button to save inflight changes, your changes are also publishable immediately, whether that is your intention or not.

16. Hide or prevent write access to content items

Be sure to plan a proper security model. Content authors should only have write access to their own content. You can even hide areas of the content tree from content authors where it makes sense (be careful here, because removing read permissions may have unintended consequences).