User Experience, UX for short, is a very common term used by anyone who has ever been involved in the production of a website or a digital product. UX places emphasis on the end user, and drives design & implementation decisions that benefit those users.
However, for those of us who build websites & products using content management systems & frameworks like Drupal, there is a second layer of UX that often gets overlooked.
The beauty of a CMS like Drupal is that it comes packaged with a relatively nice administrative interface. While this interface allows developers to easily configure and administer a website, its one-size-fits-all approach is also meant to act as an interface for content editors. Without consideration for the people who will ultimately be in charge of managing content, a website often becomes unmanageable.
Drupal affords developers great flexibility in how to translate a design into a functional website. We have nodes, blocks, views, nodequeues, contexts, panels, paragraphs, boxes, menus, mega menus, etc.
The more complex a website gets, the more reliant it becomes on custom and contributed modules which will often provide their own methods of placing content on a page. This flexibility often spirals into pages where content needs to be managed on multiple screens. Perhaps obvious to some, but not your content editors.
It’s easy for experienced developers to become blind to these potential challenges due to their intimate understanding of Drupal in any particular instance. View headers are clearly managed here; This block lives here, but is managed there; This? This is coded into the template.
This understanding doesn’t easily translate to content editors. There are myriad ways to build a Drupal or any CMS driven website so it looks like the designers mockups. The fastest isn’t usually the best. Despite best efforts in clear documentation and in depth training, an editor will still disregard all of the blocks and panels we configured for them, and instead try to lay a page out in the node wysiwyg editor because the admin UX sucks for that content type.
Poor UX for content editors and administrators ends up impacting everyone from the client to the end user. Content editors will see an increased time and frustration level in producing and editing content. Website maintainers and other vendors will see increased time in updates and management. End users will be presented with an experience that degrades over time. All of which will become a financial burden to the client.
What can be done?
This post isn’t meant to be prescriptive or exhaustive in this regard, but the main message is: Don’t rely on developers to make all the decisions around how content is to be managed. It’s not fair to your clients or the developers (although there are many developers that pride themselves in great UX for their CMS’s). User Experience planning needs to be extended to whatever app you are using to manage content (Drupal, Wordpress, Joomla or API based CMS like Contentful).
Let the UX team be part of the Content Management planning process. A lot of the issues that tend to arise can be handled early in the process. Use the website wireframes to plan out a build, and to justify some of the implementation decisions that need to be made. Make quick prototypes for admin flow and screens. Focus on ease of use instead of ease of implementation. Create dashboards for frequently managed content. Involve non-dev team members for QA during the development process. A non technical set of eyes will see problems and ask questions that will resolve many potential issues before it ever becomes a problem for the client.
More than anything, it’s important to simply be aware that non-technical people will be managing and editing websites. Having an entire team on board will result in happier editors, and happier clients.