Umair Yahya
All work

I rebuilt Integry’s Flow Builder so people can read a flow while they build it.

Integry Flow Builder, 2022 to 2024. The old builder offered no guidance. The new one shows where logic can go, what still needs setting up and how to test it, on one canvas for developers and non-technical operators.

Flow BuilderEnabled

When contact created in AcmeSaas, get contacts by email in HubSpot

betaproduction

What the happy path doesn’t show

  • Needs configurationBuild the flow first, set each step up later.
  • ConditionsIf, Else If and Else stay readable as indents.
  • LifecycleInitialization when the flow turns on, Cleanup when it turns off.
  • Run failsIt stops at the step, and an error notification goes out.
  • LoopsA two-way sync can’t trigger itself and use up tasks.

Designed before launch. Multiple triggers and the lifecycle canvases were deferred.

Add a step from the real picker, run a test, open Settings, and switch the flow off and on. The model shows the full design, including pieces deferred at launch.

Role
Senior Product Designer and Team Lead, August 2022 to January 2024, in Dubai. I managed a junior designer day to day and designed most of the Flow Builder myself.
I owned
The Flow Builder, with the embed and form builder alongside: the lifecycle, branching and loops, insertion points, configuration state, error notifications, loop prevention, and the design system behind them.
Worked with
The Head of Product, whose lifecycle model I turned into structure, and the CEO behind it; a Product Manager I ran the process with; engineering; customer success and sales.
Shipped
At the end of 2023, roughly three months after delivery began, and still live at integry.ai. Verified.

The builder could create a flow. It could not make one readable.

When I joined, I found the existing builder hard to follow even as a designer, and it gave the people using it no guidance. It handled one trigger and one straight line of actions. Nothing ran when a flow was switched on or off, and IF and Else logic was hard to add and harder to follow.

It also competed with the rest of the product, with panels on the left, top and right around the work. People were building a system of dependencies inside what still felt like another screen.

That mattered more than polish. Integry is embedded in its customers’ products, a platform of 50,000+ users and over a billion API calls a month, so a confusing builder became their support problem, not just Integry’s.

  • Support ticketsThe same limits, reported again and again.
  • FullStory session recordingsPeople getting lost while assembling a flow.
  • Feedback relayed through salesCustomers asking for what the builder could not express.

The same canvas had to guide operators without limiting developers.

Developers needed HTTP calls, JSON, custom code, output caching and precise failure information. Product people and less technical operators needed a journey they could read without translating a node graph in their head. I used progressive disclosure by expertise rather than splitting them into two products.

For operators

  • A plain-English title“When contact created in AcmeSaas, create contact in HubSpot”
  • App icons and compact badgesThe source of each action, and IF and Else at a glance
  • Dashed rowsWhere another step or branch can go

For developers

  • Make HTTP Call, Receive HTTP CallIn the same picker
  • JSON, custom code, system operationsA clearer place, not a removed capability
  • Output cachingA setting on the flow itself
The empty state teaches the minimum valid structure before the first choice: add a trigger, then one or more steps.

Six decisions, after seven rounds of exploration.

Between joining in 2022 and the October 2023 hackathon, the working file records seven exploration rounds, four architecture studies and six studies of adding and removing steps. These came out of them, each with a working piece. Unless a decision says otherwise, I made it with the Product Manager I ran the process with.

A vertical stack instead of a free-positioned graph

Chose
A vertical reading order with indentation and dashed connectors, inside a focused full-screen workspace. The system controls layout; people concentrate on sequence, conditions and data.
Instead of
A free-form canvas, which can express complexity but asks people to arrange it, and the normal product shell, whose chrome competed with the flow.

The same flow, laid out two ways. Step names come from the real file.

A later exploration that established the focused, full-screen workspace before the flow structure was resolved.

Every valid insertion point stays visible

Chose
Add step, Add Else IF and Add Else appear as dashed rows wherever the structure allows them, so the canvas shows what can happen next.
Instead of
Hiding every option inside an overflow menu, where the structure’s possibilities have to be discovered one click at a time.

Click to add. The flow keeps its shape either way; only the discoverability changes.

In the shipped design: indentation, connectors, control badges and the dashed rows.

Structure separate from configuration

Chose
People build the complete shape while steps still show Needs configuration. The warning keeps momentum without pretending the flow is ready, and Test Integration stays available throughout.
Instead of
A strictly blocking wizard. Integration setup is rarely finished in one pass, and a wizard hides how unfinished parts relate to each other.

A model of both approaches, using the shipped Needs configuration state.

Needs configuration in the shipped design: the flow keeps its shape while each step waits for setup.

Actions separate from control steps

Chose
The picker gives app actions and IF or Loop controls their own columns, with filters for the host app, other apps and system operations.
Instead of
One mixed list. An app activity and a logic operator do different jobs, and the separation makes the decision clear before anyone types a search.

Items from the real picker.

The shipped picker: add an action, or add a control step.

A flow with a beginning, triggers and an end

Chose
Initialization runs once when a flow is enabled, for example to register a webhook. Cleanup runs once when it is disabled, to undo what setup created. The Head of Product introduced the lifecycle idea; my part was a structure people could navigate.
Instead of
The old single trigger with nothing on enable or disable, where setup and teardown were invisible implementation details.
Decided with
The Head of Product, whose idea it was, and the CEO, who also set the launch cutline. Multiple triggers and the dedicated lifecycle canvases were deferred at launch.

Switch the flow on and off a few times and watch the webhook.

The lifecycle rail as designed. The second trigger and the dedicated canvases were deferred.

Failure designed before launch, not left to support

Chose
Error notifications set up at account level, then customized per flow, with a message that carries the network code, the API response, the Run ID and a link into the failing run. Loop prevention states its cost up front.
Instead of
An error label that says something went wrong and leaves the investigation to support.
Decided with
The Product Manager, from real customer incidents relayed by support and sales. Loop prevention and the basic error settings shipped first; the full diagnostic message was deferred.

The payload as I designed it; its full version was deferred from the first release. Identifiers are stand-ins.

The flow settings dialog: loop prevention says what it costs, and error notifications sit in the same place.

Three months shipped the core model and deferred four pieces.

Before development, I connected the Figma prototype to Maze, wrote the tasks and questions, and ran two variants against each other with people inside and outside the team. The feedback mostly confirmed the direction, and I worked it in before anything went to development.

Development accelerated during an October 2023 hackathon, and the builder shipped at the end of 2023. The CEO and Head of Product set the launch cutline.

  • ShippedIF, Else IF and Else, loops, action and control-step selection
  • ShippedNeeds configuration, Test Integration, loop prevention, caching and basic error settings
  • DeferredMultiple triggers with a persistent Add trigger control
  • DeferredDedicated Initialization and Cleanup canvases
  • DeferredCustom error payload fields and the full diagnostic message
  • DeferredThe deletion warning that explains which later steps lose their data
The complete design in read mode. The rail’s second trigger was one of the deferred pieces.

What shipped, what was cut, and what I would change.

  • VerifiedShipped at the end of 2023, roughly three months after the concentrated delivery began, and still live at integry.ai.
  • Internal testA two-variant usability test on Maze before development, with people inside and outside the team. The feedback mostly confirmed the direction.
  • ReportedRoughly 30% fewer related support tickets, according to support. I did not see the underlying data, so it is directional, not measured.

What I can claim

The model, the three-month delivery, the test before development and the product being live. Not the 30% figure as measured, and not the four deferred capabilities as part of my release.

What I would do differently

Keep a baseline of the old builder and instrument task completion, configuration errors and support volume from day one. And validate the lifecycle model earlier, since it was the most distinctive part and one of the parts deferred.

What it taught me

Three months was enough to simplify a difficult interaction model, and not enough to prove it. A cutline is a design decision too: what ships first decides what people learn the product is.

Verified on the record: a live product, a public page or a project document. Internal test measured by me or the team, outside production. Reported someone told me; I have not seen the data.

Building something harder than it looks?

Open to Principal and Lead Product Design roles, in Dubai or remote.

umairyahya48@gmail.com

LinkedInResume