29th May 2019

5 Ways We Build Experiences That Content Editors Love With Episerver

author image

read by Janaka Fernando

As Head Of Product Strategy at Made to Engage, I've successfully executed many implementations of the Episerver CMS for our clients over the years. I know that it's critical to build a strong interface that today's content editors can enjoy using. That's right, content editors - the people who use the CMS every day to curate and edit relevant content for brands. The first step is to understand the content editors' unique needs and expectations.

To address these needs, the Made to Engage team focus on delivering streamlined Episerver solutions that put the joy of curating content at the centre of the experience. That's one of the reasons why we include a module on designing for the content editor when we're training our back end and front end Epi developers. 

Here's a checklist I made to ensure our developers are building products that content editors can enjoy using.


1. Use clear names and descriptions for all your content types


It should be easy to intuitively name your components yet I've seen plenty of projects that have screens like the one above. Remember, the name you give a component will be the one a content editor sees when they are creating pages so it should be clear. 

While ArticlePage might be a bit lazy, StandardLeftContentPage is unlikely to mean much to the average content editor. Fortunately, Episerver allows you to select a new Display Name as well as a Description for each content type to make this more user-friendly. These names can even be localised if you have editors with multiple languages using the CMS. And the same rules apply for Blocks too. 

Janaka's tip for developers: Avoid generic placeholder names and descriptions like 'content'. The description should always be in line with the intended usage of the page. 

For example:

Article Page

This page is for press releases and corporate information. 


2. Use relevant iconography 

And while we're looking at the example above, did you notice the use of Alloy icons?


Is it just me or do these seem to be the icons we see on almost every project? They only make sense on Alloy because that is the brand of the company. At the very least developers should come up with a thumbnail icon that represents the brand of the customer site they are working on.

The icons are meant to indicate the usage of the Page or Block, so more brand-specific icons would be extremely helpful to a content editor who wishes to spot the right content type quickly.

Janaka's tip for developers: Never release a content type without a thumbnail icon. You could spend weeks delivering the functionality for a specific content type and yet it will look unprofessional and rushed if you skip this detail. 


3. Fully utilise On-Page Editing 

Sometimes there are settings for a Page or a Block that require you to go into the All Properties view to properly edit, such as the number of items to display on a page listing block. However, you should try to make the On-Page Edit view the easiest way for editors to make changes to the majority of properties because this is the most natural way of understanding what those changes will look like. 

Tip for developers: As a rule of thumb anything in the Content tab should be available in the On-Page Edit view. If it doesn't fit in there, it may go in Settings or a custom tab.



4. Avoid nesting of Blocks where possible

Here's one that frustrates content editors no end. They want to do something simple but in order to do so, they have to click through several layers of Blocks. Adding one layer is generally okay, for example, a Block that contains a set of items that might be Blocks themselves. The problem is when those Blocks contain other Blocks the poor content editor has to take four or more steps just to edit the content. 

Tip: Avoiding nesting will lead to improved performance for your site. 


5. Provide human error messages

Error messages provide a better experience for editors, guiding them on how to correct invalid input. However, these don't provide much help if they just show the default message.  


Tip for developers: Try to help the content editor along with examples of the correct input or a clearer error message such as the one below. 


Once again, use localisation here if you need to accommodate editors in multiple languages. 



At Made to Engage we take these measures to build experiences in Episerver that content editors love. I hope this makes you consider the experience of the content editors who will be using the site you are building and incorporate their needs and expectations from the very start.

If you aren't thinking about the content editor when building your product in Episerver, you're missing an opportunity to facilitate the content editing experience and generate better customer engagement for clients.

Ready? We are

CX Consulting. Systems Architecture and Engineering. Design, Build and Optimise.

You might also like...