It’s no secret that our team loves Drupal.

Designers, developers, and marketers all have their preference on CMSs, but we have found Drupal to be a powerful platform that can flexibly extend beyond its core system, making it exceptionally capable of building better user experience.

One of the most critical aspects of our work with Drupal is that we have focused on creating a customized platform that provides a rich authoring experience and sophisticated solutions for our users. The release of Drupal 8 became an opportunity for us to do a thorough investigation on ways to improve our core offerings, experience, and interface. In this post, we'll discuss how we researched our content management system’s user experience, and how we established the next steps of our strategy to improve our custom Drupal 8 platform.

Goals

Reworking Drupal 8’s setup began with discussing and establishing our internal goals. Our team was excited to take an in-depth look at what we could improve, but we had to prove and disprove our own hypotheses before we began making changes.

Our research and strategy included three steps:

1. Create user personas to understand our core user base and their unique needs
2. Conduct contextual inquiries with current users on the Drupal 7 platform
3. Audit all of our current authoring tools and conduct a comparative analysis of other platforms

1. User Personas

The importance of personas can never be overstated when working on improving any product. Much of our team has been working with Drupal for years, and we've come to understand the intricacies of the structure and design quite well. Usability that might feel innate to our team can very easily be vexing for our users. By creating a set of personas, we've worked on putting our own assumptions aside and focusing on our clients’ needs. During this process, we came up with four personas.

It is important to emphasize that there are other types of users who use our Drupal setup, but these personas focus on our power users, those who use the more advanced features of the platform. We included one persona based on a new hire because our new hires tend to come in with their own ideas of how a CMS should work (I know I did). The same logic applies to new hires within our clients’ companies. The importance of including a new hire here is to focus on how someone who has never worked with the CMS, but needs to quickly acclimate, figures out how to do so without errors.

With these personas, our team was able to set aside our own experiences and establish what types of user we would need to talk to during the interview process.

2. Contextual Inquiry

Asset Manager

Our team has been highly aware of issues with our current asset manager, but these issues were confirmed during these interviews. Many of our current users, including our own team, struggle with using the asset manager. Issues with the asset manager include:

• Slow uploading/loading

• No search functionality

• A complicated structure of folders for assets

• Errors when uploading assets with confusing error messages

• Issues with customizing images within the manager (alt text, size, etc.)

• No way to preview the assets while they are being listed (assets must be selected to show preview)

There were more issues involved with the asset manager, but these were the ones most discussed during the interview process.

Regular Tasks v. Irregular Tasks

We found that our users are quite familiar with the things they interact with daily, such as adding pages, editing pages, adding blog posts and etc. This is surprising of course, as most users on any platform or application become mostly familiar with the tasks they need to perform regularly. However, they struggle with adding/editing anything outside of nodes and are unlikely to use some of the more custom elements of the nodes and CMS to simplify their work. Users were likely to ignore any features that they had never used before, even if it would help to use them. Users, when prompted, would mention a fear around using features they weren’t familiar with because they didn’t want to mess up anything. Furthermore, our users felt that if they wanted to learn more about what this feature was, they wouldn’t know where to do so. One example of this was the ability to save a node without publishing it. Clients were likely to edit content on their text editor and then paste them into the CMS when they wanted to publish them, even though we have the ability to save nodes without publishing in the system.

At later points in these interviews, I sometimes would show our users these features and how they worked to understand if they found value in them. Our users did like these types of features and wished they had known about them sooner, often inquiring “where would I learn more about this?”

In the same line of thought, throughout the interview process, I found that our interviewees would complain about issues that we already have solutions for (example: revision history, searching for content, filtering content), but would not know of the fixes. Users often found roundabout ways to complete certain tasks, adding unnecessary steps into their workflow.

Duplicative Tasks

Much of our internal concern around the current CMS is in regards to performing repeated tasks. When I say this, I mean creating content that is duplicative of existing content. In our interviews, we found that our users had large scales of content within their sites. Often our users would have hundreds of different types of content on their sites. The main issue with this inherently is that many of the pages have repeating content and that our users do not currently have a simple way of reusing section types and duplicating nodes. That means that our users could be performing duplicative tasks manually every time they have to create similar pages. Our clients voiced an interest in the ability to template and duplicate existing nodes/sections so that they may use that template in the future to create a new node without having to perform a set of tedious manual steps.

Preview

One issue that many people encounter with most CMSs is knowing how the content they are entering will look when published. Some CMSs have solved this problem by allowing users to edit the content in context (examples: Wix, Squarespace), others provide a “live preview” option that allows users to section out the backend of the page with the live view (examples: Hubspot, Craft). Currently, our setup includes a “maximize” view, which changes the view of the content so that users can see it more like it will appear live. However, many of our users either do not know that “maximize” performs this task, or do not find it flexible and often found it “buggy.” Another issue with this current function is that it only shows certain parts of the live view, but not others, so the effectiveness of this feature is currently limited.

Unused Features

As I've mentioned, there are rich features we provide on our Drupal 7 setup that this set of users were not aware of. Across the board, our users indicated a concern about not using the CMS to the full extent that they could. While we provide “Help” documentation for our users, they didn't use it much in these cases. Users that had explored the “Help” page found it to be unhelpful to their learning. Furthermore, users mentioned a concern around training new content managers and employees on the CMS with only their understanding of the functionality rather than a formalized process or set of helpful content.

Again, this is a high-level look at the issues our users currently experience with the CMS. It's not intended to prescribe solutions, and it certainly does not entirely handle the issue of more specific use cases. The interviews we conducted revealed issues to us that we had not considered, as well as some that we were already quite aware of. However, having confirmed what we need to improve we can now move forward towards defining solutions.

3. Audit & Comparative Analysis

The next step of our research was to audit all of the existing authoring functionality available in our content management system. We did this to build our set of tasks moving forward. By creating a solid list of current functions we can structure our work going forward into user stories, and group those stories into epics as they collectively expand. These user stories will help us build a narrative around our redesign process, guide us through our users’ flows, and help us understand what functions we can improve as well as build on. For example, one feature of our CMS is the asset manager. Through this process, we documented all of the functionality currently available through our asset manager:

• Asset manager (accessing assets from nodes)

  • Upload

    • From Computer

    • From URL

  • Delete

  • Edit

    • URL

    • Title

    • Caption

    • Alt text

    • Description

    • Image size

    • Border

    • Spacing

    • Create thumbnails

  • Add directory folder

This is just one of many documented features we've put together.

This audit also was relevant to the comparative analysis we conducted. We used the list of high-level features we currently include to understand what items we would need to consider in our analysis. A comparative analysis is the review of applications or websites that are not necessarily in direct competition with a product but may have similar processes or interface elements that are worth reviewing. While other CMSs provide different solutions than the ones that might work best for our users, it is important to understand other trends because it helps our team with generating ideas on how to solve various usability issues, and to know where we stand in reference to similar products. To document this in a collaborative way, we uploaded screenshots of other CMS patterns into an InVision board where can annotate them about any observations we make. For this task, we selected a variety of platforms, some more specifically CMSs, others not so much. Here are some we considered:

• WordPress

• Wix

• Squarespace

• Hubspot

• Medium

• Craft

While we've documented a very large chunk of what we need to have for Drupal 8’s setup, we'll continue to expand the audit as well as our comparative analysis as we dive further into specific user needs. These processes have guided our team into the next phases of our work and given us a lot of inspiration moving forward.

Summary

Our customized Drupal content management system is something our team is proud of, but we are also excited to begin reworking Drupal 8 so that we can continue to deliver a fantastic authoring experience. Certainly, this process has shined a light onto some of the problems we need to think through. Improving our product will always be a never ending story, but by continuing our research we'll continue to grow as our users do. By gathering this research we can now move forward with the next steps of customizing and optimizing Drupal 8. At the risk of exposing myself as a geek, I can happily say I enjoyed writing this post just as much as I enjoyed researching our product.

Still reading? Head on over to our next post about the Drupal 8 customization process — giving Drupal 8 a facelift with a complete UI overhaul.