A 2019 redesign that still works
- Contribution
- Hands-on product designer; later Head of Product Design & Research
- Team
- Product Design, Research, UI Engineering, and Platform Engineering
- Timeframe
- 2019–present
- Outcome
- The interaction model designed in 2019 remains in production seven years later.
The original editor was powerful once you learned how to use it
Workato's first Recipe Editor had a significant product advantage: it described logic in simple English, guided builders step by step, fit substantial logic on one page, and became easier to scan on repeat visits. It was closer to “documentation that runs” than a conventional programming surface.
But that strength came with an adoption cost. The editor was text-heavy, less inviting at first glance, and easy to mistake for code. Indentation made nested logic, especially if/else conditions, harder to understand. Meanwhile, integration-savvy customers were becoming comfortable with more visual, freeform flowcharting tools.
We wanted to change the perception, not discard the model
I framed five requirements for the redesign:
- Create a better first impression - make the editor feel friendly, inviting, and modern.
- Improve immediate comprehension - help someone understand the logic before becoming an expert.
- Make it feel less like code - remove the impression that a business builder had to program.
- Use familiar visual conventions - borrow useful flowchart cues without requiring every author to invent a layout.
- Preserve what worked - retain the plain-English sequence, directed construction, compactness, and repeat-visit readability of the original editor.
A blind comparison tested the direction and exposed what could break
I developed an early direction for the redesign and partnered with research on a lightweight perception study. Nine customer groups at Dreamforce saw five randomized, unlabeled designs: the existing and proposed Workato editors and three competitors. Four interviews with sales and support added context.
The study was directional, not statistically powered. The proposed design received 24 positive associations compared with 13 for the existing editor. It was the only design never described as code-like and ranked highest for friendliness, ease, and understandability.
However, I found the contradictions to be more valuable than the score. The new direction felt approachable, but sometimes “basic.” Icons improved orientation but reduced information density. A more visual experience helped first-time comprehension, while returning builders still needed predictable markers and a stable structure.
The principles I used to make decisions
My early work was guided by three outcomes: simplicity, clarity, and confidence. In critiques, I used a practical test: could we remove an extra click, an unnecessary decision, or a second spent understanding what to do next?
These principles helped me balance the tensions revealed by the research:
| Principle | How I balanced it |
|---|---|
| Simplicity without dilution | Make the editor approachable without removing advanced capability. |
| Clarity without clutter | Add visual orientation while preserving the ordered logic. |
| Confidence without friction | Make consequences, errors, and recovery paths visible. |
| Efficiency without loss of context | Accelerate construction while keeping the whole recipe understandable. |
Keep the whole recipe visible while configuring a step
The most consequential layout decision was a stable split view.
The recipe remained visible on the left while configuration for the selected step opened on the right. Builders could work locally without losing the sequence, branches, current position, or system-level story.
This created a durable division of responsibility:
- Left / Recipe flow - always visible. The builder retains the sequence, branches, current step, and overall logic while working.
- Right / Step configuration - contextual and guided. Only the selected step opens for configuration, following the same learnable sequence each time.
Give every step the same setup grammar
I designed triggers and actions around a repeatable sequence:
| Step | Question I asked |
|---|---|
| App | Where does the work happen? |
| Connection | Which authenticated account should it use? |
| Action or event | What should happen? |
| Setup | What data and rules apply? |
Once builders learned this grammar, they could transfer it across hundreds of connectors and thousands of actions.
The consistency also created an extensibility contract. Recommendations, generated recipes, and later AI-assisted construction could enter a known structure rather than inventing a new interaction for every connector.
Let density adapt to the task
A long enterprise recipe and a short automation shouldn't demand the same information density.
- Zoom shifted between detailed editing and a compressed system view.
- Additional spacing preserved drag-and-drop targets when zoomed out.
- The Datatree could be minimized, used at a working size, or expanded for deeply nested schemas.
- Search and persistent optional-field controls replaced paginated configuration flows.
Match the interface response to the consequence of a change
Changing an app, a connection, or an action may look similar on the surface, but each has a different blast radius. I specified different recovery behavior for each:
| What changed | What happened |
|---|---|
| The app | Reset downstream selections, because the system had changed. |
| Only the connection | Preserved the selected event when it remained valid. If a custom event was unavailable, the editor cleared it and prevented completion until the builder chose again. |
| The action or event | Retained the app and connection, then moved directly into configuring the new selection. |
Reveal advanced capability at the moment of intent
Every input field began in plain-text mode. Formula guidance appeared only after the builder selected Formula mode.
Once active, the editor used the field's data type to recommend relevant transformations and documented them inline. The default experience remained calm, while advanced capability appeared when it became useful.
Make data provenance part of the object
Datapills visibly carried their source step number. An invalid mapping wasn't represented as a generic error.
Selecting the invalid pill exposed likely replacements. Choosing a replacement option cleared both the warning and its corresponding item in the “Things to fix” checklist.
Diagnosis, recommendation, correction, and confirmation happened in one loop.
Small interaction decisions made the system coherent
The working files were filled with decisions below the level of a feature list: focus behavior, selected and hover states, search highlighting, motion, keyboard shortcuts, responsive layouts, error hierarchy, and default open states.
Testing shouldn't feel like a separate stage
I didn't want builders to construct an entire recipe and only then discover whether it worked.
The editor organized building and testing as one continuous loop. Builders could make a change, run the workflow, inspect each step's input and output, and return directly to the recipe.
The interaction model encouraged four behaviors:
- Test early and often - testing was part of iteration, not final validation.
- See exactly what happened - step-level inputs and outputs made debugging visible.
- Skip without deleting - builders could isolate logic while preserving the structure under test.
- Resolve errors before running - the “Things to fix” checklist surfaced all design-time errors like missing connections and invalid mappings, then marked issues complete as they were fixed.
Safety continued beyond the editing session
Saving and exiting moved the recipe into read-only mode to reduce accidental changes. Permission-aware View and Edit modes clarified who could act. Every save created a version, enabling review, comparison, and recovery.
We migrated everyone while keeping the concepts familiar
The redesigned editor launched in 2020 across every plan. Existing recipes opened in the new experience, and there was no switch back.
This made conceptual compatibility essential. The launch established the model. Later releases increased speed, precision, and collaboration without destabilizing it:
Visual flow cues, guided setup, zoom, the resizable Datatree, View/Edit modes, error guidance, and integrated testing.
Formula guidance, search, copy and paste, remapping, live preview, dependency visibility, and job observability.
Visual recipe diffs made review and change comprehension first-class.
Copilot, recipe sketches, skills, Genies, and MCP reused the editor's structured workflow language.
A measurable example
One measurable example came from formula guidance. After it shipped, the 2021 roadmap recorded a 5.4% reduction in related support conversations. It was a modest metric, but it measured the intended outcome: an advanced task becoming more self-explanatory inside the product.
Make constraints about cognition, not fashion
Not every component designed in 2019 was perfect. Yet the editor remained usable over the years because its foundational decisions addressed stable human needs.
- The ordered flow was a collaboration protocol - it standardized how automation logic was authored and read across teams.
- The setup grammar was an extensibility contract - it allowed new connectors and later AI capabilities to enter a familiar structure.
- The split view preserved local and global context.
- Progressive disclosure protected both novices and experts - the surface stayed approachable as technical depth increased with new formulas, schemas, and control statements.
- Testing, versions, and provenance made change safer - iteration, troubleshooting, review, and governance were built into the lifecycle rather than added as administration.
The interface continued to evolve, but later teams didn't have to redefine how a recipe should be read, configured, tested, or understood.
The world of automation has expanded
In 2026, automation has grown beyond deterministic workflows. Agents introduce reasoning, delegation, knowledge, and tool selection as core parts of what our customers are building.
Agentic systems have become a central component of our orchestration platform, but their construction is distributed across multiple experiences.
Genies and recipes are already one system underneath
Agent Studio gives Genies a separate build experience. A Genie, however, uses skills, knowledge, handoffs, tests, recipes, and other Genies.
Many of those capabilities are built from the same top-to-bottom Recipe Editor language. Builders must nevertheless move between Agent Studio, recipes, skill configuration, knowledge, and runtime conversations to understand one system.
Agentic orchestration isn't linear
A Genie can delegate work to a specialist, receive the result, call a validator, consult knowledge maintained by another workflow, and continue reasoning.
A linear recipe alone can't represent those system-level relationships. A separate Agent Studio can't reveal the deterministic execution beneath them.
Bringing the concepts together requires a redesigned editor:
- A system view for orchestration, relationships, and handoffs.
- The ordered recipe model for deterministic execution.
- Contextual configuration for prompts, contracts, schemas, and permissions.
- Runtime traces showing agent choices, tool calls, knowledge use, inputs, outputs, and failures.
The goal is to design one coherent build system with representations that match the work.
Headless creation changes the role of the interface
Advanced builders increasingly create recipes through Claude, Codex, APIs, and browser automation. This establishes new requirements that the interface must meet:
- Express intent, constraints, approved connections, and reusable patterns before generation.
- Inspect AI-authored changes through diffs, provenance, dependencies, and blast radius.
- Approve, deploy, version, roll back, and govern generated work.
- Trace behavior across deterministic and agentic components.
- Keep human and AI edits synchronized and prevent stale-context overwrites.
What this work says about how I design
- I work from a point of view - I strengthened a constrained, directed model when the market favored open canvases because enterprise readability and lifecycle management mattered more for our customers.
- I translate principles into interaction rules - simplicity, clarity, and confidence were principles that determined layout, focus behavior, change recovery, information density, testing, and permissions.
- I stay in the details - my role included the small decisions that make a product feel coherent: target sizes at different zoom levels, selection behavior, error hierarchy, motion, recovery states, and when an action should become unavailable.
- I design the release and the runway - I separated the foundational model from follow-on capabilities, migrated customers without fragmenting the experience, and left room for the roadmap to compound.
- I treat trust as a product capability - visibility, provenance, reversibility, permissions, version history, and safe concurrency allow teams to move faster because the system makes consequences legible.