I was tasked with improving the user experience and interface of Alloy Magnetic's customized Drupal 8 product. I conducted a series of interviews, research, and audits to understand the flaws of the old system. After establishing the user experience needs, I lead efforts to build a visual system and user interface for the new system.
The importance of personas can never be overstated when working on improving a product. 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 own 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 issues.
The Alloy team was aware of issues with the asset manager, but this was confirmed during the user interviews. Many of the users, including our own team, struggled with using the asset manager. The issues mentioned most were:
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)
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 and were 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. When prompted, users 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 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 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 had the ability to 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 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 / Content Authoring
Much of Alloy’s internal concern around the CMS was 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 tens to hundreds of different types of pages on their sites. 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. We found our users were confused about what sections were being added to a page, how those sections 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 allows 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 like 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 were not aware of. 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 as well as build on.
This audit also was relevant to the comparative analysis that was conducted. 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 generate ideas on how to solve various usability issues, and to know where we stood in reference to similar products. To document this in a collaborative way, 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 component libraries, we could build wireframes and structure without having to do high-fidelity mocks for every update. Drupal 8 out-of-the-box was a difficult user experience, with an even more difficult 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 common 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 unique 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 to not 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 large 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, an important alert should be clearly different than 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 included several secondary colors, as well as a set of cool grays.
Icons play a key role in content management systems. Often icons 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 sizes, icons have been filled since small icons do not generally fair well as outlines. 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 important to consider components. Components help build the visual system, from the “atoms” of the design all the way up to the pages. By establishing components and building them into fully fledged systems, we are able to see a cohesive whole and a collection of parts at the same time. This establishes 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 (CMS) on devices that were less than 1024px wide, we didn’t have a great experience for smaller sizes in the first place. I set out to create a set of adaptive designs to provide a strong CMS experience regardless of device.