Low Code Platform Redesign

The platform could do a lot, but only if you thought like an engineer. The designers and business folks who were meant to build on it kept hitting walls, so the work quietly funnelled back to the developers it was supposed to free up.

The platform had strong technical depth but the experience had not kept pace. Developers could use it, but designers and business stakeholders were largely locked out. In financial services, where both groups need to build and configure applications, that gap was a real cost.

Underneath the general problem sat a structural one. An app was built end to end as a single unit, so shipping one new feature on top of an already-live MVP meant redeploying the entire application just to make that one feature live. None of that stopped a developer. All of it stopped everyone else.

The core structural question for Micro Apps was how to organise the library, a decision that shaped how teams would work at scale and how changes would propagate. My starting assumption was separate libraries per app, which looked cleaner in isolation. Working it through with my co-designer and the engineering lead surfaced the flaw: at scale, teams would diverge and parent-level changes would not cascade. That pushed me to a unified library instead, and I checked the approach against how the best design tools handle shared components before committing.

The low-code market is crowded with enterprise tools. Looking at the other tools helped me see where this one could stand apart, mainly its focus on financial services and the fact that it deployed across platforms from one build.

Two archetypes drove the design, but they were not equal. The developer remained the primary user: the platform's core workflows, the Micro Apps architecture and the project type model were all shaped by the developer persona's reliance on cross-platform deployment and reuse. The designer was the secondary, newly-served user, and their need for styling control without code dependency defined the theming system and the Sketch-benchmark ambition. The redesign widened the door for designers and business stakeholders without moving the developer out of the centre.

A typical business app crams everything into one interface, which makes it slow to load and hard to find anything. Micro Apps break that single heavy app into smaller pieces you can manage on their own. Changes at the parent level cascade across all child apps. Child-specific changes remain localised.

Once a Micro App owned its own styling and assets, not just its scope, it became a genuinely portable unit. It could be published and pulled into another project through Visualizer's Marketplace instead of being rebuilt from memory every time. Reuse stopped depending on tribal knowledge.

The platform supports multiple project types, each targeting a different deployment context. Mapping these out came first, before the creation flows: each type needs different configuration, and the setup experience had to handle all of them without becoming a decision maze for a first-time user.

The high-fidelity designs were about keeping dense developer work manageable: a clear hierarchy, actions that show up where you need them, and a clean canvas to build and manage apps in.

A walkthrough demonstrating project creation, micro app configuration, and theming workflows.

Once Micro Apps shipped, the same question went further. Could the people who couldn't code build conversational, AI-driven experiences too, not just static screens?

Worth placing in time: this was 2022, before ChatGPT, before "agentic" was a word anyone used for software. There was no obvious playbook for letting non-engineers author conversational logic. What we were really building toward, giving people a visual way to compose intents, responses and branching behaviour, is close to what the industry now calls agentic experiences. We were designing in that direction before the language for it existed.

I stayed on as the primary designer for the next extension of the same platform: letting non-engineers build conversational, chatbot-driven experiences without writing code. A second designer supported on an as-needed basis, a lighter structure than the equal co-ownership on Micro Apps.

This shipped after I moved on from Temenos. I can speak fully to the design, the reasoning, and the research behind it, but I didn't see it land with real users.

The platform could now let non-engineers build interfaces. The next ceiling was conversational logic: branching dialogue, intents, and responses, a fundamentally more complex authoring problem than static screens. Nobody had asked whether the same "non-engineers can build this" thesis would hold up against something with real logic underneath it, so this was as much a question as a brief.

A flow canvas is mostly states you hope nobody sees. A finished screenshot shows it working. Here is what each broken or in-between state looks like, and how it behaves.

The severity ladder is a design decision, not a technical one. Get it wrong and the tool becomes either dangerous or naggy.

Keyboard handling got the same weight.

Motion is specced, not decorative. Each moving element has to justify its place. The bars show relative duration.

Every row has a reduced-motion equivalent that changes state instantly. Motion only ever explains something already true underneath it. A row that could not justify that last column got cut.

Before designing the Flow Editor, I studied Google's own Dialogflow, both the classic intents-and-entities model and Dialogflow CX's flow-based builder, to understand how a team that builds this for a living structures conversation logic. Nobody asked me to do this research, it came from wanting to know what good already looked like before designing my own version.

Reference material used: a public Dialogflow overview video, cited in the original spec deck. It's been a couple of years, so I'd describe this research as something that shaped my point of view going in, rather than claiming a one-to-one influence on any single feature.