An AI copilot built for the Azure portal, reimagined for the places engineers actually work — a conversational experience for Microsoft Teams and Slack, where specialized agents help an engineer resolve issues without leaving the thread.
Timeline
2024 – 2025
Platforms
Microsoft Teams · Slack
My Role
Design Lead — owned strategy and design across every surface, from kickoff to launch.
Context
Azure operations are a team effort. Azure Copilot brings AI-powered operational assistance into Microsoft Teams — helping teams troubleshoot issues, manage support requests, monitor costs, and stay on top of operations without leaving their workflow.
The Challenge
But Copilot was built for the Azure portal — a world of navigation, panels, and forms that chat simply doesn't have. The design challenge was less about moving Copilot into chat than about what it had to become to work there.
🎯
Problem Statement
What does a product built for a portal have to become to work in a conversation?
Design Highlights
What shipped brings Azure Copilot into Teams — from discovering and installing the app to chatting with a set of specialized agents that resolve issues in place. Here are the highlights, in the order a user meets them.
App discovery
Users install Azure Copilot from the Teams app marketplace and launch it right inside Teams. As a brand-new product, it also needed a first impression — naming, icon, and visual identity — plus a staged waitlist for a gradual enterprise rollout.
Onboarding
A short onboarding walks users through setup: sign in with an Azure account to connect Copilot to their organization, meet its key capabilities, and start chatting right away. Proactive notifications are optional and customizable at any time.
Chat agent
With setup complete in a few clicks, users can start asking questions directly from Teams. Copilot identifies the relevant resources, analyzes the issue, and generates a solution — without requiring users to switch tools. They can also revisit chat history or start a new chat to keep their conversations with the agent organized.
Specialized agents
Some questions need a specialist. When starting a new chat, users choose who to talk to — the general Copilot, or a specialized agent for migration, deployment, troubleshooting, and more. Each agent opens with prompt starters written for its job, so the conversation starts with an expert who already knows the territory.
Research
I ran research in parallel — what competitors had built, how these teams operate, and what the platforms would allow. Each track narrowed the problem further.
🔎
Competitive — AWS
AWS splits monitoring and support across two apps, forcing a context switch mid-incident — so we consolidated into one agent, one conversation.
📊
User Research
Chat is where customers run operations, not just receive alerts. What they needed was correlation — what's affected, how severe, and who owns it.
🧱
Two platforms
Teams and Slack offer different building blocks and rules, and don't map to each other. I validated Teams with its platform team, and Slack against its public API docs.
What the research concluded
These tracks converged on a set of principles that governed every decision downstream.
1
Context, not signals
Customers were not asking for more information. They wanted the correlation they had been doing manually, and help understanding an incident before moving to a fix.
2
Make chat actionable
If every answer is a link back to the portal, nothing has moved — the flow has only gained a step. Whatever the agent surfaces should be actionable in place.
3
Humans stay in control
Customers welcomed AI triage and AI-generated fixes but consistently wanted a person to approve anything before it ran. The agent recommends and prepares; it does not act on its own.
📌
The insight that shaped everything
The product's value is that engineers stop switching between systems, but that only holds if the conversation carries them forward. In a portal, users navigate to the next step themselves; in chat there is nothing to navigate to. The agent has to know what comes next.
Design Process
Troubleshooting is one of several on-demand skills — cost, support, and operational insights work the same way. The platform already had these capabilities; the harder design problem was the flow that connects them into one guided conversation, carrying an engineer from “something's wrong” to “it's handled.” The example below follows a workload retirement.
Journey map
I mapped the way teams move through an incident onto an ordered set of stages, each answering the question the previous one raised. The agent carries the user forward — completing one stage surfaces the next.
01
Discover
Surface the retirements and changes affecting a workload.
“Does this affect me?”
02
Prioritize
Rank what's found by criticality and cost.
“What do I fix first?”
03
Plan
Generate a remediation plan across 30 / 60 / 90 days.
“How do I fix it?”
04
Coordinate
Create the work item, assign an owner, track progress.
“Who takes it?”
05
Execute
Generate and run the remediation script.
“Let's run it.”
Iterations
A design review surfaced two changes, both about letting the user decide rather than deciding for them.
Scope before answering. Instead of answering a broad question directly, Discover now asks for what it needs — the subscription and service group — and offers to save that as a reusable workload, so the user never has to define it again.
🖼
Image / GIF
Scoping step — agent asks for subscription / service group and offers to save a workload.
A fork to hand off. The recommendation card gained a second action. Review & remediate opens the plan; Create work item hands it off, notifying the assigned owner through their own Copilot. Some users need the plan; others are triaging for a team and only want the handoff.
🖼
Image / GIF
Recommendation card with the fork — "Review & remediate" vs "Create work item" handoff.
Designing for Slack
The same conversation had to ship on Slack — the same stages and the same decisions at the same moments, but not the same screens, because Teams and Slack do not offer the same building blocks. I designed Teams first, then defined the system a second designer built Slack from.
💼
Teams
The skills flow in Teams — Adaptive Cards.
💬
Slack
The same flow in Slack — Block Kit.
The same flow, side by side.
When something needs attention in Teams, a toast can surface it over whatever the user is doing; Slack offers only a sidebar badge, noticed in passing. Teams' Adaptive Cards support a carousel, so several items fit in one swipeable card; Slack's Block Kit does not, so the same content becomes a list or splits across messages.
📏
The rule I drew
The easy path was a lowest common denominator — one identical experience everywhere — but forcing two platforms to match makes both worse. The rule instead: the meaning stays identical (what the agent says, which decisions are available, and the state the user ends in), while delivery and layout are free to differ, since that is what makes each platform feel native rather than ported.
Takeaways
I expected the hard part to be the AI — its intelligence and the quality of its answers. It was not; that already existed in the portal. The difficulty was everything around it, and most of the work was translation.
💬
Meet users where they work
The intelligence already existed in the portal; the value was removing the tool-switching. Bringing Copilot into Teams let engineers act on an issue in the same place they were already talking about it.
🧭
A blank chat box isn't a product
A conversational tool has to introduce itself. Onboarding and clear entry points — troubleshoot, check health, ask a question — did as much for adoption as the answers behind them.
🧩
One product, many specialists
Specialized agents give expert answers without crowding the main experience. Choosing one is part of starting a chat — a behavior Teams users already have — and the general Copilot always works, so nobody has to choose correctly to get help.
