Low Code Platform Redesign
An end-to-end redesign of Temenos's low-code platform. I led the framing and the designer-facing experience, co-owning delivery with a cross-functional team.
A low-code platform lets people build software with very little hand-written code. That matters in banking, where the people who understand the business are not always engineers. Temenos had a powerful one, but it had been built by engineers for engineers, so the designers and business folks it was meant for could barely use it.
I led the redesign that opened the platform up to those non-engineers, focusing on letting them style and shape apps without writing code. I set the bar against the design tools they already trusted, so it felt familiar rather than intimidating.
- Benchmarked against Sketch to make the platform usable by designers and business stakeholders, not just developers
- Argued for a unified Micro Apps library over separate per-app libraries, with customisable views per app
- Project-level theming and multi-style widget support
- Micro Apps architecture with parent-child cascade
- Cross-platform preview across mobile, tablet, desktop and wearables
- Primary framing and structure of the redesign end-to-end
- Theming and styling system: making the platform approach Sketch-level capability for non-developer users
- Core experience decisions for how designers and business stakeholders interact with the platform
- Co-designer: shared ownership of the Micro Apps feature and several features within it
- 3 PMs (1 primary, 2 support): scope prioritisation, stakeholder alignment and delivery sequencing
- Engineering: underlying framework, deployment constraints and platform architecture
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.
The platform worked, but only for engineers. The redesign opened the same power to the designers and business stakeholders it was meant to serve.
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.
Alongside the Micro Apps decision, we set the bar for the styling and theming work: Sketch-level approachability for non-developer users. The existing tools were optimised for engineers. We wanted designers and business stakeholders to be able to apply colour, typography, and component styling without writing code or handing off to a developer. That meant building a styling system that matched the richness of the best design tool available at the time. I benchmarked the bar against the design tools these users already trusted, so "approachable" was measured against their real expectations rather than an internal guess.
The low-code market is crowded with enterprise tools. Understanding the competitive landscape helped identify where the platform could differentiate, particularly in its financial-services-first focus and cross-platform deployment model.
Two archetypes drove the design. The developer persona's reliance on cross-platform deployment and reuse shaped the Micro Apps architecture and project type model. The designer persona's need for styling control without code dependency defined the theming system and the Sketch-benchmark ambition.
A conventional business application consolidates everything into a single UI, creating loading challenges and making specific features hard to locate. Micro Apps solve this by dividing a monolithic app into smaller, independently manageable units. Changes at the parent level cascade across all child apps. Child-specific changes remain localised.
The platform supports multiple project types, each targeting a different deployment context. Mapping these was foundational to designing the creation flows: each type has different configuration requirements, and the onboarding experience had to handle all of them without becoming a decision maze for a first-time user.
The platform shipped six project types, each with its own creation and configuration flow. Every type imposed different constraints on the onboarding experience.
The high-fidelity designs focused on reducing cognitive load for complex developer workflows: clear hierarchy, contextual actions, and a clean canvas for building and managing applications.
A walkthrough demonstrating project creation, micro app configuration, and theming workflows.
One shared surface was the right move for the timeline. It got designers and business stakeholders into the platform quickly and proved the thing we were trying to prove. The obvious next step is role-based entry, where what you see is scoped to your actual job instead of everyone working in the same crowded space. I built the foundation to take that layer without a rebuild, so it's a clean addition rather than a do-over. Ship the shared surface, then specialise. I'd run it the same way again.
That is the summary. The full case study covers the research, the design decisions and the final screens in detail.
Password protected. Available on request via email or LinkedIn.