An Idea, Some Wireframes, and a Wide Open Problem.
The founder of Rolai came to us with a compelling premise: an AI-powered productivity platform for small businesses. The core proposition was three-layered:
- a chat interface for interacting with leading LLM models
- a curated library of ready-to-use prompts for everyday business tasks
- a Knowledge Store that would act as context to make every response more accurate and relevant.
What made this engagement distinctive from the start was the honest uncertainty around it. We were designing for a broad audience in a space most users weren't yet familiar with. There was no validated playbook. The founder wasn't locked into a single user group, which meant we had to treat every feature decision as a hypothesis and every client conversation as a research opportunity.
"With the average user not yet familiar with the capabilities of AI, our process centered on building a working prototype quickly so people could see, not just imagine, what was possible."
A Growing Team, and How We Worked
I was the only designer on this engagement, working directly with the client's founder and reporting to him throughout. What started as me and 4 developers grew, over two years, into a team of 15 developers, 3 QA, and 1 product manager on our side, plus 2 stakeholders on the client team, with additional external stakeholders from pilot programs joining along the way.
A traditional, structured design process wasn't the right fit for a product with this much ambiguity, so we kept it intentionally light. A founder conversation could turn into a shipped feature in days, not weeks. The team would use it internally while the founder demoed it to prospects, and we'd decide from there whether to build on it or shelve it.
From One Client's Problem to a Platform Capability.
The platform grew into several interconnected capabilities (Chat, a Prompt Library, Knowledge, and Agents), all designed in depth and shipped. This case study zooms into Flows, where the most interesting design tradeoffs showed up.
The basic platform was working, but a new client engagement forced the team to think at a different scale. A mortgage company needed to batch-process hundreds of PDFs, extract specific data fields, auto-fill forms, and operate through a custom interface built for their exact workflow. That pushed us toward the first version of Flows: a set of actions that would run based on specific triggers or schedules to automate multi-step tasks.
Why AI Flows Came First
We needed something fast enough to bring end users into a pilot program and speed was a condition of moving forward at all. A mix of manual building and AI interpretation was the fastest path. Users would add actions and triggers manually, configure them with a natural language prompt and have the AI figure out the exact configuration at runtime.
Why We Rebuilt Them
We spent about six months trying to make AI-interpreted flows reliable enough for production use. Hallucinations and misinterpretations kept surfacing in ways that cost hours of debugging every time. Eventually the dev team reached a point where they felt there wasn't meaningfully more they could do to improve reliability within that approach.
We gathered to discuss it, and the team moved toward rebuilding Flows on deterministic logic: user-defined steps, no runtime interpretation, predictable execution every time.
Shipping the AI Layer in Phases
Deterministic flows solved reliability, but they created a new problem: building flows became something most end users would find hard to do. The learning curve was large. If we shipped deterministic flows without anything else, we'd have a reliable feature that would require a developer's help to use.
As a team, we knew an AI-assisted layer would be important to make deterministic flows usable. But with a backlog full of other equally high-priority items, we took the AI-building work in phases rather than all at once. First, we let users build the basic flow and its configuration with AI. Extension-related settings and the ability to build a custom interface were left for a later phase, once we had more time to give them the attention they needed.
From Activity Log to Inbox.
The first version of flow activity was a straightforward log: one column, chronological. It worked fine until flows started including conditions, loops, and human-in-the-loop steps. Once a flow could branch, wait on approval, and loop back, a single-column log got hard to scan. Too much was happening at once for a linear view to hold. I redesigned it as a two-column layout to give the branching room to breathe.
But cleaning up the log design surfaced a bigger question: did most users actually need to look at it at all? About 70% of flows were scheduled or triggered by another application, running entirely in the background with no one watching. Even for the manual 30%, people mostly cared about two things: the end result, and whether something needed their approval. Getting to that meant opening a specific flow, finding its activity, and hunting for the pending approval inside it. That was a lot of clicks for something people needed to do quickly and often.
So instead of continuing to refine the activity log itself, I designed an inbox. A single place to see everything waiting on a human action, whether that was an approval or a flow that had paused mid-run needing more input, without having to go hunt down which flow it belonged to. The inbox could also be extended in the future to quickly get to deep-reasoning chat responses and other AI-related content the user is waiting on while working on other tasks.
Building the inbox also accounted for who our users actually were. We'd designed around our original small-business assumption: that most people in an org would both build and use flows. In practice there was a much sharper divide. A small group of admins built and distributed flows, and a much larger group of end users only ever used them. The inbox worked well for exactly that split. It let end users live in one focused space without ever needing to touch the builder, which also lined up with permissions work we already had planned for separating creator and user access.
Combining Actions on the Canvas.
As flows got more complex, the dev team started running into a specific failure mode: some actions depended on information a previous action needed to retrieve first, and users building flows had no way of knowing that dependency existed.
Where it stands today
AI-assisted building handles the hidden dependency behind the scenes, so nobody is blocked when creating flows. But the canvas still shows the retrieval step as its own block, sitting there with no obvious reason for existing. On a complex flow that makes the canvas harder to scan, and when something breaks, an unexplained step makes it harder for creators to diagnose, which means they lean on us for support more.
What I proposed
Combine dependent actions into a single, higher-level action wherever the dependency is implicit. Instead of two blocks ("get email body", then "reply"), one "respond to email" action would handle both. The retrieval is folded underneath rather than sitting on the canvas, and users see one action for one intent.
Why it isn't built yet. Once AI-assisted building shipped, this went from "immediate problem" to "nice to have". The AI was already compensating for it, so nobody was blocked. I've flagged it as a future improvement, since it still matters for canvas readability and diagnosis as flows scale up, even though it stopped being urgent.
Real Time Back, Not Just a Demo.
3+ Sectors Onboarded
The platform expanded beyond its initial small-business focus to serve clients across multiple industries, with each engagement broadening the platform's capabilities rather than fragmenting them.
Hours & Days Back to Users
From 2 days down to ~3 hours in one workflow; from a few hours down to a few minutes in another. Different magnitudes, same pattern: real time back to the people using it.