Back to portfolio

Designing content-first workflows

  • Title: Lead UX Designer
  • Company: Quark
  • Timeline: 2019 — 2020
My responsibilities:
  • Design research
  • Information architecture
  • User experience design
  • User interface design

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.

Large scale editorial processes are complex and involve operations beyond the usual authoring, editing and reviewing. They include additional, equally critical stages such as content modeling, approving or rejecting content, versioning and comparing content, as well as controlling access to content.

As the demand for content grows, so does the challenge of managing the act of creating said content, and a key theme in this whole arc of content publishing for a large organizations is governance: this is a granular system of permissions for individuals and groups which ensures that only permitted actions can be carried out by authorized users at any given stage of the content lifecycle.


Easier workflow management

A redesigned 'birds-eye' view of all system-level and user-level workflows for easier management.

Improved configuration panel

Played a key role in simplifying how workflow status is configured, including a simplified set of available options and a reimagined Rules section.

A more connected interface

Based on customer feedback, I helped create a new, more visual workflow designer with a deep attention on information architecture.

A new mobile experience

The next-generation blade-interface provided the perfect opportunity to ensure that the complexities of the workflow designer were simplified for mobile.

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.


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.

  • The original workflow designer for Quark 01
  • The original workflow designer for Quark 02
/ Above & below / the legacy Workflow Designer seemed convoluted and complicated. And our customers felt the pain, despite our best efforts for training and onboarding them.
The original workflow designer for Quark 01

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.

The original workflow designer for Quark 03
/ Above / All workflow configurations are bound to a status, but the tabbed interface makes everything seem disconnected

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.

The original workflow designer for Quark 03
/ Above / Managing attribute constraints in the legacy workflow was difficult to say the least

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


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.

/ Above / Throwing some ideas on the wall to simplify workflows


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.

  • Redesigned search 01
    / Above / Iteration 1 of the workflow designer was a task-based workflow designer with 2 fixed states (not started and completed), and with statuses treated as groups of tasks for improved organization. However, due to various legacy constraints, we were forced to ignore additional enhancements to how workflows operate. So this concept was abandoned.
  • Redesigned search 02
    / Above / Iteration 2 of the workflow designer was simpler in terms of functionality and execution. The bulk of the effort was focused on simplifying existing functionality and not reimagining new use-cases.

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.

The original workflow designer for Quark 03
/ Above / The new workflow designer in a 2 column view: details on the right represent the status selected on the left.

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
To simplify the mess that is otherwise created when you have dozens of metadatas with an assortment of those three rules, my idea was to have virtual-buckets for the different types of constraints and allow users to add relevant properties into them, therefore, simplifying the process and the cognitive load.

The original workflow designer for Quark 03
/ Above / Virtual buckets where all three rules can co-exist without overwhelming the user

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.

  • The original workflow designer for Quark 03
  • The original workflow designer for Quark 03
/ Above / You would change a workflow status in the older generation Publishing Platform by right clicking on a document and selecting 'Edit Attributes'. It's awkward to say the least.

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.

The original workflow designer for Quark 03
/ Above / Switching status is now easier and accessible from multiple touchpoints.

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.

  • The original workflow designer for Quark 03
  • The original workflow designer for Quark 03
/ Above / The behemoth of a workflow designer works well on mobile, which is an amazing achievment of clear thinking and strong engineering of the entire team.
Visit website