Workflow Builder

Overview

Goals

Impact

Customer feedback validated the demand for workflow automation, reducing repetitive task execution time from 40 minutes to 6.5 minutes through reusable no-code workflows.

My role

I worked with the Product Manager and Architects to make sure the design was technically feasible and met product requirements. I presented design concepts regularly, gathered feedback, and iterated on the experience.

Through development I provided detailed developer handoffs, ran UX walkthroughs, supported QA, and kept the engineering team in the loop with every design update.

Research and findings

There were no end users I could sit with at the start, so the first insights came from the people closest to the product.

I sat with the PM and the architects and worked through two sets of questions: what the feature had to be, and how the canvas had to behave.

Persona and user journey

Research takeaways

What stuck from the stakeholder sessions, customer service insights, and competitor analysis.

User story

All of it condenses into one sentence that the rest of the project answers to.

References

I started by studying how existing automation tools handle a canvas: how n8n and Zapier structure nodes, connections, and configuration panels, and how they behave when a flow gets long. That set a baseline for what an admin would already recognize, and it made clear our workflows were short and mostly linear, so we could afford to be simpler than any of them.

Information architecture

The IA settled on three surfaces: a dashboard that lands you on every workflow and deployment, a details page as the read-only home of a single workflow, and the canvas where a workflow is created and edited. KPIs live only on the details page, and deploying straight from the dashboard was deliberately parked for a later phase.

I validated the map with the PM and architects before drawing any screens, walking it surface by surface to confirm what lived where, what was view-only, and what was out of scope.

Flows

Everything a user needed to do, written down as flows before any of them were drawn:

• Build, edit, and delete a workflow.
• Add, delete, move, search, and configure nodes and their parameters.
• Build a workflow from JSON by uploading a file, or download an existing one.
• View deployments for a workflow.
• Check an overview of deployments and navigate to the deployments page.
• Add tags to a workflow and check its status.
• Handle node failure on the configuration side.

User flow and journeys

From that list I mapped the two journeys that matter most. Creating a workflow end to end, including the power-user path that opens the JSON editor instead of the canvas.

And working with an existing workflow from its details page: deployments, editing, deleting, and viewing the flow.

Wireframing with Figma Make

Grid and color contrast

With the wireframes agreed, phase two was iteration: taking every piece of the canvas and reworking it until it held up. The grid came first. I made the dots lighter so they sit behind the workflow instead of competing with it, while keeping enough contrast to stay accessible.

Node dimensions were tuned to the same grid, so a node always fits cleanly between grid rows and the flow keeps a steady rhythm down the canvas.

Node explorations

The node itself went through its own rounds. It ended up deliberately neutral, with a single configuration status, so the canvas stays calm no matter how many steps are on it. Delete stays visible on the node because people reach for it constantly; the less common actions (move up, move down, duplicate) are grouped under a keyboard-accessible kebab menu.

Every node carries the same four touchpoints: a drag handle, its configuration status, delete, and the menu. Nothing else earned a place on the card.

Node handles for keyboard

I dropped the connection dots completely. They added visual weight, and they actively worked against keyboard users: with dots as the target, moving a node up or down had no exact destination the interface could promise.

Without them, the flow itself is the target, so a node reorders one step at a time and always lands somewhere valid.

New canvas

The empty canvas has to invite a first step from two kinds of users at once: someone dragging with a mouse, and someone who never touches one.

The prompt went through four rounds, starting from a plain placeholder to a focusable plus between Start and End that triggers keyboard navigation, with copy that names both paths: drag and drop, or click + to add a step.

Layouts explored

Node branching

Branching was the hardest thing to make keyboard-fair, so I worked the scenarios until the rules were simple:

• Branching is only possible on a Switch node, with a maximum of five branches.
• A node can change position only within its own branch, but the left and right arrows move focus across branches.
• Double-clicking any node, or pressing Enter on it, opens its configuration and shifts focus into the drawer.
• Connectors are limited to straight and step patterns, which cuts visual clutter and keeps branching workflows readable.

Keyboard navigation

Every node's actions work as a labelled toolbar, and the spec I handed to engineering said exactly how a screen reader should treat it:

• The section holding Duplicate and Delete is wrapped in an element that defines it as a distinct toolbar block.
• role="toolbar" tells the screen reader this is a set of utilities navigated with arrow keys, not tabbing.
• aria-label names the group, so the user understands the scope of these icons.
• Pressing the down arrow jumps focus straight to the first icon inside the node's action group.
• aria-describedby announces: “Press Alt plus Up or Down arrow to reorder this node.”

Invalid use cases

Then I attacked the canvas with everything that could go wrong: a Switch branch left without a target, a node sitting disconnected from the flow.

Every invalid state gets an explicit way back. Select target and Change target live on the insertion points, and a Connect to menu sits on the node itself, so a workflow can always be brought back to valid before it's saved.

Node configuration and the JSON editor

Configuration is where admins spend most of their time, so the drawer got its own round of iteration:

• Fields auto-fill with previously saved values for the same node type, cutting repetitive configuration.
• A suggestion list of past configurations appears only after that initial auto-fill, so values are quick to reuse or edit.
• I extended an existing dropdown component to carry the new interaction, with a distinct icon so it doesn't read as a standard dropdown, giving it new behaviour on the same design system.

Feature structure

The Workflow Builder experience consists of three core screens: the Workflow Dashboard, the Workflow Creation Canvas, and the Workflow Details screen. Together they support the complete journey from creation to deployment and management.

Building on the canvas

A collapsible Action Library balances discoverability with canvas space. Search prioritizes node names, then categories and descriptions, so the right action surfaces fast. A fixed Start and End structure keeps every workflow consistent, while canvas controls like Zoom, Fit to View, Auto-align, and Lock keep larger workflows navigable.

Adding node to canvas by drag and drop

Adding node to canvas by keyboard

Keyboard navigation gets equal treatment here, not a fallback. There's a plus between every pair of nodes, and a Skip to Action Library link jumps focus straight to search and then to the canvas.

Mapping

Node: add, swap, duplicate, delete and save

This walks through the node lifecycle from start to finish. Pick a slot and place a step, and every edit that follows, whether swap, duplicate or delete, keeps the flow valid and connected. Saving asks for a name, description, and tags, or holds the workflow as a draft.

Configurations, JSON editor, details and edit workflow

Configuration and the power-user path, side by side. The drawer auto-fills from past values and suggests previous configurations, the live JSON editor imports and exports whole workflows in sync with the canvas, and the details page keeps stats, properties, tags and deployments one read-only view away.

Accessibility for mobile screen

The builder holds up on a smaller, accessible viewport. The same node, library, and configuration patterns adapt to a narrow screen, and adding a step works the same way.

Keyboard navigation order

Underneath all of this is a defined tab order, the spec I handed to engineering. Every interactive element is numbered in the sequence focus moves through it, so the keyboard path is unambiguous to build and to test.

Skip links jump focus to the action library or the canvas, the canvas runs Start to End following the workflow itself, and even chart segments take focus.

Detailed flows and use case

The full set of detailed flows and use cases, covering every interaction, state, and edge the canvas handles, lives in a separate document.