Workflow Dashboard is an internal workflow management platform designed to make long, complex workflows trackable as they progress from end to end. A workflow can span many dozens of tasks across multiple teams, with dependencies determining when the next task in the workflow is ready to start.

I led product design for the platform, working across discovery, information architecture, interaction design, prototyping, and usability validation. I partnered closely with the product manager and engineering leads to translate recurring operational workflows into a cohesive experience that balanced user needs with technical and product constraints.

This case study focuses on one foundational problem within the broader product: before a specific instance of a recurring workflow could be started and tracked, someone first had to build a template for it.

THE challenge

Technical experts called template builders worked with subject-matter experts from the teams involved in a workflow to identify its tasks, establish their sequence, and map dependencies between them.

This was a slow process that relied on a spreadsheet listing all the tasks in a workflow and a flowchart representing them visually.

This created a bottleneck: the number of workflows waiting to be added continued to grow, outpacing the ability to build templates for them.

Understanding the users

I began discovery by speaking with template builders about how they created templates and where they encountered friction.

I then observed several working sessions in which a template builder collaborated with subject-matter experts to refine a workflow template.

The template builder would share the workflow template in progress: a long spreadsheet listing the tasks needed to complete the workflow, represented visually in a flowchart showing the individual tasks, in sequence.

The subject-matter experts would evaluate the workflow template, then propose changes to make it more accurate.

The template builder would then document those changes as annotations directly onto the flowchart. Over the course of a session, dozens of annotations could accumulate, many of them dependent on each other.

A key insight

Each subsequent session would begin with an updated flowchart incorporating the previous session’s proposed changes.

Once seen visually, SMEs could quickly spot errors that had been difficult to identify when they existed only as annotations. As a result, parts of the workflow would sometimes revert to their previous states.

This led to a key insight: annotations alone were not enough. SMEs needed to see proposed changes actualized in the workflow before they could properly evaluate them.

This suggested a new requirement for the experience: template builders needed a way to make and reflect changes visually, in real time, allowing the group to evaluate the workflow as it evolved.

Design strategy

I had already designed a visual framework, validated by users, for workflow instances that auto-updated as tasks progressed and changed status.

That framework could be expanded to be editable, following commonly used patterns from visual flow-building tools.

The goal was to make three things possible:

Edit templates directly

Template builders should have a graphical interface for making changes to the workflow template without relying on code.

See changes in real time

Changes should immediately appear in the workflow so participants could understand their implications in context.

Reduce iteration cycles

Template builders should be able to reach consensus on a workflow template as efficiently as possible, reducing the number of sessions required to complete it.

Design exploration

I explored a fully visual editing model that allowed template builders to add, modify, and reorder tasks directly within the workflow.

The concept addressed the central usability problem: template builders could update workflows quickly and make those changes available for real-time evaluation.

However, this direction required a significant engineering lift that was disproportionate to the relatively specialized template-builder user base.

Pivoting & validation

The concept addressed the central usability problem: template builders could update workflows quickly and make those changes available for real-time evaluation.

However, this direction required a significant engineering lift that was disproportionate to the relatively specialized template-builder user base.

A fully visual approach to editing a workflow template was presented to stakeholders for feedback and, although it was agreed that the approach checked the right boxes for usability, the engineering effort couldn’t be justified for a feature with a limited user base.

My next set of iterations would need to leverage existing patterns and components for easier development, without compromising the goal of enabling quick changes directly onto the visual workflow for real-time previewing.

After conducting some hallway testing of the latest iteration to uncover any glaring issues, I then presented it to stakeholders for review.

The resulting experience

The redesigned template-building experience made it possible for template builders and subject-matter experts to modify and validate workflows together, without relying on increasingly complex annotations or waiting for updated diagrams between sessions.

The change produced measurable improvements in the template-building process:

2–3 templates built per week

Up from approximately 1 template every three weeks with the previous process.

Better clarity during working sessions

Participants no longer had to imagine the implications of their proposed changes; they could see them immediately in the workflow.

Fewer template-building sessions

Template builders no longer had to translate annotations into code after each session with SMEs to update a template, and then schedule a follow-up meeting to review the resulting changes. As a result, some templates could be completed in a single session.

More broadly, solving this problem removed a foundational bottleneck in Workflow Dashboard: the platform could only provide value at scale if teams could efficiently create the workflows it was designed to manage.

Project takeaway

This project reinforced the importance of separating the underlying user need from the solution used to address it.

The initial concept provided a strong user experience through a fully graphical interface, but the engineering cost wasn’t proportional to the size of the audience. 

By returning to the core insight from discovery—keeping workflow changes visible and understandable in real time—I found a more pragmatic solution that preserved the value of the experience while fitting the constraints of the product.

UX tools used

Figma · FullStory · Dovetail · Miro