My role
Lead UX Designer
Timeline
12 weeks
Team
1 designer · 2 PM · 6 engineers
Focus
Analytics & product leadership
Work is enterprise focused, therefore not many images of work may be published publicly. Low-fidelity images provided when applicable.
Quick summary
I designed the analytics framework and dashboard guidance for Dragon Admin Center, helping teams create consistent, scannable, and decision-oriented analytics experiences across multiple products. I took a broad leadership role in defining the future of the platform by conducting and connecting research with product strategy and implementation across teams.
overview
Dragon Admin Center (DAC) needed a more scalable way to support analytics across products, capabilities, and future extensions. As more reporting experiences moved into DAC, the risk was that each team would bring its own dashboard patterns, filters, navigation, terminology, and visual structure. That would create a fragmented experience for customers and make it harder for administrators (the users) to understand what they were seeing. Rather than having a product that looks like many different teams provide their own reports on one UI, one UI should look like a cohesive place for reports. Not only that, but there was a systemic problem where as our product portfolio grew, we are going to need more dashboards created. This needed to scale for an ever-growing group.
I created a scalable analytics framework that enabled teams to build consistent, high-quality dashboards without requiring direct design support for every implementation. This allowed me to shift from execution into platform-level influence.
As the work matured, my focus expanded from establishing visual consistency to shaping the longer-term analytics direction for DAC. This includes defining how tenant-level, product-level, and extension analytics can work together, while making sure the standards are reflected in the reports that customers actually use.
The challenge
As analytics became a core part of Dragon Admin Center, teams needed shared rules for how dashboards should be structured inside the product shell. Without clear standards, each dashboard could make different decisions about navigation, headers, filters, chart structure, visual hierarchy, and terminology. Each time Microsoft releases a new product that would be hosted on DAC, a new dashboard would need to be created that has specific needs for that product.
Besides just creating a general Design Guideline or visual language, there needs to be clear distinction on what should and should not be a report. The analytics for Dragon Copilot for Physicians, Dragon Copilot for Nursing, and Dragon Copilot for Radiology were going to have to be moved from wherever they were currently being hosted into DAC, therefore the understanding of what the user wants and needs was a little vague to those product teams. DAC was not just an analytics platform but an administration platform that allowed people to provision and assign licenses. Whatever guidelines that are going to be created need to explicitly frame DAC dashboards as experiences for a specific audience trying to make specific decisions, not generic dashboards “for everyone”. We also need to keep the dashboards grounded where the visuals should answer a user’s questions rather than just being a dumping ground for everything measurable.
In practice, this meant the platform needed more than visual polish. It needed a shared analytics philosophy.
my role
I created and documented the DAC analytics dashboard guidance and helped establish patterns for how analytics should work inside Dragon Admin Center. I was the sole designer and UX role on this project.
My role had grown into leading the future-facing analytics experience across DAC. I connect design, research, PM, engineering, and product teams around a shared direction, facilitate critiques and design audits, prioritize recommendations, and follow the work into implementation rather than stopping at guidance.
I also used the platform work to identify where teams need a shared solution and where a product may need room to adapt. My goal wasn’t to make every report identical, but to create a recognizable and consistent structure within DAC to support product specific needs.
I led the design guidance for analytics in Dragon Admin Center, creating a repeatable framework for dashboard structure, navigation, filters, visual hierarchy, and decision-first metrics. The framework helped partner teams build analytics experiences that felt consistent with DAC while still supporting product-specific reporting needs.
understanding the problem
I partnered with research to move the platform beyond assumptions about what administrators want from analytics. The research included sessions with customer administrators, analysts, and Dragon Copilot app and agent partners. We used early concepts and prototypes to understand what people monitor today, where they lose context, and what they need before they can take action.
The research I conducted showed that each customer and organization cared about different analytics. The growing need for dashboard views that are customized for each customer created a clear path that customers should oversee their own views. They need to have flexible segmentation, role-appropriate views, clearer system-health signals, access to underlying data, and the ability to connect usage patterns to actions such as onboarding, support, or license changes.
These findings shifted the direction of the platform. Instead of treating DAC as a fixed collection of standardized reports, I began shaping it as a shared analytics foundation that can support a consistent overview while allowing deeper product and organization specific views.
The design question
How do we structure analytics for action rather than just communication?
design evolution
For this project to be successful, I needed to set up goals for this framework:
Build dashboards that are consistent and understandable in minutes.
Start with user intent and decisions instead of charts.
Structure reports inside the Dragon Admin Center shell without duplicating navigation.
Use top-down dashboard hierarchy so admins can scan and quickly understand trends
Give non-designers practical guidance and a self-critique prompt for dashboard review.
I needed to structure the guidelines to explain these concepts to any team that is tasked with making a report that could fit within DAC. This needs to be scalable. I decided to break down things in this fashion:
01
Define the user and decision first
The first principle in the dashboard guidance needed to be that dashboards are not “for everyone.” They should be designed for a specific audience trying to make specific decisions. The guidance calls out DAC users such as IT admins or people responsible for license provisioning, who may report results to CMIOs. Rather than focusing on “What charts should we include?”, I wanted to focus on “What decision does this person need to make, and what information helps them make it quickly?”
02
Establish a consistent DAC dashboard anatomy
The guidance needed to define how dashboards should behave within the DAC shell. Because DAC already provides navigation and context, the report should not recreate navigation or add a secondary left-side navigation inside the report. The way that DAC is created, new reports would be rendered in an iFrame into DAC, which means that it would display any additional navigation that a developer creates in the iFrame in the middle of DAC.
The dashboard anatomy guidance also needed to define page headers, filters, and the top-down hierarchy
This gives partner teams a concrete structure:
Header: orient the user to what they are viewing.
Filters: predictable segmentation without making the data hyper specific.
Top: high-level KPIs and quick signals.
Middle: drivers and comparisons.
Bottom: detailed tables.
03
Create rules that scale across products
The goal was not to create one perfect dashboard but to create a system that could work for Dragon Copilot, Nursing, Physician, Radiology, future apps, and platform extensions. As more products get released by Microsoft that need to be on DAC, more reports will be created, each with their own product specific needs. The boundaries of the system have to be shaped in a way that emphasizes who the user is specifically (an IT administrator) and someone that plans based on what they see in the data, rather than a person who just wants to see all data.
04
Make the guidance actionable for non-designers
As I am just one person who oversees the analytics framework, I want to make sure that people can utilize the guidelines even if I am not available to answer questions. I wrote out the documentation in non-technical language to help those who may be new to the system as well as provided visuals for each part that is discussed.
In addition to this, I provided a Copilot self-critique prompt that asks for the top five UX and information design issues, severity, why each issue matters, exact fixes, and the “if you only fix one thing” recommendation. I also provided an agent that I created that people could download into their project space that utilizes the guidelines I have created and helps guide the user on triages different visuals for them to best represent data. I wanted to create an enablement mechanism for teams to feel empowered to create with the guidance of AI.
05
Tie platform guidance to future analytics strategy
The work expanded beyond immediate dashboard standards into broader platform questions: where analytics should live, how tenant-level analytics should work, how product-level analytics should relate to environment-level analytics, and how admins might compare usage across multiple apps or agents. In my analytics guidelines, the discussion covers analytics tabs, environment-level views, product-level reporting, tenant-level reporting, and the challenge of combining products that measure usage differently.
The biggest challenge was balancing consistency with flexibility. DAC needed a cohesive analytics experience, but different product areas had different reporting needs. Diagnostics and radiology, for example, raised deeper analytics needs that challenged the initial overview-oriented model. Expanding the analytics model for one product could affect consistency across DAC and therefore needed broader alignment.
Another challenge was defining where analytics belongs in the product. The tenant-level analytics explored whether analytics should live under individual products, at an environment level, or in a broader analytics home, especially when users may need to compare usage across products, apps, or agents.
A third challenge was that user research revealed deeper gaps beyond layout, including inflexible segmentation, shallow usage visibility, invisible AI quality signals, reactive system health, and manual bridging from insight to action.
FINAL SOLUTION
I created the analytics design framework for Dragon Admin Center, turning dashboard design from a series of one-off report decisions into a scalable platform pattern. The guidance defined how teams should structure analytics inside the DAC shell, choose decision-grade metrics, organize overview and detail content, handle filters, and use AI-assisted critique to improve quality. This work helped partner teams build dashboards that were more consistent, easier to scan, and better aligned with how customer admins make decisions.
As Dragon Admin Center expanded to support more products, analytics risked becoming fragmented across teams, reports, and reporting tools. I created a scalable analytics design framework that helped teams build dashboards consistently inside the DAC shell. The work defined how dashboards should be structured, how metrics should be chosen, how filters should behave, and how teams could use AI-assisted critique to improve dashboard quality without waiting for a designer on every decision.
Below are some quick examples of things that are included in the framework:
Decision-first metrics
Dashboards should surface metrics that indicate health/status, provide direction, and enable action, rather than showing everything measurable.
Top-down dashboard hierarchy
Dashboards should put the highest-level information at the top and more detailed graphs or tables lower in the page so users can scan, understand, and investigate.
No duplicate navigation inside reports
The DAC shell already provides navigation, so embedded analytics reports should not add their own left-side navigation.
Filters should support decisions, not create sprawl
The guidance recommends filters such as date, organizational unit, user type, and modality, while discouraging filters that segment the data too narrowly, such as person ID, accession, or report number.
Shared guidance plus ai critique
The playbook, AI agent, and Copilot critique prompt made design guidance more scalable by helping teams self-check dashboard quality.
OVERVIEW & REFLECTIONS
The analytics guidance became part of the DAC design system and SharePoint onboarding experience. The playbook exists as a way to produce dashboards that are consistent, understandable in minutes, and safe to embed without waiting on a designer for every decision.
The dashboard guidance was also published into Azure DevOps wiki content. The Dashboard Anatomy wiki page includes DAC-specific dashboard rules, including no secondary side navigation, page header conventions, filter placement, and top-down layout.
The broader customer-facing analytics effort also “blazed the trail” for embedded Power BI reports in the Microsoft tenant on Dragon Admin Center, giving other product and engineering teams a smoother path to follow the established pattern.
Next project