MICROSOFT • PRODUCT DESIGN INTERNSHIP

Reducing misroutes in Microsoft’s incident management tool.

Role

• Product Design Intern

TOOLS

• Power Apps, Power Fx

Timeline

• 6 Weeks / June - July 2025

During my 12-week internship at Microsoft, I primarily worked alongside the Power Apps design team on customer-facing feature. Midway through the summer, a senior manager invited me to take on an additional project: a full redesign of Microsoft's internal incident management tool.

Unlike my other work in Figma, tight timelines on this project required me to deliver a fully functioning application end-to-end. I built my redesign directly in Power Apps and worked closely with lead software engineers.


I shipped the full solution before the end of my internship, directly improving how Microsoft’s support teams manage and resolve incidents today.

• CONTEXT

What is the ICM Routing tool?

The Incident and Case Management (ICM) Routing App is Microsoft’s system for handling reported product issues. When an issue is reported on a Microsoft product (e.g., a bug in a feature), it follows this flow:

Ultimately, the tool’s purpose is to help support engineers determine which product team owns a given feature so incidents can be routed correctly.

• THE PROBLEM

Information overload leading to frequent misroutes

Throughout this project, I worked closely with the senior software engineer who had originally developed the tool and was still responsible for managing it. He shared with me feedback that showed why a redesign had become so crucial. I then identified three major pain points that made relying on the tool especially difficult:

In practice, this meant the tool was generating frequent misroutes: incidents being sent to the wrong team, only to be rerouted later. Misroutes not only forced engineers to do extra work but also delayed resolution for customers.


The next step in my redesign was to dive deeper into the original ICM app.

Why weren’t existing patterns working?

• ORIGINAL SCREENS & INSIGHTS

Filters dominated the UI but didn’t reflect how engineers worked

The app’s filter-based navigation system (App → Surface → Component → Feature) was designed to narrow down ownership step by step. While this worked reasonably well for front-end issues, it broke down for backend services, where mapping is not as intuitive.

Original App

Working in PowerApps, I was able to gain access to telemetry from the live system. I uncovered that engineers weren’t following the intended filter flow…despite it taking up most of the interface.


Instead, they overwhelmingly used Search to jump to keywords and highlight matches. The second most-used action was selecting "Feature", confirming that engineers often already knew what they were looking for.

Activity Tracking

Exceptions were endless.

When the ICM Routing App recommends a team for a specific feature, the recommendation is rarely absolute. Each team can define a long list of exceptions: specific situations where an issue that normally belongs to their team should actually go elsewhere.

Original App

When the engineer finds a recommended team for a feature, this list is shown to the support engineer in the “Except If” section. It may read something like:

"Route to Team A… except if the issue is caused by API authentication failures. "

"Route to Team B… except if the error occurs in a legacy version of the product."

Because these exceptions were authored manually, they quickly spanned into dense, text-heavy pages. Support engineers often overlooked key exceptions, which became a major contributor to the frequent misroutes.


The current exception list failed to address two of the most critical pain points:

• USER FLOW + EXPLORATION

After gaining a better understanding of the original tool, I mapped out a user flow to illustrate the engineer's journey.

Using the map and insights drawn from research, I began exploring what a solution might look like. Because support engineers relied on this tool daily, I knew the redesign needed to enhance (not disrupt) their established workflows.

Initial sketches from a design session with my manager

• ACCELERATED DELIVERY

Design Meets Development

A major difference in this project was that I wasn’t just redesigning the interface — I was building the actual product. I built new components in Power Apps, implemented logic with Power Fx, and worked with real data from the original application. I had never done anything like this before.


This opportunity allowed me to think beyond visuals and make continuous trade-offs throughout development.

(Me and the error indicators became very familiar with each other)

• THE GOAL

Reduce Cognitive Load

Original Screen

• FINAL REDESIGN

Aligned With Real Usage

Redesign

Real estate to mirror actual usage patterns:

Streamlined Information

Redesign

Exceptions List

Redesigned Component

• IMPACT

Currently used by Microsoft's support teams.

The new ICM experience went live internally before the end of my internship; it is still used within the company today.

The Result:

Kind words from engineers after launch ^

• REFLECTIONS

What I learned.

This project taught me the value of meeting users where they are. Engineers had already shaped their own workaround by relying on search, so instead of fighting that behavior, I optimized for it.


It also underscored the value of designing through implementation. I wasn’t just envisioning the solution…I was shipping it. This technical stretch gave me a deeper understanding of what it takes to deliver design at scale.


I’m deeply grateful for this project and for the people who supported me through it. Taking on a more technical challenge taught me far more than I expected, and I owe much of that growth to the senior engineer who guided me with not only his expertise, but also patience. I’m also incredibly thankful to the Power Apps design team for their mentorship and unwavering support throughout the process <3

Thanks for reading!