Designers, developers, and marketers all have their preference for content management systems. At Alloy, Drupal was found to be the most powerful platform to extend beyond its core system flexibly and was our main product. I owned the experience of this product, conducting a series of interviews, research, and audits to improve the user experience and interface of our customized Drupal 8 product. I had about six months on this project, though it ran in parallel with other projects.
Personas are essential for developing a product because they help you and your team identify your ideal users and customers. Much of the Alloy team, including myself, had been working with Drupal for years. Usability that might feel innate to me could easily be vexing for our clients, and the average user. By creating a set of personas, I was able to put my assumptions aside and focus on user needs. During this process, we came up with four personas.
After establishing a set of relevant user personas, I worked with my team to set up a series of user interviews with our ideal clients and our internal marketing team. In these interviews, I observed and recorded how people interacted with the customized Drupal CMS we had in place. From these interviews, I was able to gather information about the most relevant pain points for each persona type and find where overlapping issues were occurring. With this information, our team could understand where to start and what how to best improve.
The Alloy team was aware of issues with the asset manager, but we confirmed this during the user interviews. Many of the users, including our team, struggled with using the asset manager. The issues mentioned most were:
• Slow uploading/loading
• No search functionality
• A complicated structure of folders for assets
• Errors when uploading assets with confusing error messages
• Problems with customizing images within the manager (alt text, size, etc.)
• No way to preview the assets while they are listed (assets must be selected to show preview)
Regular Tasks v. Irregular Tasks
I found that users were most familiar with tasks they completed daily, such as adding/editing pages and blog posts (nodes) and interacting with the WYSIWYG editor. They also struggled with adding/editing anything outside of nodes. Our users were unlikely to simplify their work with custom elements of the nodes and CMS. They were also likely to ignore any features that they had never used before, even if it would help to use them. When prompted, users would mention a fear around using features they weren’t familiar with because they didn’t want to “mess up” anything.
Additionally, our users felt that if they wanted to learn more about what a 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 the content on a text editor, such as Microsoft Word, and then paste them into the CMS when they wanted to publish them, even though the CMS already could save nodes without publishing.
At the end of these interviews, I would show our users the existing features and how they worked to understand if they found value in them. The tested 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 future?”
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 specific tasks, adding unnecessary steps into their workflow.
Duplicative Tasks / Content Authoring
Much of Alloy’s internal concern around the CMS was in regards to performing repetitive 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 tens to hundreds of different types of pages on their websites. Each node they created was custom built when reusing section types and duplicating nodes could have saved them hours of work. That means that our users could have been performing duplicative tasks manually every time they had 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 steps. Users also indicated a confusion around sections within a node. Users didn’t know what parts were added to a page, how those parts looked, and how they behaved.
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 will enable users to section out the backend of the page with the live view (examples: Hubspot, Craft). Alloy’s setup included a “maximize” view, which changed the view of the content so that users can see it more as it will appear live. However, many of our users either did not know that “maximize” performed this task or found it to be inflexible and “buggy.” Another issue with this was that it only showed parts of the live view, so it did not provide a full and accurate preview.
As I’ve mentioned, there were rich features provided on Alloy’s custom Drupal 7 setup that users didn’t know. Across the board, users indicated a concern about not using the CMS to the full extent that they could. While we provided “Help” documentation for our users, they often didn’t use it. 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.
Audit & Comparative Analysis
The next step of our research was to audit all of the existing authoring functionality available in our content management system. By creating a solid list of current functions, we could structure our work going forward into user stories, and group those stories into epics as they collectively expanded. These user stories helped us build a narrative around our redesign process, guide us through our users’ flows, and help us understand what functions we needed to improve an expand.
This audit also was relevant to the comparative analysis. We used the list of high-level features included to understand what items we would need to consider in our analysis. While other CMSs provided different solutions than the ones that might have worked best for our users, it was important for our team to generate ideas on how to solve various usability issues, and to know where we stood about similar products. To document this collaboratively, we uploaded screenshots of other CMS patterns into an InVision board where annotated them about any observations we make. For this task, we selected platforms with user experiences we appreciated to review: WordPress, Wix, Squarespace, Hubspot, Medium, Craft.
After having the user research in place, my team then went into the design phase of the project. We understood the major qualms that our users experienced with our customized Drupal 7 Content Management System, from there, we could see where the same issues would occur in the out-of-the-box Drupal 8 CMS. We started by redesigning visual elements of the out-of-the-box Drupal 8 design to set up a strong base for updates going forward. With this visual redesign and established design system, we could build wireframes and structure without having to do high-fidelity mocks for every update. Drupal 8 out-of-the-box had a challenging user experience, with an even more complicated user interface to support it, so we started from the ground up.
Many CMSs take a minimal approach when it comes to type. Old favorites, Helvetica and Arial, are standard on content management systems. Some, like Squarespace, will add other fonts to create a sense of style and help with hierarchy. We wanted our typeface to be more stylized and unique, but the typeface we wanted still had to be:
• Legible and capable of scaling well
• Available with a variety of weights
• Stylized enough to be unique, but not so unusual to be distracting
With these elements in mind, our team decided on the Google Font called Montserrat. Montserrat is an urban typeface inspired by the early 20th century posters and signs in the traditional Montserrat neighborhood of Buenos Aires. This typeface stands out while still being subtle enough not to distract users as they navigate the CMS. Montserrat is highly flexible, with 18 styles to choose from and two sister fonts.
Color palettes applied to content management systems tend to vary more than fonts. WordPress used various shades of blue (though they offered customized themes), Squarespace was mostly black and white, and Craft used cool grays and desaturated warm colors. With our colors, it was important to provide a set of options that, when applied, helped to drive the user’s journey. Because of this, we chose colors with high contrast and visibility. These colors, when applied to buttons and fonts, provide clear direction to users navigating the CMS.
It was also essential to provide a broad set of colors and differentiate between primary colors and secondary colors. This would help our developers when they need colors to differentiate in unique situations. For example, a critical alert should be different from the primary colors and give a sense of awareness and possibly urgency.
Our selection included some of the colors of Alloy’s parent brand, specifically the bright blue and grassy green. In addition to these, we added several secondary colors, as well as a set of cool grays.
Icons play a crucial role in content management systems. They are often are paired with actionable items, so using them can help users scan the interface and find elements that they need to move forward. Over time, they can also help users learn page layouts, which helps them complete tasks quicker. Icons should rarely be used alone in a CMS, more often than not, they should be paired with a label to help communicate the associated action.
For Alloy Beryllium’s icon sets, we established three styles: icons to be used at large sizes (mostly for adding new content), icons to be used at medium sizes, and icons to be used at small sizes. At large and medium sizes, icons have an outline effect rather than a fill effect. At small scales, we chose to have icons filled in to make them easier to see. These icon sets will not only serve users as they navigate through their tasks but will also emphasize the new style of Alloy’s Drupal experience manager.
“We’re not designing pages, we’re designing systems of components.” — Stephen Hay
When designing apps and products, it is essential to consider components. Components help build the visual system, from the “atoms” of the design up to the pages. By establishing elements and making them into fully-fledged systems, we can see a cohesive whole and a collection of parts at the same time. This creates a strong hierarchy that can be carried through to new designs.
With Drupal 8's basic system, it is easy for users to get lost in the navigation. It was important for us to create a UI with a strong emphasis on hierarchy to help users when navigating complex management systems.
While our data and interviews showed that many of our users were unlikely to use the content management system on viewports that were less than 1024px wide, we didn’t have an excellent experience for smaller sizes in the first place. I would hypothesize, even now, that most users don’t choose to manage content via a mobile device. But to take away a user’s ability to do something on a small screen just because of this assumption would be biased. Even though our data showed it to be unlikely that data could have been skewed because users wouldn’t be able to use small screens in the first place.
Additionally, there could be a situation, even if it were uncommon, that a user would prefer or even need a smaller screen to work. Having a product function on all screen sizes is about building an inclusive experience, and ideally, all products would perform as such. For all of these reasons, I set out to create a set of adaptive designs to provide a secure CMS experience regardless of device or screen size.
Since we learned that users were struggling with a lack of templatization, we opted to provide users with a simple set of template content options, adding additional options for customers with specific needs.
Many of the findings from user interviews had yet to be implemented at the time of this phase wrapping. We had made much progress from where we started, but it is important to remember that a product is never “complete.” Iterative growth and adjustments are needed for all types of products, even ones from major companies. I learned about product design in this project, specifically in terms of scoping and completing items determined by impact/difficulty. Regardless, we were able to make a positive impact in this phase. Customers who had the opportunity to preview this new version would always ask, “when can we get this? and “how much does this cost?”