Umbraco: the friendly CMS. Or is it? Umbraco's intuitive interface, its support and it's friendly community definitely go a long way. However, developers who build their websites with Umbraco still have a big responsibility to deliver on this promise. If you are a developer, then this article might be interesting for you.
As a developer, you need to step into the shoes of your user. How will they look at the CMS? What are their motivations and what are their goals? If you fail to understand the user, there's a chance that they won't experience the friendliness that Umbraco promises.
Together with a content editing expert, I've compiled a list of rules and guidelines that help me build a content editing experience that my users will love. This article will highlight the most important rules that work for my users. I hope that it might inspire you to step into the shoes of your users and that it might give you some ideas to set up your own rules for building content editing experiences.
Introducing the users
Before diving into the rules, let's first have a brief look at the users upon which they are based. There is a wide variety of backgrounds for my users: some of them might work in a zoo, others in healthcare and some might work for an insurance company. What these users have in common, is that they have little affinity with the technology behind websites and the internet in general. The users are often goal-oriented: They need to fulfill specific tasks, like publishing news or updating vacancies. Maintaining content is considered a chore and the users are often only interested in the features that directly affect their goal. Beyond that, the website just has to work.
For such users, it's important that their CMS aligns with their goals. If the CMS does not align with the user's goals, then it leads to frustrations and questions. In practice, this means that the CMS should be minimalistic and straightforward. A user should only need to worry about the content of the page. A good CMS minimizes constraints and maximizes freedom.
With those things in mind, let's dive into some of the rules that I use when designing an Umbraco backoffice.
Descriptions tell what something is and what a user can do with it
It's very simple: if a user doesn't know what something does or why they need it, they're not going to use it. It's very likely that users don't read any descriptions at all until something doesn't work the way they expect. By the time they read the description, they will already have questions, so a description must answer those. It can be even more frustrating for a user if a field is required, but they don't know what they're supposed to do with it. It makes them feel clueless and dumb. Adhering to this rule should make your users feel more in control. If a description covers the two questions "What is it?" and "What can I do with it?", it answers the most common questions that users have. Here's a bad example description and a better alternative:
❌ Add a CTA here
✅ Add a button below the page title here by selecting a content page or entering a URL
All functionalities are consistent
If the user is already reluctant to learn how a feature works, it's all the more frustrating when that same feature works differently on different page types. This rule also applies to vocabulary. Being consistent with your choice of words makes it easier for a user to understand context and expectations.
| ⚠️ NOTE |
|---|
| A feature doesn't necessarily have to be the same to be perceived as similar by the user, so it's essential to get an understanding of how your user looks at their content. |
The content is linear
Linear means that content that is entered later does not prompt a user to revise content from earlier. It also means that there is no "wrong" way to fill your content. Examples I regularly see are properties that cancel out other properties or different combinations of properties causing different behaviours. They are often accompanied with descriptions like: "If you fill this property, property x will be ignored" or even worse: "Fill property x and y to use option 1, fill property y and z to use option 2". Don't make this a puzzle for your users.
Every block or group has an example image if possible
Users don't always know what they're editing. They love the preview feature, because it helps them understand their content. Switching back and forth between the preview and the CMS becomes time consuming though and should therefore be avoided. Adding a screenshot of some example content for a block gives users a quick visual indication of what they're creating. Make sure that this image is always available without extra clicks. A thumbnail in a blocklist is nice, but once a user selects an option, they've likely already forgotten what it looks like. You can easily solve this by adding that same image to the block content.
Optional properties include (optional) in the description
More generally: make it abundantly clear which properties are required and which ones are not. The tiny red star that Umbraco adds to mandatory properties is very regularly overlooked. Users don't like being told that they're doing it wrong, so you have to make sure that they don't make any mistakes. My approach is to make everything mandatory by default, unless explicitly mentioned otherwise.
Groups have comprehensible names
More explicitly, choose one of the three following options as a name for content groups:
- Use a common term that the user understands (Either a commonly understood term or jargon from the user's field of expertise)
- Use a short explanatory phrase if no term exists for a content group
- If no term exists and the content cannot be described in a short phrase, then use a less familiar term, but add a note with additional explanation
Always avoid technical terms or jargon from your own field of expertise.
Some good examples are:
✅ Header
✅ This is what your page looks like in search engines
Some bad examples are:
❌ Open Graph (non-technical users don't know what that is)
❌ Generic (this word feels technical to users)
Do not use any of the forbidden words
It's very easy to introduce technical vocabulary in titles and descriptions without noticing. To help prevent that, I have a list of words that are not allowed to be used anywhere in the CMS. Each word has an alternative that users understand better. Some noteworthy words on my list are:
| Bad word | Better word |
|---|---|
| Node | Page |
| Intro | Introduction text |
| Display | Show |
Notice that this word list is based on personal experience and is ever growing as more words are discovered that cause confusion.
Final thoughts
Though Umbraco does a lot to be the friendliest CMS out there, much of the weight still rests on the shoulders of the developer. Using some concrete guidelines and a good understanding of your client, you can make it easier for yourself to deliver on that promise.
These rules are a great start, but there's more that I would like to explore still. As of currently, these rules are enforced manually through regular reviews. I would like to explore the possibilities to automate this so that our reviews become more effective. Perhaps that's a topic for another blog.
What are your thoughts on these guidelines? Do you have any rules and/or guidelines that you use when designing your backoffice? Let me know in the comments! For now I'll say: Thank you for reading and I hope to see you in my next blog! 😊
The images in this article were created with the assistance of AI
Top comments (0)