Product and content design

Under construction. Demo available upon request.

  • Product: Web Content management system (Drupal 8)
  • Team structure: Agile with developers and strategists (content design, business, change management)
  • Design: In-house after agencies initial hand-off
  • Scale: Building the new web platform for the University of Ottawa (full-depth)
  • Total 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 had to ensure 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 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 explicitly describing this to users? (This one was usually followed by silence.)

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).

Visual example of terminology and implementation

A screenshot of the micro-copy document for the new uOttawa Drupal platform.

A screenshot of the 300+ paragraph micro-copy document.

Examples of the micro-copy that was implemented following the standardization of component names and terminology:

Example of before standardization:

In teal, the casing was inconsistent, in red, the acronyms wouldn’t be understood by occasional web contributors, in purple there are is a mismatch between the concepts of a main component and the concept of a field (they were both components), and in yellow an example of inconsistency across components.

An example of limited information about components at handoff.

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

Impact: A task-based approach to intranet content design instead of the previous content-owner structure (user-centric design).

(coming soon)