This is the story of how workflows that enable thousands of knowledge workers to produce mission-critical content everyday were re-engineered from a complicated monstrosity to something simple and easy to work with.

About the project

The backbone of any well managed content lifecycle are workflows that enable a piece of content to move between different stages while smoothly regulating prerequisites, such as assignees and permissible actions. The original Quark Publishing Platform, a then 15+ year old Multi-Channel Publishing System for large-scale enterprises was the powerhouse relied upon by hundreds of thousands of highly skilled knowledge workers to plan, produce and publish mission-critical content that drives their business forward.

As Quark went through a ground-up overhaul of QPP into a modern, scalable next-generation solution called Content Enablement Platform, one of my major responsibilities was the re-imagined Workflows Designer.

Problem

Configuring a well-considered workflow for a particular content type or publication is inherently a complex task. However, after speaking with the Customer Success team as well as the head of Engineering and the head of Product Management to better understand the issue, it became apparent that even experienced system administrators who had been onboarded and understood the mechanics of the product had trouble configuring workflows due to an unintuitive user interface.

Problem 1: Workflow status feels disconnected from everything else

There was a visual disconnect between workflow statuses and all other dimensions of the workflow (assignee, properties, transitions). This was especially a concern considering the close relationship that a workflow status has with these other dimensions. I.e., a set of properties and possible transition points are set up for a specific status - yet the interface does not easily let me see all my configurations at a per-status level.

Problem 2:Role based restrictions and Attribute Constraints are difficult to comprehend

Role based overrides
A workflow can be configured to work differently for each role, however, the current interface made it difficult to see such specific restrictions at a role level. Instead, the expectation was to find that information at an individual statuses, which led to users being unsure about which status contains what role overrides, if any.

Attribute Constraints
As an asset moves between different statuses, there are rules that define which properties must be filled, which properties already exist but must be updated, and which properties must never be allowed to change. In the original QPP, these rules were challenging to configure and the poor choice of interface and interaction only made things worse.

Problem 3:Confusing vocabulary

Another observation that came up after several rounds of discussion with Engineering and Professional Services was the realization that the lack of proper UX Writing was equally to blame for why the workflow designer seemed overwhelmingly complicated.

Reframing the problem

Before diving in any further, it was important to make sure all the stakeholders were onboard with the proposed changes. There was a lot of legcacy involved here, and it was imperative that we all be on the same page. After connecting with Product Management, Engineering and Customer Success, the following key solutions were finalized for the redesign:

• Reimagine how a workflow is created to make it more visual - maybe like a flow diagram?
• Ensure that workflow status and its corresponding settings are visually in the same space to make managing complex configurations easier
• Make it easier to reveal what the workflow would look like for any given role
• Make Attribute Constraints easier to set up whilst retaining it's powerful benefits
• Simplify the vocabulary

Ideation

With low-fidelity prototypes, I was able to ideate quickly and test out multiple concepts - some more obvious than others. These prototypes were used extensively to gather feedback from stakeholders - almost every 1-2 weeks to make sure we didn’t go deep in a direction that doesn't meet the objectives.

Solution

Since the style-guide for the next-generation Content Enablement had already been defined, there were several pain points that were resolved relatively quickly once we took the old functionality and injected the same into the new design language.

Introducing a visually rich workflow designer
Instead of a text-based list of statuses, we opted for an interactive workflow builder using Angular’s Material library - specifically, the Drag & Drop component - to develop a modern, visually rich experience of workflow management.

Display status and relevant details together
The new workflow designer leverges the 2 columns layout to showing the workflow statuses on the left, and its respective configuration on the right.

There is also an simple method of revealing role based overrides directly on the worflow designer's canvas.

Create separation between different types of attribute constraints
Attribute constraints (its easier to think of them as property rules), can be configured on individual metadata keys, from 3 possible options:

• Prevent change
• Require change
• Require a value

Changing requirements

An additional challenge that the team faced during this project was the pace at which requirements and features were being iterated upon. Many of the components of the next-generation Content Enablement Solution were being built with an agile approach. And there was a lot of uncertainty over what the Minimum Viable Product would include. With the reengineering of the architecture powering the entrire solution, there were countless possibilities to introduce enhancements. So I had to keep asking:

• "Can we make this easier for the user by adding extra functionalities upfront?"
• "What would that cost us in time and resources?"
• "Is that even doable considering our nearing release date?"

For example:
In the original Quark Publishing Platform, an asset is forced to be entered into a workflow as soon as it is added into the system. With the new architecture, the use of workflows became optional, which meant starting and ending a workflow was something that became a user-level decision and not a system-level decision.

This suddenly opened up a world of possibilities:
For starters, workflows were no longer an obligation but a means to an enhanced experience of managing your team. Additionally, without workflows forcing your files to conform to set rules, you can use the system to simply take advantage of a powerful cloud-based storage system with fine-grain version control, commenting and an assortment of useful features.

Switching status, made easy

Outside of the purview of the Workflow Designer, another thread that needed to be resolved was how unintuitive it was to change an asset's status.

Considering that workflows were now a very conscious user decision and not every file would be part of the workflow, I wanted to make sure we highlight an asset's status with special emphasis, if an asset was in fact part of a workflow.

With the new blade-based framework in place for the Content Enablement Solution, we had the perfect opportunity to simplify this experience. After some back and forth and attempting to understand how users really expect to use the product, it seemed fairly obvious that the ability to switch status can be provided wherever we actually show the status - there was no need to complicate that premise any further.

The solution was to introduce the current workflow status at multiple touchpoints such as when listing all the assets in an explorer-like view; and within an asset's header when displaying an asset's details.

Support for Mobile

With the redesign, one of the constant goals for all design exercises were to ensure responsiveness: design for tablet-first; plan for mobile as much as possible. We were able to achieve both for the workflow designer, which is something I'm very pleased with.