Diagram View Revamp

Years of design debt, scoped into one vision.

Contribution: Research + design, driving the exploration
Team: 1 co-designer, product and engineering
Product area: Flow automation canvas
Research sample: 3 competitors + 2 years of public community posts
Delivery: 2 months, 8 items scoped for V1, web
Outcome: In build

Context

Two views, and people worked in one

Flow Designer had two views and people worked in one. The canvas was somewhere to look, not somewhere to work, so I used the rebuild as the opening: eight items scoped for V1 and negotiated live with product and engineering.

The problem

The glance-and-abandon canvas

Flow Designer offered two authoring modes for building automated workflows: a structured list view and a visual diagram canvas. Whilst visual orchestration represents standard practice across enterprise automation platforms, our canvas had been left behind. Authors opened it to scan the shape of a process, then returned to the list view to conduct the actual authoring.

Years of accumulated technical debt in the legacy React implementation had prevented engineering from shipping parity updates or responsive node interactions. Capabilities available in the list view, including node reordering and the collapsing of structural branches, were absent from the canvas. Failure was not represented at all.

When the migration to a Lit web component library was scheduled, the mandate for the first release was strict functional parity: the same tool rebuilt, function for function. What that parity would preserve was a view authors had stopped authoring in.

Every substantive edit required leaving the canvas, and a canvas users continually leave is a canvas they stop opening.

The shipping Flow Designer diagram view: sixteen numbered steps in two columns on a light canvas, with branch connectors crossing the full width of the screen and looping back underneath the flow

Internally the position was not in dispute. Diagram view usage sat far below the list view, and had done for years.

The public record stated the same case from outside. Its sharpest instance was a workflow that would not render at all: one containing stages, which our own documentation instructs customers to add as a best practice.

Tried to show this to a client and none of their flows will diagram because of the error: “Diagram view is unavailable… Flow stages present”… So ServiceNow says to add stages to Catalog Item flows as a best practice, but then prevents their diagrammer from working under those conditions?
ServiceNow Community

Four further complaints sat behind that one. Complex workflows were described as spaghetti. Debugging was called a nightmare, because execution detail is held behind a system property few users locate. Migration from Classic Workflow was reported as painful beyond the basics. Decision Tables were buried deeply enough that experts direct people to them in forum replies.

This is secondary research: public Community posts, support threads and documentation from 2023 to 2025, compiled and lightly edited. It is not interviews, and it is not telemetry. Verification against our own support data is a named next step.

The exploration was not assigned to me. I compiled the complaints, benchmarked the canvas against the tools customers compare it to, and returned with a scope a first release could deliver.

The live V1 prototype

A co-designer and I built this together on one shared branch, so the eight items could be tried rather than argued about. It runs here rather than being described. Search the canvas, collapse and expand the branches, switch between canvas and list view, and turn the Global Error Handler on.

Flow Designer Revamp, V1 Open full screen

Competitive benchmark: the diagram view against ten canvases
Tool	Free node placement	Branches rejoin	Loops as back-edges	Run data on the canvas	Grouping or lanes	Minimap
ServiceNow FD	No	Partial	No	No	No	Yes
Camunda	Yes	Yes	Yes	Yes	Yes	Yes
UiPath	Yes	Yes	Yes	Yes	Yes	Yes
Appian	Yes	Yes	Yes	Yes	Yes	No
n8n	Yes	Yes	Yes	Yes	Yes	Partial
Make	Yes	Yes	No	Yes	No	No
Salesforce Flow	Partial	Yes	Yes	Yes	Partial	No
Zapier	Partial	No	No	Partial	Yes	No
Power Automate	No	No	No	Partial	Partial	Yes
Tray.ai	No	Partial	No	Partial	Partial	No
Workato	No	Partial	No	Yes	No	No

The brief

Transforming a read-only pane into an active authoring workspace

My assigned responsibility on the rebuild was the design audit: confirming, screen by screen, that the rebuilt canvas matched the tool it replaced. Every screen was being touched regardless, and building with AI made a broader scope affordable in a way the legacy code never had.

I therefore opened a vision track alongside the parity work and argued for it. The self-set brief had three goals.

Eliminate forced context switching. An author should be able to build, repair and read a workflow without leaving the canvas, which means parity with the capabilities the list view already held.
Meet the contemporary benchmark. The canvas should stand beside the tools authors compare it to without apology, on visual clarity, canvas navigation and error handling.
Earn sustained adoption. A view users opened only to look should begin earning its place in the product.

Eight items for V1, drawn from the friction points the research repeated most often and walked through live with product and engineering rather than circulated as a deck.

User personas

Four enterprise roles the research kept returning to

Workflow authoring spans several levels of technical literacy. Three of these roles already work on the canvas. The fourth cannot get it to render at all.

Enterprise workflow author

Large-scale automation

Need: To hold a thirty-application access workflow in mind whilst editing it.
Constraint: They never once referenced diagram view as a tool that might assist, which is itself the finding.

Classic Workflow migrator

Long-tenured developer

Need: To comprehend a workflow as rapidly as they did in the tool they left.
Constraint: In their own words, transitioning to Flow Designer has been painful.

Production operator

Debugging a live incident

Need: To establish where a live process currently stands, and where it failed.
Constraint: Execution detail sits behind an undiscoverable system property, and the context page is empty.

Pre-sales consultant

Partner demonstrations

Need: The diagram to render. At all.
Constraint: Stages block it outright, and stages are a documented best practice.

The research behind the scope

Three years of complaints, and the reading that chose the eight items

The benchmark above says what competitors do better. It does not say what our own users were struggling with, and the two are not the same list. Before scoping V1 I read three years of public posts about Diagram View and recorded twenty-eight distinct findings, each with how often it came up and how badly it hurt. The severity turned out not to be spread evenly, and that is what decided where the eight items went.

Pain points research Open full screen

Show the whole pageShow less

The field, in full

Ten canvases, and the one question that predicts all of them

The benchmark table is the summary. This is the review it came out of: every canvas read on its own terms, screenshot by screenshot, against the same twelve capabilities. The question that sorts the field is whether a node carries coordinates, because that decides whether branches can be drawn to rejoin, whether a loop can be a visible back-edge, and whether the picture is the model or a report about the model. Each tool folds shut until you open it.

Ten flow canvases Open full screen

Show the whole pageShow less

What I designed

A modular, interactive canvas foundation

Solution 1 of 4

Stage as a first-class node type

Problem: A stage within a workflow constituted a hard block. The canvas refused to render, and the person who encountered it was typically standing in front of a client.
Design decision: My first instinct was a compatibility mode: render the workflow, grey the stages out and ship it. That is a workaround. Stage instead became a node type like any other, sitting beside Action, Flow Logic and Subflow, with a name, a value, a duration and its own properties panel.
Result: The most frequently cited blocker in two years of public complaints now has an answer on the canvas.

The V1 canvas with numbered steps, inline annotations and a collapsed branch badge — The V1 canvas a stage node lands in: numbered steps, inline annotations, one branch collapsed to a badge.

Solution 2 of 4

Persistent in-canvas search

Problem: Locating a single step in a large workflow required scanning it, and a large workflow is precisely the case in which scanning fails.
Design decision: Search sits on the canvas and never leaves it. My co-designer wanted it pervasive: an element that never disappears. Matches highlight, the remainder dims, and up and down step through the results. The team declined to auto-focus the field, which I consider correct: the canvas is for building until the author indicates otherwise.
Result: Typing works the moment the canvas loads, with a match counter and keyboard navigation.

Canvas search highlighting one match and dimming every other node — A match highlighted, non-matches dimmed, and a count with up and down navigation.

Solution 3 of 4

Named collapse for structural branches

Problem: Spaghetti was the second complaint and the leading competitive gap. Collapsing branches addresses both, and my first pass did not survive review.
Design decision: My co-designer could not determine what was collapsing, since any node might absorb anything downstream. A teammate added that the dark theme rendered the affordance harder to see again. The badge therefore names its own unit and count on hover, and both themes are buildable side by side rather than argued about.
Result: Two branches, click to collapse. It states the noun, the number and the action.

A collapsed branch badge showing the label two branches, click to collapse — The objection, answered on the badge itself rather than in documentation.

Solution 4 of 4

Global error handling on its own canvas

Problem: Error handling was not visible anywhere. Every competitor in the benchmark draws it, and we drew nothing.
Design decision: Routing error paths through the main canvas would have doubled the very thing we were attempting to untangle. The Global Error Handler sits beside the workflow instead, behind a toggle, with its own group in the data rail. Any step fails, then capture context.
Result: A gap listed as unexplored at the July sync is now in the prototype.

The Global Error Handler on its own canvas beside the main workflow — Failure kept beside the workflow rather than threaded through it.

User flows

Streamlining the authoring and recovery loops

Add a stage to a workflow The fix for the top blocker

Canvas: trigger to action
Add a node
Add to flow: Action, Logic, Subflow or Stage
Select a stage, or create one
Name, value, duration
Inline flagged node and properties panel

Locate a step in a large workflow Enterprise workflow author

Land on diagram view
Type immediately
Matches highlight, the rest dims
Step through the results
Jump to the node

Reorder a node Flow author

Drag a node
Approach a connector
Original position fades
Release to snap in

Catch a failure Production operator

Toggle the error handler
It opens beside the workflow
Its own group in the data rail
Any step fails
Capture context

The targets it was scoped against

2/5 to 5/5

visual clarity for complex flows, benchmarked against the wider field. A target.

flows blocked from rendering by the presence of stages. A target.

items scoped for V1, two of them already deferred or undecided.

What this project changed

Nobody defends a two out of five

An engineering-led framework migration was repositioned as a design opportunity, and diagram view moved from a passive preview towards an environment an author can remain in. Eight items were scoped in a room with the product owner and the engineers who would build them, and two were cut on the spot.

What I had not anticipated was the effect of the benchmark on the room. Collapse and expand, argued as a design opinion, had gone nowhere. Placing our canvas in a row beside the tools it gets compared to, with a mark beneath each, converted it into a scoping conversation. Nobody defends a two out of five.