Making flow creation intuitive & scalable

Getting users to value quickly

I design end-to-end product experiences and the UX systems that sustain them — from early foundations through growth, optimization, and scalability.

Initial company and product state

Company state

Celigo was a Series A SaaS startup, and I was the first product designer. The platform’s success depended on enabling customers to build and maintain complex data integrations independently, without relying on professional services. Its current Gartner position was Niche, though it would move to Leader.

Product state

Flow creation was the core of the product’s value, but it relied on a series of complex forms to connect data. The flow builder itself was in alpha state, but needed to become the core way users built and evolved flows.

Challenge

Flow creation was the core of the product’s value — yet it was one of the most confusing and restrictive areas of the platform. Before the redesign:

  • Users had to deal with a number of confusing orchestration forms. The canvas wasn’t truly a canvas — it was an early, constrained prototype buried behind forms.
  • Users had to stop everything to create a connection before they could even begin building a flow.
  • Business users (a core growth audience) couldn’t get started at all because they couldn’t configure authentication.
  • In the first concept of the visual canvas, all controls were exposed at once, creating visual overload.
  • Larger flows became unmanageable: no zoom, no way to see structure, no visibility into configuration status.
  • Debugging and error visibility were nonexistent. Users ran flows blind.
  • Users couldn’t modify existing flows or swap out applications. Any change required starting from scratch.
"Building flows was like trying to navigate a maze in the dark" - Developer, GoDaddy

There was no guidance to get started, check your work, or troubleshoot flows.

Approach 

Rebuilt flow creation around how users actually work

I shifted the interaction model away from “configure everything first” to “start building immediately,” reducing time-to-first-value dramatically. This included removing the forced step to authenticate an application in the flow, so that users could now map out flows visually before dealing with authentication. This unlocked flow creation for business and technical users alike, promoting flow creation and expansion.

Created visual canvas for flow building

I redesigned the early prototype into a scalable, intuitive builder designed for complexity:

  • Progressive disclosure instead of overwhelming control exposure
  • Zooming, panning, and full-screen for large flows
  • Clear node structure and visual hierarchy
  • Immediate visibility into broken, missing, or incomplete elements
  • Postponing the need to authenticate applications, enabling users to immediately start building flows
  • Ability to create connections on the fly

Users could now see what was wrong, what was missing, and what to do next, instead of building blind.

The first iteration of the new flow builder brought forth connections that we down, issues that needed attention, used progressive disclosure to only give you what you needed when you needed it (instead of a lot of confusing controls).
Initially, users couldn't create a connection. They had to use an existing one or exit out and go create a new connection, then start the flow building process again. You could also create a connection later, freeing users from the rigid authentication requirement. This enabled business users to creating a flow structure, then turning it over to developers to add the underlying logic.

You could now search within applications and see which applications were in each category, reducing cognitive burden in choosing the right connector for your needs.

Rather than letting users just guess which connection was online and authenticated, this brought forward the info that not only was a connection offline (needed authentication or had some other issue), but also enabled you to fix the problem right there.
You could now quickly edit connections without having to exit your flow building process, keeping you engaged.
This was a further evolution of flow builder, as we were able to get away from having source and destination applications and could let users build the flow they wanted. We reduced the cognitive burden of "what is an import"?, "what is a lookup", etc., and used progressive disclosure to get you moving quickly.

Flow menus

Previously many of these controls were on the canvas with no labels. It was difficult to know what to do next, and business users weren't familiar with terms such as "lookup". This organized all actions, defined them, and provided guidance on the scenarios in which it could be used.

Flow builder menus

Added branching logic

User research revealed customers were faking the concept of branching using filters. This introduced:

  • Progressive disclosure with only the relevant menu options
  • Ability to add and remove branches
  • Visual structure that scaled with complexity

This enabled real decision logic.

The first step of flow branching, hiding the complexity until needed.
Setting up the logic of flow branching. The logic widget was a third-party tool that we were not successful in getting approval to redesign.
Flow brancher enabled customers to create as complex a flow as they needed, with the ability to modify any part of the flow at any time, enabling scalability as a company grew or as applications used changed.

Preview data, test, and validate

To prevent hours of blind trial-and-error, I added:

  • Preview data pulled from the destination app
  • Configuration testing to validate if an app was set up correctly
  • Real-time validation to highlight errors early
  • Debug

This aligned the builder with modern workflow-automation expectations.

To facilitate debugging, I built this new debugging console, showing HTTP request, response, body and header, as well as enabling capturing more detailed debug logs. None of this functionality was available before.

Built the Run Console

Previously, users had no idea what ran, when, or why it failed.

I introduced a run console with:

  • Run history
  • Connection usage
  • Data preview
  • Quick access to error messages
  • Advanced actions when needed

Less common functions were tucked away; core insights were front and center.

Users could tell what needed attention, such as a broken connection, something that didn't exist before, but could also rerun the flows, cancel runs, view history and much more, all of which didn't exist before.

Enabled flow modification

Users could finally:

  • Replace applications
  • Swap out connections
  • Reconfigure steps without rebuilding
  • Evolve flows over time

This paved the way for copy-flow functionality and dramatically reduced rebuild effort.

Each branch could be configured andinput/output checked before running flows. Note: The logic builder widget is third-party and could not be modified within the project scope.

Resolving errors quickly and confidently

This error resolution console enabled users to get all information about an error, make adjustments to retry data in place, save changes, retry, resolve, and move to the next item. Previously, messages were truncated, they could not edit retry data, you could only resolve one error at a time, you couldn't retry an error, you couldn't see HTTP request and response, and much more, so this was a vast improvement.

The CTO said my error management revolutionized the platform and one customer said I should get a raise!

This error resolution console enabled users to get all information about an error, make adjustments to retry data in place, save changes, retry, resolve, and move to the next item.
To facilitate debugging, I built this new debugging console, showing HTTP request, response, body and header, as well as enabling capturing more detailed debug logs. None of this functionality was available before.

Impact

  • Enabled business users (not just developers) to build flows end-to-end.
  • Reduced time-to-first-value, improving trial conversion and adoption.
  • Drastically reduced cognitive load, helping users understand where they were and what they needed to fix.
  • Transformed debugging, allowing customers to test, preview data, and validate configurations.
  • Introduced branching, enabling customers to design multi-path workflows that previously weren’t possible.
  • Set foundation for future scalability, including advanced automation and multi-step workflows.
  • Contributed directly to Celigo’s movement into the Gartner MQ Leaders quadrant.