Designing at Lleverage

4 min read

Introduction

This article reflects on my journey as Product Design Lead at Lleverage, but more importantly, it is meant to give practical insight to anyone designing AI first products. Lleverage started as a simple workflow tool and grew into a serious back office automation platform. That shift only happened because we understood where people struggled, simplified complex logic and adapted the product as the technology evolved.

My aim is to share what worked, what failed and what I learnt along the way.

Helping People Build Their First Workflow

When I joined, 89.23 per cent of saved workflows could not run. Not because users were unskilled, but because the product was inconsistent, full of technical jargon and expected people to understand workflow logic they had never used before.

I spent weeks watching recordings, interviewing power users and building flows myself. The problem became obvious. Users did not know what each step meant, what data they needed or why something was broken.

I redesigned the experience around clarity and predictability. Node cards explained themselves. Action modals used simple language. Validation surfaced issues in plain terms. The system taught you how to build rather than punishing you when something went wrong.

Failed workflows dropped to 24.46 per cent, and users finally built flows with confidence.

(image: node card with inline hints and validation)

Removing Integration Friction

Once users could complete workflows, the largest barrier became integrations. The platform expected people to write HTTP requests, handle authentication and understand JSON. Even Copilot could not help because every provider followed different logic. For most users, it was impossible.

This created a tension. Engineering could support everything, but the UX made it unusable. I designed an integration wizard to test guided patterns, but user testing showed it still felt too technical.

Then engineering told me something important. They could generate structured logic if we could identify which integrations users actually needed. So I shifted direction. I spoke to customers, interviewed power users, reviewed drop off paths and even built and shipped a request interface myself. We paired this with Copilot prompts to gather integration intent automatically.

With clear data, we built the integration library users needed. Clean provider cards. Simple fields. Predefined logic. Select a provider, fill the basics and you were done.

Drop off fell immediately. The lesson was simple. You cannot solve integration UX with clever UI patterns. You solve it by removing complexity and building only what people actually need.

(image: integration library with clean provider cards)

Designing for Real Back Office Processes

As larger clients joined, everything changed. Manufacturing, finance and logistics teams live inside legacy ERPs, spreadsheets and strict approval chains. They do not want endless flexibility. They want stability. Something explainable. Something that behaves the same way every time.

I joined their sessions, mapped real processes and watched how information passed across teams. This reshaped the product into a more opinionated experience with clearer states, structured flows and predictable patterns. Operational work depends on reliability, so the interface had to reflect that.

This period also involved some of the most impactful features I led. Data tables that made messy legacy information usable. Human in loop patterns that gave clients control over ambiguous AI decisions. Evaluations that tested workflows over time. While designing these, I protected existing mechanics and ensured no older experience regressions impacted day to day work.

(image: ERP flow simplified into a cleaner automation path + data table with enriched fields)

Redesigning the Workflow Canvas

As workflows grew more advanced, our original canvas could not support them. At that point, I am comfortable scrapping old work entirely rather than patching. The canvas had to be rebuilt, not tweaked.

I redesigned it around two needs. Beginners needed a gentle start, and experts needed structure for complex logic. Natural language creation helped new users build quickly. Clear mapping, stronger hierarchy and consistent behaviours supported large operational flows.

The result was a canvas that scaled with the user instead of forcing the user to scale for the canvas.

(image: updated workflow canvas with clean node connections)

Adapting to Fast Moving AI

AI changes often and unpredictably. At one point, a new model made Copilot slower and overly detailed. Usage dropped almost immediately. I diagnosed the issue, tested alternatives and moved to a faster model with equal intelligence. Usage recovered at once.

This taught a crucial lesson. AI behaviour is part of the interface. When the model changes, the UX changes with it.

(image: Copilot panel with concise responses)

Building a Mature B2B Product

As Lleverage became a serious enterprise platform, consistency mattered more than ever. I strengthened the design system, refined tokens, aligned naming and spacing, and wrote documentation that helped developers build accurately. This made the product feel unified and easier to scale.

In B2B, research works differently. Instead of huge user volumes, I focused on deep conversations with selected clients. These sessions revealed far more about operational needs than any large dataset could.

(image: design system token grid)

Conclusion

Lleverage grew because UX consistently removed friction and simplified complex systems. Users went from being unable to run a workflow to building full operational processes. Integrations became simple. Data became clear. Ambiguous decisions became manageable. The canvas adapted to scale.

And a strong design system held everything together.

My journey at Lleverage has been about taking technically heavy systems and turning them into something real teams can use with confidence. If there is one message worth sharing, it is this.

AI only becomes valuable when the experience is simple enough for real people to trust.