Crosswise Workflows
Preview
Introduction
Crosswise Workflows
Workflows were Crosswise's primary automation primitive — node-based logic graphs where compliance teams could string together agents, Python execution, email delivery, and event triggers to either synchronously or asynchronously automate processes end to end. A bank's complaints intake form, for example, could automatically trigger a workflow upon submission, route the data through an AI agent for classification, and surface structured outputs to the relevant compliance team for review and further action.
Role
Designer, Frontend Engineer
Tools
Figma, ReactJS, Typescript
Timeline
2 weeks
The Problem
Workflows were technically functional but too complex to demo or understand without constant engineering support
Ideally workflows were something a typical user could at least make sense of, but in reality workflows were tools for our engineers built for engineers or heavy power users. The node graph interface surfaced every technical detail at the default view level — ports were labeled with raw identifiers like string_id rather than human-readable names, and nodes with many connections grew tall enough to make the graph visually unreadable. Connecting nodes required knowing exactly which output port to drag from and which input port to target — a level of specificity that was opaque to non-technical users and even for some of us internally.
The configuration experience compounded the issue. Setting up a node meant navigating a modal dense with low-level options, full-width buttons inconsistent with every other UI pattern on the platform, and helper text beneath every field that made the interface feel like documentation rather than a product. There was no visual hierarchy, no sense of what mattered versus what didn't.
The result was a workflow canvas that was technically functional but practically inaccessible — and critically, one that failed in the context that mattered most for an early-stage startup: the sales demo. Workflows were a centerpiece of Crosswise's value proposition, but their complexity made them difficult to demonstrate convincingly to prospective clients. The interface communicated engineering effort rather than user value.
Competitive Analysis
Zapier and Figma Prototype mode
Lofi
I started by reviewing our current workflows, all the interactions and flows and ui components used, and did a design critique of it all on paper which is what you see on the left here.
A few patterns emerged from that pass that went beyond workflows specifically. Visual clutter wasn't a workflows problem — it was a platform-wide pattern. When features were built at speed by backend engineers before reaching design, the result was interfaces that were functionally complete but visually unresolved. Every option surfaced at once, every field given equal weight, every component competing for more and more space. This wasn't a criticism so much as an observation about how early-stage product development works — shipping comes first, design passes come after. Knowing that shaped how I approached the redesign: rather than treating each problem as isolated, I looked for the smallest number of principles that could address the most surface area.
3 themes inspired the decisions I ended up making for workflows.
1
Visual Clutter
Too much information exposed at the default view level, making the interface feel overwhelming before a user had even done anything.
2
Progressive Disclosure
The system had no sense of what a user needed now versus later. Everything was treated as equally immediate.
3
Competing for limited space
Space, especially horizontal space, is limited and the more things you want to show, the more those things compete for that limited resource.
Hifi
1. Simplified Nodes
The first and most visible change was to the node graph itself. Previously, every port on every node was exposed by default — inputs and outputs listed explicitly, labeled with technical identifiers, making even a simple three-node workflow feel like a circuit diagram.
The redesign centered around a central question: from the graph view, what do users actually need to see? The answer reduced the node design to something far simpler with just the node name, type, and a single universal port for outputs. This made our workflows scannable at a glance and reduced the space nodes took up in the graph by up to 70% in some cases.
2. Intent Driven Connections
The original connection model required users to identify the correct output port on one node and drag precisely to the correct input port on another which proved to be an error-prone and cognitively demanding process.
Inspired by Figma's prototyping interaction, I redesigned this to be intent driven. Users drag from a single universal output handle on any node to any other node to establish a connection. Port mapping and configuration happen afterward, inside the connection itself — surfaced only once the structural intent is already expressed.
Redesigned Connections
3. Configuration Modal Redesign
With the canvas simplified, the configuration modal was the next friction point. The before state read more like a developer settings panel than a product interface: full-width save buttons inconsistent with every other UI pattern on the platform, helper text beneath every field turning the modal into a wall of instructional copy, and tab-based navigation that offered no sense of information hierarchy.
The redesign addressed each of these systematically. Tabs were replaced with a sidebar navigation, giving users a clear map of the modal's sections at all times. Helper text was removed where the field labels were self-explanatory, restoring visual breathing room. The save button was moved to the bottom right as a contained action, with secondary actions like delete and reset given appropriate visual weight rather than competing for attention.
Development
My implementation touched both the graph rendering layer and node configuration UIs. Eventually I also worked on maintenance, debugging, and branding workflow result emails
Shipped
Takeaways
Features vs Principles
The core of every decision here was the same: hide what the user doesn't need yet, surface it when they do. Progressive disclosure, then, became less about redesigning a feature and more about integrating a principle which propagated throughout the product onward.
Interaction models can be borrowed across contexts
Figma's prototyping UX was designed for a completely different use case, but the underlying interaction pattern — connect first, configure second — mapped directly onto a problem in a different domain. Looking outside your immediate competitive set often surfaces better references than looking within it.
Reality of tradeoffs
Since Crosswise was as small and as fast as it was, tradeoffs were a real thing and this was just one project that gave me insight into that. In reality, not every feature will follow a clean design process before implementation, in fact it might get built before its designed. Being the sole designer at this company, I had to come to terms with that reality.
