Building the uOttawa WCMS and website in Drupal 8

About

  • Role: Individual contributor
  • Product: Web Content management system (Drupal 8)
  • Team structure: Agile with developers and strategists (content design, business, change management)
  • Design: In-house after the agencies initial hand-off
  • Scale: Building a new web platform for the University of Ottawa
  • Impact:
    • Visitors: Over 50 million unique visitors, 75 million visits
    • Web contributors: Over 200
    • Business: Core business streams

Design system

Issue: Our team was building a new web platform without having a way to share knowledge about using the new product in a scalable and presentable manner.

Thought process: Design systems have been popularized as a standard for organizations. It was a great opportunity to showcase the product while using it as a way to educate and train employees.

Implementation: I pitched and championed the concept to have brand and design elements together as one system. After receiving by-in, I consolidated the content and devised the information architecture for it it. Following advice from my UX classes and the UX community, I suggested that we have a name for it and rallied resources to formalize our documentation. As a content strategy, I then categorized the content to be task and self-serve oriented for the users.

Impact: The design system was ready to be consulted as we launched the product. The community and trainers now have a centralized and reliable source of information to consult and improve their knowledge about the product and the brand. The information is more comprehensive. To encourage our new approach to increasing web contributor access, I ensured that our plain-language approach will make the content more accessible to non-technical users.

Approach to the copy: The voice and tone for the main external audience energetic, friendly, helpful, and direct. Since this design system is exclusive to staff, I approached the design with a more knowledgeable, guiding, and collegial voice. Since governance was loosely defined, apart a stern warning of bypassing specific rules, the essence is was to encourage a collaborative approach. Notably, I ensured that:

  • Acronyms were defined before being used
  • Platform versions were explicit since we were transitioning between three at a time (Drupal 7, 8, and 9).
  • Used approachable comparisons to explain complex concepts into simpler models
  • The system respected what we preached in terms of writing, layout, casing, hierarchy, logical topic themes, and design.

Explaining the concepts

To be able to explain the intended use and limitations of the design systems, I ensured we asked a lot of questions.

  • What is the use-case for this? Do we have another tool that can already respond to this need?
  • How do we see this interacting on different resolution/devices?
  • What are acceptable limitations?
  • How do we differentiate this (element) from others (visually, labelling, explanations, etc.)?
  • Is the wording ambiguous or clear?
  • Are we being consistent with our descriptions across the system?
  • How could we be explicit to describe this to users?

Here are some screenshots of the design system:

You can select an image, and then zoom-in to scrutinize the content (opens as a new tab).

The home page of the design system.
Explaining the higher levels of our Drupal components.
An example of some of the features available to the community within the design system. It includes purpose, content, and usage notes.

Micro-copy, and component standardization and design

Issue: Our agile environment assigned different developers to build features. This resulted in inconsistent terminology for the same product.

Thought process: If someone took ownership of the copy, we could have a product that is less confusing for the end-users as well as for future feature improvements. Since the components are modular and referenceable, it made it even more-so important that descriptions were both helping for anticipating and building a convention.

Action: I took the initiative to streamline and write the micro-copy for the platform contributors (editor to admins). I created a document and collaborated with developers to understand (and map) the dependencies and current functionalities. I then mapped out over 300 paragraphs fields (each can contain multiple labels, entity references, machine names, helper text, notes). As components were built, I would consult and advise on copy. I also translated these to French since the product is bilingual.

Impact: My document became a collaborative tool for keeping track of paragraphs, content types, and modules micro-copy. This contribution standardized our labelling and formalized our tool’s terminology. Well over 3300 excel data cells were considered for over 99 paragraph types (components).

Example of terminology and implementation

Micro-copy master document

Here’s a screenshot of the micro-copy document and tracker I made for the new uOttawa Drupal platform.

A screenshot of the 300+ paragraph micro-copy document.
Micro-copy mapping and translations (English and French).

Implemented micro-copy in user interface

It was quite rewarding to see the micro-copy implemented after the standardization of component names and terminology.

The first example shows sections that are clearly identified and hint at what kind of content they contain.

The second example shows the paragraph displayed in a new order: alphabetically (instead of by creation date/weight). This would save time for users. It was a pain-point in the previous CMS build.

I also worked on naming the templates by their function. The templates with “page” distinguished the page templates from other content types (such as alerts).

Once again, we notice that the templates are now alpha-sorted ❤️.

Nested fields were by far the most confusing and time-consuming UX writing decisions.

I led the discussion with contributors and read the (scarce) design agency documentation to understand the dependencies. I even had to experiment building by inserting copy to see how content would be displayed.

For all fields that were related, I kept the thematic names within them since the user interface colours and display can be a bit difficult to distinguish quickly.

In this example, the main component is Quick links blocks, and the child-components contain Quick links.

Example of issues before standardization

In teal, the casing was inconsistent (intro text and contact methods).

In red, the acronyms wouldn’t be understood by administrative staff web content contributors. The term Call to action (CTA) was a coded by the design agency without considering the platform’s end-user in mind.

In purple there are is a mismatch between the concepts of a main component and the concept of a field (they were both components).

In yellow an example of inconsistency across components.


Heuristics, usability, user interface (UI), user experience design (UXD), and quality assurance (QA)

Issue: An agency shipped initial designs of the platform, another agency built functionalities, and the remainder of components were designed in-house. This resulted in an alpha product that had never been tested prior to client use.

Thought process: How are we supposed to explain specifications and features if they haven’t entirely been defined and tested.

Action: Using Tognazzini’s First Principles of Interaction Design (Revised & Expanded), I initiated the heuristics of the product before our initial launch.

I introduced the concept of heuristics to my team as we were discovering issues and not cataloguing them in an unorganized way. By involving my team and formalizing the task, we were able to identify many issues. These were sorted by critical, major, and minor, within 19 themes.

Impact: The work resulted in a neatly organized 67 page document of identified issues with screenshots and descriptions. The issues were incorporated in our agile process sprints. Since I had identified who found which issues, it made it much easier for the developers in our team to know who to contact for gathering additional information and context when they were working on the fixes. The process of bug-reporting and has since become streamlined and is part of continual improvement.

The instructions I created to guide the team to grade the severity of issues. This helped the developers know which issue to fix first.

Content design and Information architecture

Tool: Flowmapp and Drupal

Challenge: The project wanted to hide the administrative content from other audiences, but we did not have a good WCMS intranet.

Actions:

  • I pitched a content strategy to leadership for aligning the project with the vision (it was approved). I was then the lead for the initiative.
  • I re-organized the university’s WCMS content design into a task-based approach. The previous structure was content-owner structure (user-centric design).
  • A lot of change-management and stakeholder discussions were required for information gathering and ensuring that no clients were forgotten in the top-level framework.

Impact: Administrative content was hidden from the public to increase the SEO results for our core business objectives.

A fresh message once user permission rules were implemented. Staff that are logged in can access the intranet.

Redirects and content strategies were deployed to ensure minimal operations disruption.