Redesigning how OneReach builds AI agents for enterprise clients.
PROJECT #2
2023–2026
No-Code Agent Builder
Role
Lead and sole product designer
Team
1 PM, 7 engineers, 1 QA, 3 solution builders
Timeline · Platform
2023–2026 · B2B enterprise, web
Key outcomes
Faster client launches
A retail client went live in days, not weeks, by starting from a ready-made agent.
A clear place to start
New users stopped asking “Where do I start?” The dashboard shows them.
Less time hunting for settings
Solution builders told us the new builder is “much easier to work with”.
Context
OneReach.ai was moving its enterprise clients from scripted chatbots to AI agents. The old approach led to low issue resolution rates, a heavy support ticket load and overly complex logic trees. Agent Builder was the product that had to make this shift possible.
But the product quickly outgrew its MVP. Building an agent meant digging through documentation and sometimes writing GraphQL. Even our own solution builders, the experts who build agents for our clients, lost time searching for settings and checking the docs. Every slow build meant a slower client launch. And some clients wanted to build parts of their solutions themselves, on their own accounts, so the tool had to be simple enough for them too. At the same time, competitors offered similar products that were easier to start with.
I joined as the sole designer to make building agents faster and simpler: for our solution builders first, and for the client teams who work alongside them.
Phase 1
When I started, Agent Builder was still an MVP. New features kept piling up, and the structure couldn’t hold them. Some flows needed GraphQL, and most labels were written for engineers.
I talked to our active users and collected about 18 pain points. Most of them came down to three things:
Hard to start. People kept the documentation open in another tab just to build a simple agent.
Hard to find things. The navigation didn’t help users understand where they were.
Hard to undo. There was no way to save a version or roll back a change.
Hypotheses
So I made three bets:
Help inside the product
If we add tooltips and a short tour, users won’t need to leave for the docs.
Hide the complex stuff
If we keep only core settings on the main screen and move the rest to an “Advanced” tab, beginners will move faster.
Let AI do the first draft
If an AI assistant builds a base agent from a short description, nobody starts from a blank page.
We never measured how much the tooltips helped. Later, the AI assistant and the Phase 2 dashboard took over their job.
We also added version history, so users could finally save and roll back.
The AI assistant turned out to be the most important change of the whole project. But I didn’t know that yet.
The “Advanced” tab felt like a clean solution. It cleared the noise from the main screen. But it also quietly split our users into two groups: Basic and Pro.
I only saw the problem in the second round of research.
My thought
First guesses are often wrong, and that’s okay. Testing them early with real users is worth more than months of upfront research. That’s the whole point of an MVP: learn fast, spend little, and double down only on what works.
Phase 2
The product kept growing, and the question got harder: what actually counts as “Advanced”? Users had to remember where everything was. Take a coffee break, and they were lost again.
This time I wanted to hear from less technical users, not only the power builders who knew the tool by heart. I started with a survey, but few people answered and it told us little. So I went back to interviews.
My thought
Honestly, I was a bit upset when so few people answered. But a survey is just a tool. If you can’t get quantity, go for quality. Interviews showed us how people really think, and workflows we never expected.
That’s where it clicked. What if the Basic/Pro split made no sense at all?
To check, I ran open card sorting with 6 users. They grouped features and named the groups themselves. Then I ran tree testing with 3 other users to test the new structure.
Users grouped features by context, not by how hard they were.
What we learned:
The “Advanced” settings weren’t advanced. Simple settings were hidden, while truly complex ones were spread all over the interface.
Users think in context, not in skill level. Features they saw as related lived on different levels of our navigation.
Nobody knew what “done” looked like. Users didn’t know where to start, or what was missing before release.
Talking to our solution builders added one more finding: they kept rebuilding the same agents from scratch for different clients.
These findings led to three changes.
What shipped
Hypothesis
If we group settings by context instead of skill level, users will find them on the first try.
Even after the first redesign, users still got lost looking for settings. The card sorting showed why: the Basic/Advanced split didn’t match how people think about building an agent.
So I rebuilt the navigation around context instead of skill level. Settings now sit where users expect them, and the core categories come first.
After release, solution builders told us the service had become much easier to work with. Some categories still have technical names, so there is still a bit to learn, but much less than before.
✓ Mostly confirmed
Naming still needs work.
Hypothesis
If the first screen shows what a finished agent needs, users will know where to start and what’s missing.
In interviews, one question kept coming up: “I don’t know where to start, and what is enough for the agent to be released.” Nobody could say what a complete agent looked like.
So I turned the first screen into a guided setup dashboard with a quick start checklist. It shows only the basics an agent needs to go live, and each card leads straight to the right setup page.
After launch, new users stopped asking where to start. Most of them stayed on this first screen, chatting with the AI assistant and watching the dashboard change as their agent took shape.
✓ Confirmed
Users could see where to start and what was missing.
Hypothesis
If we offer ready-made agents, teams will adapt them instead of building from scratch, and launch faster.
While talking to client teams, I noticed something: they often copied an agent that was already live and changed it, instead of building a new one. For them, editing was easier than starting from a blank page.
So I designed a library of the most popular ready-to-use agents, actions and channels. I also pushed for one more thing: giving each agent a personality. Every library agent got an avatar, a name and a proper place in the UI. I wanted building an agent to feel alive.
A retail client used a template to launch their agent in days instead of weeks.
✓ Confirmed
Teams adapted ready-made agents instead of starting from scratch.
Impact
For solution builders
They spend less time searching for settings, and they can start from a template instead of building every agent from scratch.
For clients
Faster launches, because teams start from a ready-made agent instead of a blank page.
For new users
The dashboard shows what a finished agent needs, so they know where to begin. Settings now sit where they expect them.
For the product
People now shape their agent by talking to the AI assistant, and use the UI to see what changed. With names, avatars and a personality, building an agent started to feel like creating a teammate.
Reflection
01
The AI assistant turned out to be the biggest change. Users stopped clicking through forms and started telling the chat what they wanted. The chat could build the whole agent for them, or guide them with questions. The UI became the place to see what changed.
We see the same thing across our other products: the chat becomes the main builder. And it solves the problem this project started with. Talking to a chat is much easier than reading a ton of documentation.
02
I could have done deeper research in Phase 1. But honestly, the most important insights only came later, when more real users started building agents. Small iterations helped us move faster and polish the UX better than one big redesign would have.
03
After the new UI was released, I noticed the Flow builder card on the dashboard had become almost redundant. MCPs now cover most channels and tools. Placing it wasn’t a mistake at the time, but it shows how fast things change with AI. Design has to be ready to let go of features.
Product designer
© 2026 Vitalii Dudka