The problem

Azure Copilot used to handle simple tasks limited to conversational UI: a user sends a prompt, Copilot sends an answer. Agents changed that. They work autonomously, call external tools, and can make permanent, expensive changes to a company's cloud setup. Users needed a way to monitor what an agent was doing, understand what it planned next, and intervene if something went wrong — and at the time of this project, many of those interventions weren't technically feasible.

The constraints

Engineering had no control over how chain of thought text was generated or formatted, so the UI had to accommodate unpredictable output. Stopping or canceling an in-progress agent action wasn't possible, but I believed it was fundamental to a successful design. The resolution was to communicate the limitation clearly before a user committed. That framing brought Legal in, since initiating certain actions would incur costs with no ability to reverse them.

Partner teams wanted more surfaces and more information than the timeline could support, and leadership wanted the most robust version possible for Ignite. Every decision about what to include came down to weighing what partners wanted against what was actually feasible to ship while keeping the experience trustworthy.

What I learned

The biggest lesson was in advocating for trustworthy design practices when we couldn't support basic safety guardrails like undo or cancel. The design had to do the work the backend system couldn't.

No single version of this design satisfied every preference, but I believe it delivered the most trustworthy experience possible given the constraints. Making risk visible, being honest about the tradeoffs, and designing clear consent moments gave us a real foundation to build on as AI experiences evolve.

The goal

Azure is Microsoft's enterprise cloud platform that organizations use to deploy services, run AI workloads, and build applications at scale. As we expand our agentic capabilities to execute more and more tasks across that infrastructure, the design system's job changes.

My goal is to define what the design system needs to become in an agentic future, whether that's a behavioral spec, a set of guardrails, or something else we haven't identified yet, and validate a proof-of-concept that product teams can actually adopt into their roadmaps.

The fundamental shift

My contribution

I led the framing of where the design system sits as a layer between agent context inputs and final output. The core problem is that without a behavioral framework, trust and control patterns are inconsistent. I'm working to define how the system behaves across contexts: what level of risk and impact triggers a guardrail, when an agent can act on its own, when it must pause and defer, and how that reasoning stays visible and consistent for users. Validating that requires a new kind of prototype entirely.

To validate this, I'm building a simulation environment that generates tailored, context-aware experiences per participant, something that's not achievable with traditional linear prototyping. The first version of the behavioral framework lives inside this simulation, giving us a real testing surface.

Where this is going

We're beginning user validation to find where trust breaks down and autonomous action stops feeling safe or transparent. What we learn will establish the baseline that the framework needs to be useful, evolving from a set of principles into a tested, scalable spec that our product teams can build from.

The problem

Our design system team was 6 designers supporting more than 50 consumer teams, and our documentation was always treated as a second priority. Teams kept asking the same implementation questions, which kept our support load high, since those were questions the site should have answered on its own. People stopped trusting the site as a source of truth and would go as far as sending me screenshots directly, asking what a component actually did rather than taking the documentation at its word.

The bigger picture

Our team had a strategy to modernize our system to align to Fluent (Microsoft's parent design system), who had just launched a newly redesigned system, simply named Fluent 2. We had three core deliverables: token migration, the documentation rewrite, and a site redesign. I owned the first two. The site redesign was a separate workstream I wasn't part of, except where its layout decisions affected how documentation pages themselves needed to look.

What changed

Before, do's and don'ts mostly stated the obvious in opposite pairs, or repeated accessibility requirements that were built into the component or weren't even optional to begin with. Those requirements were also buried at the bottom of the page, like an afterthought. Additionally, every piece of guidance had its own custom image, often built around placeholder content like grocery items in a data grid instead of anything like what our consumer teams were actually building.

The new structure moved from optional-sounding guidance to a clear hierarchy: a standards section at the top of every page that stated 100% need-to-implement requirements as fact, in quick bullet form. Accessibility moved into that standards section instead of being the last thing on the page. Optional guidance was deprioritized, and what remained had a clear job, like helping someone choose between component variants, rather than illustrating every rule.

Sample guidance

Outcome

Leadership announced the updates in broader org meetings and actively encouraged adoption across consumer teams, a level of visibility documentation work doesn't usually get.

Another signal I noticed: with the update, direct messages to me with site screenshots stopped, and support questions shifted from broad implementation questions to specific questions about actual product problems.