Designing the first analytical module of a scalable multi-agent ecosystem.

The project started with an Analytical Assistant a module helping users ask questions about sales data in natural language. But the design challenge was broader than one AI chat. The assistant had to become a scalable foundation for future agents: consistent across web and mobile, clear in communication, safe in edge cases and flexible enough to support new business workflows over time.

Three core states of the Analytical Assistant: the main conversation view, visible answer generation and a structured business response.

Users had access to sales data, but getting a clear answer often required working through reports, filters or additional analytical support. For users with limited analytical experience, even a simple question such as how sales changed this year could turn into a multi-step process. The goal was to reduce that friction by allowing users to ask questions in natural language and receive clear, business-oriented answers directly inside the product.

The challenge was not only to design a conversational interface. The assistant had to work in a complex product environment where answers depend on data access, business definitions, user permissions, data freshness, technical constraints and user trust. The first release focused on analytical questions, but the experience also needed to create a foundation for future AI agents. This meant designing patterns that could scale beyond one use case: onboarding, prompts, answer structure, processing states, safe refusals, error handling and a consistent Tone of Voice.

I was the lead Product Designer responsible for designing the AI Assistant experience across web and mobile. My work included the main conversational interface, onboarding, empty states, response patterns, loading and processing states, and the visual structure of analytical answers. I also co-created the Tone of Voice for the assistant, defining how it should communicate in a way that feels professional, clear, trustworthy and helpful without sounding like a generic chatbot or pretending to be human.

The project required close collaboration with analysts, PM, business stakeholders, developers, testers and the AI team. Together, we discussed the MVP scope, data limitations, response logic, access rules, technical constraints and how the assistant should behave when it cannot safely answer a question. My front-end background helped me approach the experience not only as a set of screens, but as a system of reusable states, components and behaviours: empty state, prompt suggestions, streaming response, retry, copy action, safe refusal, mobile keyboard behaviour, onboarding steps and future agent-specific patterns.

My design process

The first release was analytical, but the assistant was planned as a growing ecosystem. That changed the design problem. Instead of designing a single-purpose chat, I worked on a product layer that could support future agents and new business workflows over time. The experience needed to feel coherent regardless of whether the user was asking about sales data today or interacting with another specialised agent in the future.

This was also why the Tone of Voice became an important part of the product foundation. In an AI experience, text is not only supporting copy it becomes a major part of the interface. The assistant needed to sound professional, trustworthy and helpful, while staying transparent about its limitations.

Decision 1: Designing a scalable foundation, not a single-purpose chat

The first release focused on the Analytical Assistant, but the experience had to support a broader product direction. I treated the assistant as a scalable product layer, not a one-off chat feature.

Decision 2: Guided start instead of an empty chat

The assistant introduced a new way of working with the product, so the first interaction had to reduce uncertainty. The goal was to help users understand what they could ask before they had to formulate a perfect question.

Decision 3: Structured answers users can scan and verify

For analytical questions, the answer had to be useful in a business context: quick to read, easy to verify and clear about the assumptions behind the result.

From guided entry to response generation and a structured analytical answer on mobile.

Decision 4: Visible answer generation

The waiting state was an important part of the experience. I wanted the assistant to feel responsive and understandable while it was preparing an answer, not like a black box.

Processing steps make the waiting state clearer and build trust before the final answer appears.

Decision 5: Safe responses for edge cases and limitations

A trustworthy AI assistant cannot be designed only around successful answers. It also needs clear behaviour when it should not answer, cannot answer or needs more context.

Safe response patterns help the assistant explain limits, avoid guessing and guide users toward the next best step.

Because the assistant introduced a new way of interacting with the product, onboarding was not just an introduction screen. It had to explain the value of the assistant, set expectations around data safety and answer verification, and help users start with concrete, business-related questions. I designed the onboarding across web and mobile to reduce uncertainty and make the first interaction feel guided rather than empty.

The onboarding covered three key areas:

Onboarding screens designed to introduce the assistant, explain trust and privacy principles, and guide users into their first question.

On web, onboarding was reduced to a single modal that introduces the assistant and its value without interrupting the main workflow.

This was especially important because the assistant was not a traditional feature. It changed the interaction model from navigating through screens to asking questions in natural language. The onboarding needed to support that behavioural shift.

The assistant had to work in two different contexts: desktop and mobile. On desktop, users have more space to review answers and continue the conversation. On mobile, the experience needs to support quick interactions, limited screen space, keyboard behaviour and field-work context. I designed both versions with the same product logic but adjusted the interface density, spacing and interaction patterns to fit each platform.

On mobile, the assistant needed to stay useful even when the keyboard covers part of the screen or when the user is working between tasks. This influenced the layout of prompt suggestions, the input area, answer spacing and the visibility of core actions.

For this project, Tone of Voice was not treated as final copywriting. It became a design tool for shaping how the assistant behaves in different situations. The assistant needed to communicate with professionalism, clarity and trust. It had to be friendly enough to feel approachable, but not overly casual. It had to be helpful in errors, but not apologetic in a way that would reduce confidence. It also needed to be transparent about limitations, especially when the system could not safely answer a question. The Tone of Voice work helped align the team around communication principles for successful answers, onboarding, error handling, safe refusals and future assistant modules.

One of the most important parts of the project was designing how the assistant should behave when the answer is not straightforward. In a data-heavy business product, trust depends not only on good answers, but also on predictable limits. The assistant should not reveal data outside the user’s access, suggest facts that are not supported by the available dataset, or pretend that a feature exists when it does not.

The assistant is currently being validated internally and with selected customers. Internal testing confirmed the clarity of the core flow, onboarding and response experience. The next step is a wider rollout to customers. The feedback helped confirm that the direction is understandable and useful as a first step toward AI-supported analytical work. It also gave the team a stronger base for refining response quality, onboarding, edge cases and future agent modules.

Because the assistant is part of a complex product ecosystem, the validation was not only about whether the UI looked clear. It was also about whether users understood what they could ask, how to interpret the answer, and where the assistant’s limitations begin.

The project created a scalable foundation for an AI assistant experience inside a complex business product. The first module focused on analytical questions, but the design work established patterns that can support future agents and workflows. The main value of the project was not only the chat interface itself, but the system around it: onboarding, prompt guidance, response structure, processing states, safe failure patterns, Tone of Voice and cross-platform consistency.

For me, this project reinforced that designing AI features requires more than making the interface feel modern. A useful AI assistant needs clear product boundaries, understandable communication, strong trust patterns and close collaboration between design, business, analysts and technical teams. It also showed how my front-end background supports product design work. Thinking in states, components, dependencies and edge cases helped me design an assistant experience that was not only visually clear, but also more realistic to implement and easier to evolve.