Orbina V3

The result, first

More than 20 enterprise brands now run over 50 Orbina agents in production.

A team can configure an agent once and use it across a website widget, WhatsApp, Instagram, or an embedded mobile experience. Each channel behaves differently, but the agent, its knowledge, and its core behaviour stay connected.

This was a team effort. Engineering built the platform, the AI team worked on answer quality and orchestration, and the commercial team kept us close to the market.

My area was everything between that system and the person using it. I mapped the product flows, designed the interfaces, worked through edge cases with engineering, and built a large part of the frontend.

Where I started

I was the designer on Orbina V1. I designed the dashboard, shipped the widget, and then watched what happened when enterprise customers started using it.

That part changed how I work.

The biggest problems were rarely isolated screens. They appeared between screens and systems. A widget worked in a browser but failed inside a mobile app. A setting looked correct but behaved differently after deployment. Knowledge was uploaded twice because it was unclear what the agent was actually using.

I started looking beyond the interface in front of me. Who made the change? Where did it go? Which customers would it affect? What happened if it failed?

I kept designing in Figma, but I also started building the frontend myself. Debugging my own work made weak assumptions obvious very quickly.

Why we rebuilt it

The AI improved quickly, and customer expectations moved with it. Adding more features to V1 would not solve the problems we were seeing.

The team decided to rebuild the platform around a clearer model. Agents, channels, and knowledge became separate parts of the product instead of being packed into the same configuration.

My role was to lead the product side of that change. I mapped the new workflows, defined how the concepts should appear to users, worked through requirements with engineering, designed the experience, and implemented much of it in the frontend.

V3 did not need another layer of polish. It needed a structure people could understand.

Agents, channels, and knowledge

V3 separates three ideas.

Agents define how the experience behaves. Knowledge gives an agent information. Channels determine where conversations happen.

One agent can work across several channels. Each channel keeps the settings needed for its environment. A team can also change which agent serves a channel without rebuilding everything around it.

This sounds obvious now. It was not obvious in V1.

The widget used to be tied too closely to the agent. Styling, behaviour, and deployment were mixed together. That made other channels difficult to support and made changes harder to reason about.

My job was to turn the new model into something an operator could use without understanding the platform behind it.

At each step, the interface needed to answer:

• What am I changing?

• Where will the change appear?

• What should I check before customers see it?

Channels have different rules

A website visitor expects a quick response because they are looking directly at the chat. A WhatsApp conversation can be more asynchronous. Instagram has its own interaction patterns. A widget embedded inside a mobile application also needs to communicate with the application around it.

We wanted one agent to work across these surfaces without pretending that every surface behaves the same way.

I mapped these differences with engineering and designed the channel flows around them. The product still feels consistent, but each channel can present the settings and information relevant to its environment.

Mobile embedding was one of the harder cases.

In V1, closing and controlling the widget depended on assumptions about the host application. In V3, we created a clearer way for the widget and the application to communicate.

I also designed the channel detail page to explain this behaviour to mobile developers. They should not need a meeting with our team just to understand what the widget sends and what their application needs to handle.

Knowledge people can inspect

V3 treats knowledge as something teams maintain, not just something they upload.

Operators organize information into knowledge bases and connect those knowledge bases to agents. Several channels can then use the same source instead of maintaining separate copies.

The customer should receive a clear answer. They do not need to see how retrieval works.

The person managing the agent needs more visibility. They need to know which knowledge the agent can use, inspect the material behind it, and correct content when the result is wrong.

I designed the experience around that difference.

Builders can inspect the knowledge connected to an agent and test its behaviour before publishing changes. The simulation experience helps them see which sources were retrieved during an answer, so they have somewhere to start when the result is not good enough.

It does not expose every internal detail. It gives the operator enough information to investigate the problem and make a useful correction.

Making changes safer

Enterprise users need more than configuration controls. They need to understand what will happen after they use them.

V1 showed us how easily configuration and live behaviour could drift apart. For V3, I treated agent management as a workflow rather than a long form.

A user needs to prepare a change, test it, understand where it will appear, and know what state the live agent is currently in.

I worked with engineering to turn those requirements into clear product states and actions. The technical rules remained in the platform. My responsibility was to make their effect understandable in the interface.

This also changed the way I reviewed my own work. I stopped asking only whether a user could complete the happy path. I started asking what they would believe had happened after every action, and whether the system would confirm or contradict that belief.

How I worked

My role sat between customer needs, commercial priorities, design, and engineering.

I spoke with stakeholders, mapped workflows, defined requirements, designed the interfaces, reviewed edge cases with developers, and stayed involved through implementation.

Because I also contributed frontend code, there was no clean handoff where design ended and development began. I could test decisions against the real product and adjust them when the implementation exposed a problem.

I did not design the backend architecture. Engineering owned those decisions.

My responsibility was to understand the constraints, question how they affected users, and turn them into product behaviour people could understand.

What I learned

None of this was a solo project. The rebuild worked because the whole team committed to it.

What I can claim is the approach I brought to the product.

Every important decision needed a reason. Why is the widget a channel rather than an agent setting? Why can the operator inspect knowledge while the customer only sees the answer? Why should WhatsApp and the widget behave differently without becoming separate products?

V1 taught me what happens when those questions are answered too late.

V3 is the result of answering them earlier.

The interfaces are intentionally limited in this public case study. Orbina serves enterprise customers, and parts of the product must remain confidential. The diagrams show the product decisions without exposing customer data or internal implementation details.

For a full walkthrough, contact me directly.