IBM BSS AI Agent — Designing an AI agent to eliminate manual processes in enterprise service management.

What this project was and what it achieved.

Why service onboarding was broken.

BSS (Business Support Systems) service onboarding required non-technical business users to navigate screens and workflows designed for engineers. Every service configuration involved complex technical fields, jargon-heavy error messages, multi-step manual processes, and frequent escalations to support. The system served customers, employees, and vendors — each with very different technical literacy and goals.

• New initiative — no navigation architecture to build on Design from scratch with no existing UX patterns or established interaction precedents.
• Merging platforms — three existing systems needed to coexist Consistency across different data models and UI patterns required a unifying design framework.
• Diverse audiences — customers, employees, vendors Vastly different technical literacy and task contexts needed to be served within the same interface.
• Timeline pressure — aggressive delivery schedule Required rapid prototyping and continuous stakeholder alignment to maintain momentum without sacrificing quality.
• Accessibility — enterprise-grade compliance required Every AI interaction had to meet WCAG standards from day one, not as a retrofit.

How I understood the problem before designing.

I conducted competitive analysis, stakeholder interviews, and user interviews across the three target audiences. Persona development helped translate diverse user needs into clear design requirements.

• Insight 01 — User Goals vs. System Fields
  Users wanted to complete tasks, not configure systems.
  Business users consistently described their goal in outcome terms ("I need this service running") not technical terms ("I need to configure parameters X, Y, Z"). Implication: The AI agent should lead with user goals, not system fields.
• Insight 02 — Trust as Adoption Barrier
  Trust in AI was the primary adoption barrier.
  Early concept testing showed users hesitated to let AI configure business-critical services without understanding what it was doing. Implication: Transparency — showing reasoning, confidence, and source — was non-negotiable.
• Insight 03 — Failure Design Over Success Design
  Failure design mattered more than success design.
  Users were far more concerned about recovery from errors than about the happy path. Implication: Every AI action needed a visible, low-effort undo and correction path.

Designing the intelligence, not just the interface.

This was not a chatbot skin on existing forms. The AI agent required a principled approach to human-AI interaction — one that earned trust, maintained user control, and handled failure gracefully.

Measured outcomes.

Additional qualitative outcomes from the AI agent approach:

• Enabled employee self-services with AI — reducing dependency on manual service desk processes
• Demonstrated viability of conversational enterprise UX at IBM — informing future AI product direction
• Established reusable AI interaction patterns now applied across IBM's broader design system

How I drove direction on a new initiative.

As the sole UX owner on a new initiative with no existing architecture, I was responsible for establishing the design direction from zero:

• Defined the AI interaction model and conversation architecture before any engineering work began — establishing the design-led foundation for the product.
• Conducted user interviews and persona development across three distinct audience types — customers, employees, vendors — and synthesised into unified design requirements.
• Led competitive analysis to identify best-practice AI onboarding patterns across enterprise and consumer contexts.
• Prototyped and tested multiple conversation flows — iterating based on user feedback before committing to engineering build.
• Aligned stakeholders from product, engineering, and business on the conversational AI approach through structured design reviews.

What I learned.

• The hardest part was designing for AI failure — not AI success. What happens when the AI is wrong matters far more to user trust than what happens when it's right. I spent more design cycles on error and recovery states than any other part of the interface.
• Testing with real users, not just assumptions, completely changed the conversation flows. What seemed intuitive in design reviews failed consistently in user testing. The vocabulary business users used to describe their goals was completely different from the system's language.
• If starting again, I would define AI accuracy success metrics before the first design sprint. Measuring engagement and time were clear. Measuring whether the AI was actually making correct decisions required metrics we defined too late.