New API Integration workflow builder to be more intuitive and flexible

The idea behind the workflow builder was straightforward: Pick a trigger → Add your steps → Publish.

But the actual experience was far from straightforward. The original builder tried to support everything, triggers, actions, conditional logic, split paths, testing, but without enough visual structure or feedback. During internal reviews and early user sessions, the same question kept coming up: "Wait... did this actually work?"

Users were building workflows but couldn't tell if they were configured correctly until something broke in production.

We didn't just polish the existing builder. We rethought the entire workflow creation experience.

We rebuilt the canvas with drag-and-drop interactions, added a contextual sidebar that adapts to whatever node you're configuring, and introduced split paths with both conditional and percentage-based routing. Then we layered in a full test-before-publish flow so users could validate their automations before going live.

Every decision was guided by one question: "Can the user tell what's happening and feel confident it's correct?"

Here's what changed:

The result was a builder where users could see their logic, validate their setup, and publish with confidence.

The same process runs through every project I take on. Learn, define, design, test, refine, then hand off. The loop from refine back to design is the part that matters most: nothing here is a straight line, and the workflow builder took several passes before the canvas told users what they needed to know.

Before committing to any design direction, we studied other workflow and automation platforms to see how they handle the same challenges we were solving.

We analyzed a mix of direct and indirect competitors:

• Zapier (the market leader, simple but limited visual feedback)
• Make (formerly Integromat, powerful but visually dense)
• n8n (open-source, developer-friendly, steep learning curve)
• HubSpot Workflows (polished but rigid branching)
• Workato, Tray.io (enterprise-grade, complex onboarding)

These gave us a clear benchmark: powerful logic needs an approachable interface, not just more features.

Competitor teardowns told me what the category had settled on. They could not tell me why Blend Metrics’ own users were abandoning workflows halfway through. For that I ran a survey to size the problem, then interviews to understand it.

34 survey responses from people who had built at least one workflow in the previous month, and 8 follow-up interviews of roughly 30 minutes each with the operations and marketing people who live in this tool daily.

The survey was deliberately short. Five questions, all about the moment before and after publishing, because that is where the support tickets clustered.

Two numbers reframed the project. 68% would not publish without manually checking the workflow first, and 62% debug by opening every step in turn. People were not asking for more power. They were doing the builder’s job for it, holding the whole workflow’s state in their head because the canvas would not show it to them.

The survey said where time went. The interviews said why. I kept the questions behavioral, asking what people actually did last time rather than what they think of the product.

Different words, same three frustrations, and each one maps to a theme that came out of the affinity map.

We gathered notes from user interviews, internal feedback sessions, and early usability tests, then grouped them to find the patterns.

Users were articulating frustrations differently, but the underlying themes were consistent. Whether they were talking about triggers, conditions, or testing, the same anxieties kept surfacing.

Once we clustered everything, it became clear: we weren't just solving for layout or interaction. We were solving for confidence.

Once we had a clearer picture of what users needed, we mapped out every possible feature and sorted them by impact, effort, and user confidence. The question at the center of every decision: "Will this help users build and publish workflows with less doubt?"

If the answer wasn't a clear yes, it didn't make the cut.

This helped us stay focused. We didn't chase power-user features. We prioritized clarity and validation at exactly the points where users tend to lose confidence.

We mapped out what it actually felt like to build a workflow in Blend Metrics, from opening a blank canvas to publishing a live automation. The journey revealed hidden friction points at every stage. Users weren't just clicking nodes. They were guessing, backtracking, and abandoning workflows they weren't sure would work.

We weren't just mapping clicks. We were mapping confidence levels. Because automation builders don't lose users at the start. They lose them in the middle, when things get complex and there's no feedback telling them they're on the right track.

We mapped five core flows that represent the full lifecycle of building and managing a workflow automation. Each one was designed to reduce cognitive load at the exact moments where users tend to hesitate, second-guess, or abandon the process entirely.

This is the core builder experience. Users land on a clean canvas with a guided empty state, add triggers and actions via drag-and-drop, and see their automation take shape in real time.

The sidebar walks users through every configuration step: selecting a trigger type, connecting an account, choosing an event, and mapping fields. Nothing is left ambiguous.

When workflows need to branch, the split path interface makes it visual and approachable. Users choose between conditional routing or percentage-based distribution, and the canvas reflects the decision in real time.

The test runner gives users a clear picture of their workflow's health before publishing. Passed and failed connections are displayed with expandable details, and the canvas highlights error nodes so fixes happen in context.

Publishing is the highest-stakes moment in the builder. The two-step publish flow confirms intent with plain language, then celebrates the milestone with a clear success state and next-step options.

Connecting third-party accounts is a required step for most triggers and actions. The authorization flow supports multiple methods so users can connect in whatever way their service requires.

Beyond the canvas, users need tools to manage their workflows at scale. Context menus, version history, and rename modals give users control over their workflow library without cluttering the builder itself.

Once a workflow grows past a handful of steps, finding a specific node by scrolling stops working. Search reads the whole canvas and returns matches grouped by type, so users can jump straight to the step they meant.

Every node on the canvas is configured through the same three tabs. Splitting the work this way meant a node could be set up, gated, and verified without ever leaving the sidebar or losing canvas context.

Publishing is not the end of a workflow’s life. Every publish is snapshotted so users can see what changed, who changed it, and roll back a bad edit without rebuilding from memory.

With 126 triggers, 52 conditions, 294 actions and 46 filters, the library is the densest surface in the product. It had to stay browsable for people exploring and instant for people who already know the step they want.

Cloning, testing, pausing and deleting all live behind one options menu. Every action that is destructive or hard to undo is confirmed in the same shape, so the pattern is learned once and applies everywhere.

Every component in the workflow builder is built from a unified design system I created specifically for this product. Colors, typography, buttons, form elements, and status indicators are all standardized to ensure visual consistency across the canvas, sidebar, and modal layers.

Before handing anything off, I ran moderated usability tests with 5 participants to validate the core builder flows. Each session lasted about 20 minutes and followed a structured test guide. I tracked completion rate, error rate, time to success, and satisfaction level, then assigned severity ratings (1 = cosmetic, 4 = must fix) to prioritize what needed attention.

Task Results

Key Findings

Every component in the workflow builder has a master component with clearly defined variants. All state management is laid out: default, hover, active, focused, and disabled states are accounted for across buttons, nodes, sidebar panels, and modals.

I organized every variant side by side so developers can reference them at a glance. The design files make front-end functionality and component architecture immediately clear.

This project taught me that building powerful tools is only half the job. The other half is making people feel confident using them. What started as "let's improve the workflow builder" turned into a full UX rethink of how visual automation should feel. Every decision came back to the same principle: if users can see it, validate it, and trust it, they'll ship it.