IBM
A visual experience that helps authors build complex conversations 20% faster at scale
Problem:
Agent authors struggled to plan, debug, and scale complex conversation flows within a linear interface that didn't reflect how they think. Without a clear way to visualize structure or logic, building and maintaining large assistants was slow, error-prone, and difficult to manage as teams and use cases grew.
Opportunity:
We saw an opportunity to improve how authors plan and manage complex conversations. By replacing the rigid linear structure with a flexible, visual canvas, we made it easier to see logic, spot errors, scale with confidence, and reduce rework.
Role
Lead UX Designer
Year
2024
Team
Technical PM, Dev Team, Visual designer
Project type:
Discovery/Exploratory (Passion Project)
Deliverables
Why the solution worked:
- Build time decreased by ~20%
- Became the default builder for enterprise users
- Accelerated onboarding and handoff across teams
- Reduced overall confusion and made maintenance more efficient
IBM's current agent builder
Key Pain Points
- Users find our authoring experience, specifically Actions, hard to use
- Users find it difficult to organize and visualize their assistant
- Users find it challenging to collaborate in our product
Process
The process started with defining the problem. On a high level, customers were using the linear builder, but it didn't support complex agents well. We needed a better way to help them plan, understand, and manage their flows, which required more investigation...
📝 Plan
- Primary research
Asked PM to help set up customer calls.
Conducted a major research study (10 users across 4 customer accounts) to guide direction. - Secondary research
Benchmarked leading tools: Voiceflow, Intercom, Tidio, Mailchimp, Dialogflow, Kore.ai. - Synthesize & align
Worked with dev, PMs, and design leads to define clear user needs.
Prioritized needs and worked incrementally on designs that addresses the primary issues
Focus on the action level (i.e., building steps within an action) rather than the assistant level — this is lower risk, easier to implement, and offers high impact
Established design principles grounded in user needs and validated through usability testing
Mapped needs to business value and identified key "wow moments." - Concept development
Explored 2–3 end-to-end prototypes (backed by research) to test different approaches. - User Testing
Tested prototypes with users to validate flow clarity, navigation, and debugging experience. - Feasibility check
Collaborated with development to validate feasibility, risks and constraints
Researched and chose a tech stack that could support long-term goals. - Phased rollout plan
Phase 1: Read-only visualization
Phase 2: Interactive edit mode
Primary Research
We began with 10 exploratory interviews across developers and conversation designers using IBM Watson Assistant - we documented their agent lifecycle in detail. Participants managed assistants with skills that contained 50–100+ conversational steps.
🔍 Key Findings
- With complex flows, all users planned and maintained their flows using an external diagramming tools (like Miro, Twine, LucidChart, Excel) to plan their flows.
- Most users organize their diagrams at a step level (i.e., how steps are connected, API calls, relationships between sub-actions)
- All users agreed that our building experience is very difficult to maintain when working with 10+ actions
- Maintenance (improving, modifying, and adding) is one of the biggest pain points in this phase, due to the flat/unhierarchical design of Watson Assistant (WA)
Defining the problem
With complex flows, users planned and maintained their flows using an external diagramming tools (like Miro, Twine, LucidChart, Excel) to plan their flows.
🧐 Why was it a problem?
-
Maintaining two separate artifacts, an external flowchart and the in-product builder, creates friction for teams. They're constantly keeping both up to date, which leads to duplicate effort, slower productivity, and increased mental strain.
🧩 Why are users relying on two different tools?
- The builder lacks flexibility and creative freedom for planning complex conversations
- It behaves more like a developer tool (focused on prototyping/deployment) than a design tool for our primary user, Tanya (conversation designer)
- Users need better ways to understand flow, logic, and hierarchy within assistants
- Translating ideas into a flat, linear format causes mental strain and frequent context-switching
- As a result, users rely on external diagramming tools (e.g., Miro, Mural, draw.io) as living, collaborative artifacts
- Like UX design, conversation design is collaborative, but our product lacks tools to support team workflows
- Some teams prefer to separate low-risk, collaborative planning artifacts (e.g., diagrams) from high-risk technical artifacts (e.g., the conversation builder)
- Example: Developers update the assistant in-product, while content designers maintain the flowchart
- Diagrams provide a simplified, non-technical view that's easier to share and align on
- Example: devs update the in-product assistant; content designers maintain the external flowchart
- For many teams, the flowchart becomes the source of truth—accessible, lightweight, and aligned to their planning process
💡 How can we help, incrementally?
-
Big bet:
- Adding ways to visualize the building experience of assistant/actions will increase the understandability, learnability, and adaptability of the assistant (matches mental model)
- Users will spend less time translating their flows in WA and more time focusing on their primary goals/responsibilities (reducing cognitive load)
- Most users organize their diagrams at a step level (i.e., how steps are connected, API calls, relationships between sub-actions)
- All users agreed that our building experience is very difficult to maintain with 10+ actions
- Maintenance (improving, modifying, and adding) is one of the biggest pain points in this phase due to the flat/unhierarchical design of WA
- Work incrementally on a design that will help with the primary issues
- Focus on the action level (i.e., building steps within an action) instead of the assistant level — it's lower risk, easier to implement, and high impact
- Develop a concept car (backed by research)
- Deliver a read-only visualization as the MVP
- Users felt more confident identifying conversation logic visually.
- Node-based flow felt intuitive and reduced navigation friction.
- Debugging was faster when tools were embedded directly in the flow.
- Users wanted version history, commenting, and macro/micro views.
- Zoom-in/out for navigation
- Visual hierarchy and grouping
- Inline debugging and node-level annotations
-
Estimates for the tech stack.
-
Vision prototype clip (build / edit mode)
-
Different states of block components.
-
Defining the logic and conditions of each block
- A canvas-based graph layout
- Easy node linking and rearranging
- Debugging built into each node
-
We conducted research on how people visualize their assistant
-
Refined Plan:
Competitive Analysis
From there, our problem was more refined. We began to look at competitors and seeing how they were handling this problem.
We benchmarked leading builders Voiceflow, Intercom, Tidio, Mailchimp, Dialogflow, Kore.ai, etc. validating a growing industry trend toward visual-first design and modular flow building.
In-depth documentation of all competitors in visualization space.
Identifying wow moments & design principles ✨
As a team, we began by identifying key “wow moments” from existing internal resources and feedback shared by the marketing team. These moments represented the most compelling, intuitive, or delightful parts of the current product experience.
To guide our exploration, we translated these into design principles (backed by research findings).This approach helped us:
Align cross-functional stakeholders (design, PM, marketing) around a shared vision
Stay focused on what actually resonated with users
Bridge the gap between brand experience and functional usability
Prototyping
We tested early versions of the visual builder with both novice and expert authors.
We iterated based on feedback, adding features like:
Users had a great impression of the first two prototypes, so we blended the features they liked most for our north star.
North Star
Refining the requirements
We began scaling back the designs to focus on the MVP.
🎯 Refined Requirements for MVP
Tech stack research
I led research for the tech stack that would be used to implement the new builder and recommended React Flow for its strong support of the React ecosystem and seamless compatibility with IBM’s Carbon Design System (also made in react).
💻 Tech stack research
Establishing a design language
Partnered with a visual designer to define a design language for the MVP, ensuring consistency and scalability. Collaborated with UX engineers to build custom components, which were contributed back to the internal Carbon Design System.🎨 Design language
Phase 1: Read-only solution
Partnered with a visual designer to define a design language for the MVP, ensuring consistency and scalability. Collaborated with UX engineers to build custom components, which were contributed back to the internal Carbon Design System. The final product is a clean, modern visualization interface for building chatbot flows.It offers:
Due to time constraints, we focused on delivering a read-only visualization for the MVP. Instead of full edit functionality, users could view the flow and seamlessly jump back to the legacy editor to make changes. Despite this limitation, the approach was well-received and proved to be a successful interim solution.