IMPROVING THE DRUPAL 8 EDITORIAL WORKBENCH

 

In 2019, I collaborated with two other designers to research and identify improvements for the City of Boston’s Drupal 8 Workbench.

Boston’s website content is updated and maintained by more than 200 employees with a wide range of experience spread across departments. Drupal is the content management system employees use to edit and create content for the website.

The Department of Innovation and Technology (DoIT) wanted to make the experience for those 200 employees working on the back-end of the website just as intuitive, accessible, and enjoyable as the front end is for website visitors.

final research & recommendations report (pdf)

ACTIVITIES

 

For this project, I collaborated with two other UX designers. Together we conducted research and developed a design strategy to address three key issue areas. We then created an interactive digital prototype of the Drupal 8 Workbench to demonstrate and test our solutions.

 

 

My Responsibilities

Project Management
Research Protocol
User Interviews
Contextual Inquiry
Proto-personae
Task Analysis
UX Strategy & Ideation
Research & Recommendations Report
Usability Testing
Presentation Decks

 

Tools

Miro
Axure
Sketch

Time

3 weeks

Link to Luca Iacono-Stewart's Website

Luca Iaconi-Stewart

Morgan von Prelle Pecelli

 

RESEARCH

 

During the first weekend of project DoIT was migrating from Drupal 7 to Drupal 8 and implementing some improvements they had already planned for the workbench. This meant that users, who we began interviewing during week 2, were using Drupal 8 for the first time.

We started our research by familiarizing ourselves with Drupal and conducting some comparative research reviewing the interfaces and heuristics for Drupal 7 and 8 as well as the Google Suite, an editing tool many of our users also used. Additionally, we reviewed the editorial workbenches in WordPress and Wix, two popular consumer-facing content management systems. Then we dove into user interviews and contextual inquiry.

Goals of User Research

Speak to users from a variety of City departments, with a range of experience using the Drupal workbench.

Understand user pain points with both older Drupal 7 and new Drupal 8 workbench.

Identify common errors and inefficiencies in workflows.

Collect user suggestions about what might make the workbench more enjoyable and intuitive to use.

User Research Conducted

Focus Group (5)

Interviews (13)

Contextual Inquiry

Demo Activities & Issues (7)
Full Process Demonstration (3 + 1 Review/Approve)

We gleaned 327 comments from our conversations with users. We each created our own affinity maps of the findings.

From the full-process demonstrations, I built out three task flows, to help us identify common formal errors, confusion points, time spent wandering in search of tools they need, and inefficiencies in the workflows.

We reviewed each other’s affinity maps, discussed our observations, and then used a kind of meta-affinity mapping technique to identify and prioritize issues according to two key criteria:

Most severe impact to workflow & confusion

Affecting widest number of users

SUMMARY FINDINGS

 

WHAT WE HEARD

Navigation

I want to edit this page, but I can’t figure out how to get to the editor from here.

I am confused about how things are named and described.

I struggle to find what I am looking for.

 

Moderation & Preview

The new moderation tools seem helpful, but I’m still a little confused by them.

I want to be able to see and compare revisions, but this way is confusing me.

I don’t trust Preview.

 

Errors & Help

Help me avoid errors. Tell me the requirements.

I want easier access to the DoIT user guide.

I rely on DoIT staff when I can’t help myself.

I need more support to ensure my content is truly accessible to all of our users.

WHAT WE OBSERVED

Navigation

Navigating the live site to pages they want to work on.

Sharing URLs, help requests, and status updates via email in order to collaborate.

Hesitating and hovering over menu items.

Clicking into things and then clicking away because it wasn’t what they expected or were really looking for.

 

Moderation & Preview

Losing work because they hadn’t saved before clicking preview.

Being unable to locate their drafts.

Uncertain about what to do within the moderation area and sidebar menu.

Uncertain about what would happen when they change a page status.

 

Errors & Help

Triggering errors because they had not seen that a field was required.

Only realizing their copy was too long for a component after they were in preview.

Skipping accessibility-related fields because they are not required by system.

RESULTING PROBLEM STATEMENTS

Business Problem
DoIT needs to improve the Drupal Workbench experience for content producers and editors so that their colleagues can easily and independently create content for Boston.gov.

User Problem
City of Boston employees producing and editing content for Boston.gov are struggling to use the Drupal Workbench and often have to rely directly on DoIT staff because it is inefficient and unintuitive.

 

Specifically, City workbench users need a way to more easily:

Navigate because they are struggling to find, edit, and submit their content.

Understand and imagine what options are available or required because the Workbench uses unintuitive, unmemorable, and unrecognizable naming conventions.

Access help resources because they currently have to leave the Workbench or rely on DoIT staff to do so.

STRATEGY

 

Recommendations

1. Reorganize primary & secondary navigation, create a navigable user home page, and rename key menu items.

2. Revise “Create Content” descriptions & provide access to examples and apply the same framework to “Components”.

3. Consistently support error avoidance and accessibility requirements.

 

We hypothesized that by making these changes, we would make the workbench more intuitive to use and support user decision-making, increasing user confidence and reducing the frequency with which users reached out to the DoIT team for help

PRIMARY NAVIGATION – UPPER RIBBONS

 

With the understanding that navigation could be tailored somewhat based on user type, we made changes to the main navigation menu, removing features most content editors don’t use and including the tools that they most commonly accessed. We also added a notifications alert to the upper ribbon.

We added a second ribbon that provided the user with clear information about the page, its status, type, name, and most recent edit history, as well as the two most important actions a user could do to this type of page – i.e., in the case of a “Draft” page, to edit it or submit it for review.

 

 

We removed the “Draft” overlay from the public page’s main navigation in part because we noticed users trying to click on the word draft and instead activating the live page’s menu. Making the status its own ribbon, and changing the colors used to indicate that status, also allowed us to meet basic accessibility standards.

SECONDARY NAVIGATION – SIDEBAR MENUS

 

D8 introduced two new secondary navigation tools: Tasks and Moderation. When a user was in preview mode, clicking on “Tasks” in the main menu opened a sidebar menu on the righthand side of the screen. When a user was editing a page, Moderation, was a static menu on the righthand side of the screen. Users appreciated the new tools, but had some issues using them.

 

 

We suggested tidying these panels up, moving some items from the Tasks menu into Moderation, and creating more context specific versions of the menus to make decision-making even simpler for users. We also recommended giving users the ability to discard a draft and to cancel a submission while it was still in “pending review” status.

USER HOME PAGE – MY WORKBENCH

 

After logging in users were taken to a page that showed them three pieces of information — how many years/months they had been users, their user code, and their language code. Otherwise this landing page had no actionable items. We observed users immediately clicking away from this page to the “My Workbench” page or to somewhere else in the workbench.

A number of users expressed frustration that the “My Workbench” page wasn’t more useful to them. Many just avoided “My Workbench” altogether by using their browser’s search function to find the page they wanted to edit on Boston.gov and then changing the URL’s prefix to take them into the editor’s version of that page. 

 

 

We hypothesized that by replacing the landing page as well as “My Workbench” with a navigable Dashboard, we might limit the number of unnecessary pages users find themselves on, provide them with immediate access to key pages and frequently-used tools, and reduce their frustration.

LAYOUT & COMPONENT EXAMPLES

 

Whether they were frequent or infrequent users, all users expressed uncertainty when trying to choose which page layout or component type to use. Users told us that they often referred back to the admin guide for more illustrative descriptions and examples.

 

 

We recommended revising the descriptive text as well as adding an accordion that would drop down to reveal visual examples and spec requirements for the various layouts. We suggested that a similar format could be created for “Components” as well, to aid user decision-making when building new page sections.

ERRORS & ACCESSIBILITY

 

While text limits were indicated on some fields, they were not on all fields. Additionally, there was no warning to users when they had exceeded a text limit, leading to cut off text and user frustration when they got to previewing their page. We recommended that the workbench always clearly state the limit for any text field, show users a countdown as they type, and turn the box red if they have exceeded the limit.

The image upload process also presented some opportunities for improvement. In our task flows, we observed that once an image was uploaded, something about the layout of the subsequent screen seemed to encourage users to skip the required “Name” field. We rearranged the layout to prioritize completing the Image Name as well as Alternative Text fields before hitting that final “Upload” button.

Finally, we also made more general recommendations to improve color contrast, visibility of alerts, and recognizability of links to improve the accessibility of the Workbench itself.

Comparison of current task flow for image upload with current pop-up layout that encourages users to skip required fields and our recommendation which we hypothesize would support users better.

PROTOTYPE & TEST

 

Before completing the project we were able to conduct some usability testing and demos to gather feedback from users as well as DoIT staff and developers.

Usability Testing (4)

Demo to DoIT Project Team (4)

Demo to DoIT staff including developers & designers as well as research participants (15+)

 

Based on the Usability Test Findings we made a number of minor tweaks and changes, as well as more significant iterations to the primary navigation, dashboard page, and visual examples provided on the “Content” options page.

USABILITY TEST FINDINGS

 

Consistent positive feedback

This is easier to navigate than what I am used to.

I would use “View Example” of the content layouts.

Moderation seems simpler and easier to get through.

Users quickly and easily navigating to where they needed to go.

User excitement — “ooo” and “ahs”, coupled with body language that suggested sudden positive interest, such as leaning into the screen or sitting up attentively.

 

 

Consistent “close, but not quite” feedback

I want to see examples of published pages as well as the mockup examples.

Conflicting feedback

I like this dashboard.
I want more/different information in this dashboard.

I want the edit options in a center pop-up. 
I want the edit options in a sidebar.

REFLECTIONS

 

This project offered an intriguing puzzle – how can you make a content management system as delightful to use as the public website it is feeding into? With only three weeks to complete it, we were only able to scratch the surface of what might be done.

As a team Julia, Luca, and I were able to work fluidly each bringing our various expertise to the table in a harmonious balance. It was also a joy to work with the City of Boston’s staff both on the DoIT team as well as those we interviewed and met with for testing from other departments. Their curiosity, dedication, and desire to create positive impacts in their colleagues and constituents’ lives is palpable.

Looking back on the process, if I had one more week to dive deeper into the project, I’d want to dig into quantitative data about user behaviors. Which features, content types, and components are really the most frequently used? What parts of the guidebook do users access the most? Which content elements are used so frequently that creating templates or storing the data would be valuable? How many users pull images from the “image library”? What error messages do users trigger most frequently?

I particularly enjoyed getting into the weeds of developing the Task Flows. We prioritized changing the layout of the “Image Upload” page because we observed in the Blog Post that in that pop-up’s current layout it encourages users to trigger the same error each time they upload a new image.

 

 

Other tiny and simple to fix design issues like this throughout the site might be discoverable by looking at which error messages are being triggered and then observing users as they try to complete the task to see why they are triggering that error. And the fewer easily avoidable error messages a user is triggering, the more confident they will feel in their ability to use the tool.

Another aspect of the project that we weren’t able to really dive into was “rewards” or ways to encourage users by giving them those little dopamine bursts we get from checking items off a to do list, getting a badge to celebrate an accomplishment, or watching our page hits go up.

We had a discussion with one user about including department page stats on the user’s Dashboard, but without the knowledge necessary to interpret that data and respond to it, they agreed in the end it would just be some numbers that go up and down. The reward that data might provide would quickly become meaningless, if not frustrating.

In the end, the Notifications icon we recommended for the Primary Navigation is a kind of minimum viable reward feature – a starting place for further evolution. In addition to useful alerts, the reward it provides is confirmation that a user’s page or edit has been published. In other words, it proclaims successful completion of their task. A simple reward, but one which instills confidence in the user — in the content management system, as well as in their ability to use navigate and use it.