Colour-coded node categories as visual grammar
Events (orange), Actions (purple), Conditions (blue) form a consistent visual grammar across every surface: tabbed palette, canvas nodes, drop zone borders, config panel badges, and template previews. Scanning a complex automation reveals its structure at a glance — "what triggers," "what happens," and "what decides" are all visually distinct.
This departs from the current builder where all nodes share the same visual weight. Unconfigured nodes reinforce the system with a dashed coloured border and dot indicator, making it obvious which nodes still need setup. The colour coding also extends to the entry point picker, where app events use brand colours (Shopify green, Patreon coral) layered on top of the category colour.
beehiiv v4, n8n — colour-coded node types
Animated gap insertion for drag-to-insert
When dragging a node from the palette, existing nodes animate apart to show where the new node will land. This "make space" animation gives spatial feedback that static drop indicators can't — the user sees the automation physically opening up to receive the new step. The entry trigger is locked in place (no insertion above it), so the animation only activates between and below existing nodes.
Click-to-append is the simpler path: click any node in the palette to add it at the end. Drag-to-insert is the power-user path for precise placement. Both routes end at the same config panel, which auto-opens on addition.
Linear, Notion — drag-to-reorder with animated gaps
Floating panels over fixed sidebars
The node palette, config panel, and entry point picker are all floating cards rather than fixed sidebar panels. This keeps the canvas as the primary surface — panels overlay it rather than shrinking it. The config panel appears on the right, the palette on the left, and both can be open simultaneously without competing for space.
The sidebar collapses from full navigation to icon-only (K logomark) when entering the builder, freeing horizontal space. The breadcrumb in the secondary header ("Visual Automations / My Automation 1") provides the navigation escape hatch back to the index.
Figma, Miro — floating tool panels over canvas
Entry trigger as locked anchor node
The entry trigger (first node) is locked: it can't be moved, deleted, or have nodes inserted above it. The three-dot menu shows a greyed-out Delete with "Entry point can't be removed." This prevents accidental removal of the automation's starting condition and establishes a clear top-of-flow anchor that all other nodes build from.
A T-bar (inverted T) connector appears before event nodes, visually representing the subscriber gate — the point where subscribers enter the automation. This is a new visual element not in the current builder.
Mailchimp Customer Journeys — locked trigger pattern
Default path as opt-in for event nodes
Non-entry event nodes can optionally have a default path — a fallback route for subscribers who don't satisfy the event condition (e.g. abandoned checkout). This is toggled via a + button on the right side of the node or in the config panel. The path routes vertically (not horizontally), consistent with the ECO-3455 constraint that event nodes must only route downward.
Making this opt-in rather than always-on avoids visual clutter on simple automations while preserving the power for advanced use cases. The default path appears as a secondary branch below the event node.
ECO-3455 — vertical-only event node routing
Progressive disclosure in config panels
Config panels use pill-style toggle buttons to show and hide dependent fields. A "Joins a form" event starts with just a form scope toggle (Any form / Specific forms); selecting "Specific forms" reveals a searchable multi-select dropdown. This keeps the default config simple while allowing full customisation.
Each field type is purpose-built: searchable multi-select dropdowns with select all/clear for tags and forms, "Create new" buttons for forms/segments/sequences, and event-specific configs (custom field conditions, product source, date type, link triggers). An unsaved changes warning modal with "Don't show again" checkbox prevents accidental data loss when navigating away.
Kit design system — progressive disclosure pattern
App events and actions with brand identity
App nodes (Shopify, Patreon, Kajabi, Slicktext) are grouped under "Apps" dividers in the palette with bold app names. In the entry point picker, app events use the app's brand colours (Shopify green, Patreon coral) for immediate recognition. "New" badges on 7 event types signal recently added capabilities.
This separation between Kit-native and app nodes prepares the builder for the app-developer template ecosystem (PROD-233). As third-party developers add custom triggers and actions via the App Store, the grouped layout scales without mixing app-specific events into the core Kit event list.
PROD-233 — app-developer templates roadmap
Template previews with interactive flow canvases
Each of the 6 templates renders its automation flow as an interactive canvas preview with pan, zoom, and fit-to-view controls. The modal is expandable to a larger view. This lets creators see the actual structure of what they're about to build — colour-coded nodes with branching — before committing.
"Use template" carries the flow into the builder pre-populated. The variant toggle controls whether templates show a preview modal or go directly to the builder, testing whether the preview step increases or decreases template adoption.
Mailchimp — template detail page pattern
Variant system for structured design validation
Four toggle switches let reviewers compare different experience paths: Index state (Empty/Populated), Creation path (Text-first/Builder-first), Template preview (With preview/Direct use), and Unconfigured nodes (Dashed border/Dot only). Each toggle produces a distinct experience using the same underlying data.
This separates the "what should we build" question from the "how should we build it" question. The team can validate which experience path performs best before committing to an engineering investment, and new hypotheses can be added as toggle states without rebuilding the prototype.
Q2 roadmap — "new frontends" direction