Content Builder

Context

Gate Three is the internal construction management platform used for every construction project at EllisDon. It is comprised of multiple modules and used by different departments throughout the project lifecyle.

the problem

The traditional methods of using Excel, Word, and paper to collect project information meant missed opportunities for the business to aggregate and use data. The product team had already translated some of the most essential documents into a web format but there was a need to make this process more sustainable. Instead of the product team developing every piece of content, we wanted to put document management into the hands of users.

The Users

CONTENT CREATORS

Executives in charge of managing documents specific to their business area. These business experts have a lot on their plates so efficiency was key. Since they would receive training, it was an opportunity to slowly introduce more advanced functions while supporting the transition from creating documents in Excel and Word.

CONTENT CONSUMERS

The users who will access the documents made by the content creators. Although the content creators decide how to put documents together, the building blocks of the documents and the experience around consuming the content were within my design scope.

Business Goals

Save development time by allowing users to create and modify content

Streamline data collection to make it usable

Design Goals

Prioritize creation efficiency

Make complex back end functions visible in a simple way

Progressively introduce more advanced functions

My Process

Creating a Foundation

Mapping the big picture

Because of the scope of this project, I wanted to get a handle on the big picture before diving into more detail. I assessed the requirements with the PM, broke them into functional areas, and mapped them onto our existing global elements (e.g. the sidebar and the toolbar). Creating this foundation provided a framework for understanding each part of the product and its relationships to the whole.

understanding the current state

I also wanted to gain an understanding of how documents were currently created and used. I explored documents across each of the business areas to understand their form and function. This resulted in a list of every element (e.g. text fields, dropdowns, signature fields) being used and notes on how they functioned (e.g. a dropdown answer toggles the visibility of another field). This was valuable in understanding what the product needed to accomplish in terms of functionality.

Research Activities

Card Sorting

With the complete list of elements in hand, I created a card sorting activity using Optimal Workshop to test how people group elements. I kept the activity open, allowing users to create their own categories. In combination with my understanding of the most frequently used elements, I used the results to group and order elements on the sidebar to ensure users could add them to documents as intuitively as possible.

MATCHING USERS' MENTAL MODEL

Another challenge was understanding how users thought about the process of document iteration. I came up with two possible models. Each had implications for the dashboard, the content area, and the history toolbar so we really needed to understand get this right.

Based on my experience with other tools, I had a bias toward one option. After hearing from the users, however, it was clear the ‘making copies to edit’ model was the better choice for them. In practicality, this changed very little in the back-end. It was a matter of matching the interface with the way users think about the process of document versioning.

Design Highlights

spreading out cognitive load

To create a new document template, the first step is completing the Create New modal. A document requires the collection of metadata to house it within the content ecosystem. I received a request to incorporate the metadata collection into this first step and even went through iterations trying to fit every piece into the modal.

Stepping back to focus on the users, however, I realized it didn’t make sense to front-load this process. I hypothesized that users would want to get right into the creation process with the least amount of friction possible.

I was able to distill the modal to just the essentials and convinced the stakeholders that the metadata could be incorporated into a later stage of the process when the user was already invested and ready to publish.

History tool

Another avenue of the creation process I looked at was how users could explore different ideas within versions. Initially, I looked at other applications that used branching and merging. Based on user feedback, however, those concepts added too much complexity.

Instead, I decided to leverage the history toolbar and took a cue from Photoshop by adding a “snapshots” function so users can travel between specific points in their editing process. To create the history toolbar, I standardized action types and time increments so the tool would be scalable across the entire platform.

using colour for context

I knew I needed to simplify the complex back-end connections involved in creating form conditions. I considered adding conditions as another “mode” similar to the Settings page because I worried the toolbar area was too small to handle the complexity of this function. The more I thought about the users’ needs, however, the clearer it became that they would need the context of the content area in order to visualize the connections between elements on the screen.

I created visual cues through colour to make it clearer which elements were triggers and which were actions and took advantage of the content area by utilizing a targeted selection instead of dropdown lists to help make this step more efficient.