Conversational AI
Enterprise UX
UX Research
Designing Proactive Copilot Guidance for Azure Capacity
Cloud capacity decisions can become complicated quickly. A customer may understand what their application needs but still struggle to determine whether the required resources are available, which configuration best balances performance and cost, or what to do when a deployment fails unexpectedly.
I led the product design for an Azure Copilot initiative exploring how conversational AI could make those moments easier to understand and act on. Rather than treating Copilot only as a place to ask questions, I explored how it could guide customers through decisions, surface relevant alternatives, communicate risk, and help them move from understanding a problem toward taking action.
Role
Product Designer
Timeline
3 Weeks
Partners
Product Management, UX Research, Engineering, Copilot Design Partners
Confidentiality note: This case study has been recreated to protect confidential work. Customer information, product details, implementation specifics, and portions of the interface have been generalized or modified. The underlying problems, workflows, research methods, and design decisions reflect my original work.
The challenge
Capacity across the lifecycle
A simplified view of where customers need guidance.
Plan
"Will my future needs be supported?"
Deploy
"Why did this fail?"
Recover
"What can I do next?"
Scale
"Will my setup continue to work?"
Learning what customers expected from AI
I partnered closely with UX Research as the team studied current capacity challenges and what customers would expect from AI-assisted guidance. My involvement was strongest during the participatory co-design phase, where I helped facilitate sessions and created a FigJam activity that asked customers to build their own ideal AI experience around a real cloud problem.
Instead of asking participants to describe a list of features, we gave them a playground of words, images, sticky notes, and AI-related concepts they could rearrange, combine, or replace with their own ideas. They then walked us through what they had created and, more importantly, why they expected AI to behave that way.
That distinction was useful. Customers were not simply asking for a smarter chatbot. They wanted an assistant that understood their situation, gave them meaningful choices, explained enough for them to trust its guidance, and helped them prepare for problems instead of only responding after something failed. Those themes were consistent with the broader research around contextual recommendations, proactive guidance, validation, and clear multi-option support.
Customer co-design session
We partnered with customers to understand what they need from AI when things don't go as planned.
Understand the situation.
Offer meaningful alternatives.
Help customers evaluate the guidance.
Support planning, not only recovery.
I used those findings to shape the scenarios I explored next and to establish a few principles that repeatedly influenced my design decisions: understand the context, show meaningful alternatives, make guidance easier to evaluate, and keep the customer in control.
Recovering from failure without starting over
A capacity-related deployment failure can stop a customer at exactly the moment they need to move quickly. The immediate problem is the failed action, but the larger burden comes next: understanding what happened, identifying a viable alternative, comparing the tradeoffs, and figuring out how to get the original workload moving again.
Research reinforced that customers did not want vague troubleshooting guidance or a single unexplained recommendation. They wanted clear, contextual options and enough information to decide which path made the most sense.
I designed the Copilot experience to treat the failure as the beginning of a recovery flow rather than a dead end. Copilot first explained the problem in context, then surfaced multiple ways forward and described how each option could help. I also explored confidence as an additional trust signal for stronger recommendations, while keeping the final decision with the customer.
When an alternative configuration could help resolve the issue, the experience narrowed a much larger solution space into a small group of relevant options and made the differences between them easier to compare. The intent was to remove as much manual investigation as possible so the customer could move from “Why did this fail?” to “Here are my best ways forward” within the same guided experience.
Making AI recommendations easier to trust
Recommending infrastructure is not like recommending a restaurant or a movie. Several options can be technically valid while carrying very different implications for cost, performance, availability, and future growth.
That made a single opaque “best” answer difficult to justify and potentially harder for customers to trust.
The design challenge became determining what Copilot needed to know, what the product already understood, and how much additional information we should ask the customer to provide before offering guidance.
More relevant recommendations
Combining what we know with what customers tell us leads to better, more helpful suggestions.
What the product already knows
We use the customer's current context to get started.
Existing setup
Deployment context
Known environment details
What Copilot still needs to ask
A few additional details help tailor the recommendations.
Workload type
Priorities
Required features
Future scaling
I redesigned an existing question-based concept into a shorter conversational flow. Where the product already had useful context, I avoided asking the customer to repeat it. Where additional information could materially improve the recommendation, I used targeted questions to fill those gaps.
I also introduced a multiple-choice interaction by reshaping established Azure components for use within the Copilot sidecar. Rather than forcing every interaction into free-form chat, the pattern gave customers a faster, more structured way to respond while still feeling like part of the conversation.
*
Recreated and generalized for portfolio use.
The recommendations themselves were intentionally comparative. Instead of presenting one answer and asking customers to trust it, Copilot could surface several viable directions and make their differences visible through supporting information and visual cues. That approach reflected the research: customers wanted choices they could understand and evaluate for themselves.
The AI helped narrow the decision. The customer still decided what mattered most.
*
Recreated and generalized for portfolio use.
The AI helped narrow the decision. The customer still decided what mattered most.
Moving from reactive support to proactive guidance
Most troubleshooting tools become useful after something has already gone wrong. The research suggested a larger opportunity: customers also wanted help understanding potential capacity problems while they still had time to change their plans.
That changed the design question.
Instead of asking only how Copilot could help someone recover, I began exploring how it could help customers think through future needs and uncertainty.
*
Recreated and generalized for portfolio use.
I designed a forecasting experience that paired conversational guidance with visual information about the customer's plan. Rather than presenting the future as certain, the experience helped communicate what appeared feasible, where risk might exist, and what other directions the customer could consider if the original plan looked uncertain.
*
Recreated and generalized for portfolio use.
This was one of the more meaningful shifts in the project for me. Copilot was no longer simply explaining a current state or troubleshooting something that had already happened. It was beginning to behave more like a planning partner, helping customers reason through decisions before capacity became a blocker.
Aligning new ideas with an evolving Copilot system
Starting from established Copilot guidance but little scenario-specific UX, I designed the end-to-end flows across each concept and regularly brought other designers into the work for critique.
Where existing patterns supported the interaction, I reused them. Where they did not, I explored new combinations of familiar components instead of immediately introducing entirely new UI. That approach became especially important as the work moved into conversations with Product, Engineering, and Copilot design partners.
The patterns I was exploring also created opportunities to compare approaches with other designers working on emerging Copilot experiences. I created a demo video to help stakeholders experience the scenarios as connected workflows rather than isolated Figma screens, which gave us a stronger artifact for discussing how these emerging patterns might fit within the broader Copilot ecosystem.
From research to handoff in 3 weeks
A compressed sprint that turned customer insights into scenario design, stakeholder alignment, and documented handoff.
WEEK 1
Research
UNDERSTAND THE PROBLEM
Planning + scoping
Customer research
Co-design workshop
Key themes identified
OUTCOME
Clear opportunity areas
WEEK 2
Design
TURN INSIGHTS INTO CONCEPTS
Research synthesis
Scenario definition
Pattern exploration
End-to-end prototype
OUTCOME
Connected concepts to review
WEEK 3
Alignment
REFINE AND MOVE FORWARD
Demo video
Stakeholder deck
Cross-functional review
Handoff documentation
OUTCOME
Direction ready for continuation
By the end of my contract, the work had progressed through cross-functional review. I incorporated the latest design feedback, documented the remaining considerations, and handed the updated work to the designer continuing the project.
Using AI to accelerate the design process
AI was not only the product I was designing. It also became part of how I worked.
Designing in a highly technical cloud domain meant I was constantly moving between customer needs, unfamiliar infrastructure concepts, and an emerging interaction model. I used Copilot and ChatGPT as working partners to shorten the distance between something I needed to understand and something concrete enough to evaluate.
I used AI to interrogate unfamiliar VM concepts, organize and synthesize my co-design notes, explore which questions might provide the strongest signal for a recommendation, and generate early starting points for conversational content. I also used generative AI for rough visual ideation when I needed to quickly explore how complex capacity information might be represented before translating those ideas into Azure's design language.
AI also supported the way I communicated the project, including early presentation scripting and portions of the demo-video workflow.
None of those outputs went directly into the product. They gave me faster starting points to challenge, validate, and refine. The biggest benefit was not automating the design process. It was creating more room for the part AI could not do for me: deciding what was actually useful for the customer.
This project expanded how I think about conversational AI.
The strongest experiences did not come from making Copilot more conversational for its own sake. They came from understanding where customers were struggling to make a decision and determining what combination of context, interaction, and visual information could make that decision easier.
The co-design work also reinforced the value of involving customers before deciding what an AI experience should become. Giving participants room to imagine their own experience surfaced expectations around choice, transparency, proactive support, and control that directly shaped the patterns I explored later.
Most importantly, this work moved my thinking beyond designing AI responses and toward designing AI-supported decisions. The goal was not to replace customer judgment. It was to reduce the work required to understand a difficult situation, evaluate the available tradeoffs, and reach a confident next step.