Appsmith is an open-source platform that lets backend developers build and deploy internal applications without front-end expertise. Developers drag widgets onto a canvas, configure them through a property pane, and write JavaScript where they need logic.
I was brought in to design a no-code solution for creating workflows — the behaviour that happens when a user interacts with a widget. I owned the interaction model and visual design end-to-end, working with a PM to define requirements and a design manager for final review.
See product →Before this feature, adding behaviour to a widget meant writing JavaScript. That worked for developers who were comfortable with code — but Appsmith's whole premise is that not everyone building internal tools needs to be. For users who weren't confident writing JS, widgets sat largely static. The more powerful the platform became, the wider this gap grew.
Research and user interviews confirmed the hypothesis: there was real demand for a no-code way to attach actions to widgets, and it was blocking a portion of users from building anything meaningful at all.
The insight from research that shaped the entire design: users who needed no-code support rarely needed more than two steps. Define what happens on success and what happens on failure — that covers the vast majority of real workflows. Users building something more complex than that almost always knew JavaScript and would write it themselves. The design didn't need to be a full visual programming environment. It needed to be exactly two steps, done well.
The hard constraint on this project was spatial: the action selector had to live inside the existing property pane sidebar. Adding a new full screen would have broken the established interaction pattern of the platform — the property pane is where widget configuration happens, and that pattern had to hold.
Most competitors had built elaborate, full-page workflow builders. We couldn't replicate that, and once I understood the two-step insight from research, I realised we didn't need to. The constraint and the finding pointed in the same direction: keep it small, keep it focused, and trust that users who need more will write JavaScript.
The action selector drops down inline from a widget event — the moment a developer clicks to configure what happens on a click or search, the selector opens in context. Step one: choose an action from a categorised list. Step two: define what happens on success and what happens on failure, each of which can itself chain to another action. That's the full depth of the no-code path.
Callbacks — the on-success and on-failure branches — are surfaced directly in the property pane as collapsible sections, so developers can see the shape of a workflow at a glance without expanding everything. The component handles the common case cleanly and steps aside for JS when users need it.
User testing confirmed that people understood how to use the action selector to create workflows without guidance. Minor usability issues surfaced and were fixed before release — nothing that required rethinking the model, which validated that the two-step structure matched how users were actually thinking about the problem.
Callbacks created
+62%
rise in second-level actions after launch
Complex workflows
Up
more users building multi-step flows than before
The 62% rise in callbacks is the clearest signal: users weren't just adding single actions anymore — they were building conditional flows with success and failure branches. The feature unlocked complexity that existed in the platform but wasn't previously accessible without writing code.
What this project taught me
The competitive research initially felt like a constraint — everyone else had built elaborate workflow builders and we couldn't. But the research finding made the constraint irrelevant: our users didn't need an elaborate workflow builder. They needed two steps done clearly. Designing less, on purpose, because the data said so, is a different thing from designing less because of time pressure. This was the former.
The spatial constraint — fitting everything into the existing sidebar — pushed the design toward something more focused than a blank canvas would have produced. Constraints that feel like limitations often just are. But occasionally they're doing design work for you.