Integry · Flow Builder · Shipped at the end of 2023
The old builder gave you no help at all. The new model showed where logic could go, what still needed configuration, how to test it, and what to do when a run failed.
The existing builder was “very difficult to understand even for me as a designer. No guidance for the user.”
It handled one trigger and one straight line of actions. That was the whole model. There was no Initialization and no Cleanup, so nothing ran when a flow was switched on or off. Adding IF and Else logic was awkward, and once added it was hard to follow while you were still assembling it.
The interface also competed with the rest of the product. It kept Integry’s normal navigation and surrounded the work with panels on the left, top, and right. People were building a system of dependencies inside what still felt like another screen in the application.
The structural problem mattered more than visual polish. A flow can be valid to a system and still be unreadable to the person responsible for changing it. The redesign had to make branching, loops, incomplete setup, and operational states understandable before users pressed publish.
I used support tickets, FullStory session recordings, and feedback relayed through Sales to understand where people became uncertain.
Integry is an embedded integration platform. Customer companies use it to build connections and workflow experiences that appear inside their own products. That changed the consequence of confusion. If a builder was difficult for an Integry customer to operate, the resulting failure could surface inside that customer’s product and become their support problem.
The audience would not fit a single assumption about expertise. 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. One interface had to support both without turning every simple action into engineering work.
I was Team Lead, and I ran the design process end to end with a Product Manager. After one designer left soon after I joined, I managed and supported a junior designer day to day. I remained hands-on and designed most of the Flow Builder myself, including the custom-code block available for triggers and actions.
I used progressive disclosure by expertise rather than separating users into two different products.
For a less technical user, the builder generated a plain-English title such as “When contact created in AcmeSaas, create contact in Hubspot.” App icons identified the source of each action. IF, Else If, and Else used compact badges. Dashed insertion rows showed where another step or branch could be added.
“Needs configuration” stayed visible on incomplete nodes without blocking the rest of the flow. That decision let users assemble the structure first and return to details later. A wizard would have forced one sequence and hidden the relationship between unfinished parts. The canvas instead kept the whole journey available while marking what remained unresolved.
For developers, the same picker exposed Make HTTP Call, Receive HTTP Call, JSON examples, system operations, custom code, and output caching. Filters separated the host app, other apps, and system operations. The interface did not remove technical capability. It gave that capability a clearer place.
He understands the requirements and he’s great at designing a product as per the user’s needs.Fatima Ashfaq, Customer Success Manager at Integry
I explored more than five or six variations before committing to the full-screen model. The working file documents seven creation-exploration rounds, plus four architecture studies and six studies focused on adding and removing steps.
Earlier directions kept Integry’s navigation and distributed controls across several panels. I rejected that model because the chrome competed with the flow. The full-screen modal gave the canvas enough space and kept form settings available without making them permanent visual noise.
A free-form canvas can express complexity, but it also asks users to arrange it. I chose a vertical reading order with indentation and dashed connectors. The system controlled layout while users concentrated on sequence, conditions, and data.
“Add step,” “Add Else IF,” and “Add Else” appeared as dashed rows wherever the structure allowed them. I rejected hiding every option inside an overflow menu. Permanent insertion points turned the canvas into a guide to what could happen next.
Users could build a complete shape while nodes still showed “Needs configuration.” I rejected a strictly blocking wizard because integration setup is rarely completed in one uninterrupted pass. The warning preserved momentum without pretending the flow was ready.
The picker gave actions and IF or Loop controls distinct columns. I rejected one mixed list because an app activity and a logic operator do different jobs. The separation made the decision understandable before a user searched.
The generated sentence in the header summarized the flow in ordinary language and remained editable. Beta and production tags exposed environment context. The design helped someone understand what a flow did before opening every node.
The Head of Product and CEO introduced the lifecycle idea. I translated it into a navigable structure that made setup and teardown part of the flow instead of invisible implementation detail.
Initialization ran once when a flow was enabled, so it could register a webhook or do other setup work. Cleanup ran once when the flow was disabled, so the system could delete that webhook and undo what setup had created. Between the two, the Triggers section could hold more than one trigger, each with its own step count and status.
The left rail was not a normal step list. It was a lifecycle. Green checks and red X states made operational readiness visible, while the central canvas remained focused on the selected stage. This was the clearest structural difference between a flow as a diagram and a flow as something that has to operate over time.
Customers told us the default error notification did not provide enough information to act. Support tickets, recorded sessions, and Sales feedback reinforced that a failed run needed more than an error label.
I designed the run-failure experience, including retry and abort configuration. Error notifications were set up at account level, then customised at flow level. The default payload specified the network code, raw API response, Run ID, Flow, User ID, User Auth, Flow ID, and a deep link into the steps of the failing run. A user could append flow-specific information without replacing the diagnostic baseline.
Safety also had to appear before failure. Two-way sync could create a loop where each app repeatedly triggered the other and consumed billable tasks. Loop prevention came out of real customer incidents and a preventive product decision. The setting stated the consequence directly: enabling it could affect task consumption.
I threaded testing through the builder instead of saving it for the end. “Test Integration” stayed available across the working states. Beta and production tags clarified environment. Disabled conditions had their own designed state. When a user deleted a step, the final warning explained that dependent steps would receive empty values rather than using a generic irreversible-action message.
View error details here:app.integry.io/wapp/view/flow/1788/flow/123021/run/flow-123021-app-123-hooktype-pre_save/steps
Add additional data to the notification here
e.g.
Before development began, I put the design in front of people rather than assuming it read the way I intended. I connected the Figma prototype to Maze, wrote the task and validation questions step by step through the flow, and ran two variants against each other. It went to people inside the team and to participants outside it.
The result was not a reversal. The feedback mostly confirmed the direction, and I reflected it into the design before anything went to development. That is a weaker story than a test that overturns a design, and it is still the difference between shipping a belief and shipping something that had been checked.
Development accelerated during an October 2023 hackathon. The redesigned builder shipped at the end of 2023, roughly three months after the concentrated delivery began.
The CEO and Head of Product set the launch cutline. I compared the Hackathon page in the working file with the complete Flow Builder page to separate what reached that release from what remained in the final design.
| Capability | Launch status |
|---|---|
| IF, Else If, Else, loops, action and control-step selection | Shipped |
| Needs Configuration, Test Integration, loop prevention, caching, and basic error settings | Shipped |
| Multiple-trigger support with a persistent Add trigger control | Deferred |
| Dedicated Initialization and Cleanup lifecycle canvases | Deferred |
| Custom error payload fields and the full diagnostic message | Deferred |
| Dependency-aware deletion warning | Deferred |
Support later reported roughly a 30% reduction in related tickets. I did not see the underlying data, so I treat that as directional feedback rather than a measured case-study outcome.
The stronger proof is observable. The product shipped, and the Flow Builder remains live at integry.ai. Integry’s current documentation still shows the same core model: multiple triggers, custom HTTP calls and code, control steps, testing, and error notifications. I use that only as evidence that the product remains live, not as proof that every current capability was part of my 2023 release.
The three-month delivery proved that we could simplify a difficult interaction model quickly. It also made the missing evidence clearer.
If I approached it again, I would preserve a stronger baseline of the old builder and instrument task completion, configuration errors, and support volume from day one. That would make the effect of each decision easier to verify after launch.
I would also validate the lifecycle model earlier. It was one of the most distinctive parts of the design and one of the capabilities deferred from the first release. A clearer cutline earlier in the process would have helped the team decide whether that operational model belonged in the first proof or the next deliberate release.
