Research for the people who keep systems running
Senior UX researcher. Windows Mobile, BlackBerry Messenger, Skype, Azure Monitor, Azure Arc and Microsoft Fabric.
A note on visuals: out of respect for Microsoft's confidentiality, this portfolio contains no internal screenshots, slides or documents. The diagrams are my own redrawings and show how each study worked, not product designs.
Good design comes from close conversation, not handoffs over the wall. Research informs design, design informs research, product managers bring the business, and developers bring what's technically possible. My part is to bring the user's voice and help those angles converge.
I think of a team like a piano trio. It isn't the score or a conductor that holds the players together. Each player knows their part and listens to the others, and the lead passes from cello to piano to violin. The stories below say which line was mine and what the team achieved together.
Results, conversation, and brainstorming toward solutions. During a study I share quick write-ups and talk the findings through with the designer, PM and developers, and we push back on each other until we agree on what is going on. The most critical issues get logged as change requests, so they become tracked work, not just recommendations.
The formal readout for the wider team and leadership then covers the findings, what the team is doing about them, and options for follow-up studies. Everything is filed in the research repository.
From 2018 to 2026 I researched tools for the people who keep cloud systems running: IT admins, SREs, DevOps engineers and developers on Azure, and data engineers on Microsoft Fabric. The work covered monitoring and observability (Azure Monitor), hybrid and multicloud management (Azure Arc), troubleshooting and self-help, and AI-assisted operations. Three of the four stories below come from that work.
I'm still hands-on. On Microsoft Fabric in 2026, I ran proof-of-concept interviews with enterprise data engineers myself and used AI to code the transcripts against our hypotheses, checking each against my own read of the session. The findings moved AI from a first-class to a supporting experience, and the concept shaped the first phase of Monitor Hub, announced at FabCon Europe 2026.
Benchmarking runs through my whole career. As release cycles shrank from a year to one-week sprints, I kept making benchmarks faster to keep up.
| Years | Where | What I benchmarked |
|---|---|---|
| Mid-2000s | Windows Mobile | Competitive UX scorecards against rival phones, with international vendors running our protocols; earned Microsoft Technical Excellence recognition and an invitation to speak |
| 2010 | BlackBerry | Scorecards on the BBM pre-release build, showing which agreed fixes were still open |
| 2013 | Skype | Red, yellow and green accessibility scorecards across 15+ Lync and Skype experiences |
| 2015 | Skype | A review of 16+ competing messaging apps; I defined the core tasks and ran most of the evaluations. Skype sign-up took 12 steps against a typical 6 |
| 2018–2020 | Azure Monitor | Recurring benchmarks across Metrics, Alerts and Logs; Metrics Explorer went from 61% to 93% |
| 2021–2023 | Azure Arc | Led the working group that set the benchmark process standard for the Simplicity initiative |
| 2024–2025 | Azure troubleshooting | Directed VM and AKS benchmarks; a 7% lift in VM troubleshooting task success |
Metrics Explorer: from near-failing to passing 2018
Metrics Explorer's overall UX benchmark score rose from 61% to 93% between March and November 2018.
Context. Metrics Explorer is where Azure customers chart the health of their cloud resources. Its first benchmark scorecard came back red. Users struggled to build a chart: they had to know which parameters to enter, and choosing the right scope was hard.
My part. I ran the benchmark and worked day to day with the designer, the PM and the developers, sitting with the dev team. I didn't just hand over a list of findings. I interpreted them and pointed to where the design could improve, including the metric "pill" selector, which turned each part of a chart into a simple drop-down.
What changed. Findings led to designs, then validation, then implementation, round after round until the scorecard turned green. The PMs took the scorecard into product reviews with Azure's executive leadership.
The wider fix. Metrics, Alerts and Logs each had their own engineering team, in the US, India and Israel, and each had its own scope picker. I was the one researcher supporting all three. Using benchmark data, I made the case to each group PM that scope was a core experience holding back the benchmark leadership watched. All three agreed on one common Scope Picker.
Working fast. I ran these benchmarks often enough that I rebuilt the process for speed: shorter sessions, templates ready in advance, standard questionnaires, a scorecard spreadsheet that turned raw ratings into a ready-to-paste table, and the readout deck built before the sessions. A full 20-user benchmark took one week.
Accessibility under a legal deadline Skype, 2013
An evaluation protocol adopted across the Skype org, covering 15+ Lync and Skype experiences on desktop and mobile. Accessibility issues moved to the front of the engineering queue.
Context. A US accessibility law, the CVAA, carried penalties set by the courts. Every Lync and Skype experience had to be tested, and its issues fixed, on a short timeline.
My part. I led the UX research response to Skype's CVAA compliance effort, which engineering and UX ran jointly. I wrote the accessibility test plan: a core task list, success codes and a red, yellow and green scorecard, written so researchers at other sites could run it. I also developed the scoring and pass bar used to benchmark Skype apps across platforms.
The lab. I convinced Central Usability to convert a usability room into an accessibility lab. Disabled colleagues taught me what it needed: temperature control, a darkened room and big screens for low-vision users, and a clear walking path from the shuttle stop.
What changed. Findings drove engineering changes, and the team tagged CVAA issues so they rose to the top of the queue. I co-authored 8 design principles for blind and low-vision users, drawn from 27 studies with 150 participants across the program; they address 85% of the 496+ issues found. The work also led to a patent on screen magnification (US 10,222,927).
A benchmark process that held up through a hiring freeze 2021–2023
UX benchmarks on Arc Server, Arc VMware private cloud, Tags and Azure VMware Solution kept running through a hiring freeze. Engineering teams committed to multiple improvements from the Arc results, and a sister team finally got an Azure VMware Solution benchmark that had stalled for over a year.
The problem. As the research team grew, each researcher ran benchmarks their own way. That made scores hard to compare: is one product's 80 the same as another's? Any difference in scores should come from the product, not from how we ran the study.
My part. I ran early benchmarks for the Simplicity initiative myself, then led the working group that defined the process other teams used. I wrote:
- readiness criteria for which product areas could be benchmarked
- a process standard: each task over 80% success and 80% experience score, success defined by four tests (finished, knew they had finished, felt confident, within 3x an expert's time), and 10 Azure plus 10 non-Azure participants
- guidance on end-to-end tasks versus independent tasks, and on writing tasks that test the design, not the instructions
- a simpler rating instrument, cutting five rating dimensions to three and replacing SUS with MeasuringU's UX-Lite and Level of Confidence
The freeze. Then hiring froze. Running benchmarks would have pulled our researchers away from their product teams, where they learn what to study next. So I secured vendor funding through June 2023, and vendors ran the benchmarks to our standard. Our researchers stayed close to their teams.
What came next. The program passed to a full-time senior quantitative researcher. I also shifted the benchmark role toward quantitative researchers who could query Azure usage data and find patterns in how people actually use the product.
Asked to test the words, I tested the task Azure Arc, 2021
The team paused to rethink how admins move from Azure Policy to server configuration before building further.
The ask. Test the wording of Arc Server Guest Configuration, a feature for checking and applying settings inside servers.
My approach. If I'm recruiting people and taking an hour of their time, I make sure we answer the bigger question too, not just the one we were asked. I tested the portal and the Bicep API together, with 10 IT admins in the US, Europe and India, against five written hypotheses.
Method. One-on-one, 60-minute moderated remote sessions with a Figma prototype. Admins worked through four scenarios: assess the compliance of their resources, investigate the one non-compliant server, find the causes, and pass the findings to an audit team. Then they reviewed the Bicep API for deploying a configuration.
| Hypothesis | Result |
|---|---|
| Admins who audit will prefer the plain portal words "configuration" and "rules" | Supported |
| Admins who deploy will prefer the API's legacy words "assignments" and "settings" | Refuted: they wanted the API to use the portal's plain words |
| Admins who both audit and deploy can keep the two sets of terms apart | Supported |
| Junior admins will prefer the simpler portal language | Supported |
| Senior admins can switch between the API and portal terms | Supported |
What we found.
- The word "Guest" misled admins.
- Plain words mattered more in the portal than in the API: admins use the portal often, but set up the API once and leave it.
- The bigger problem wasn't wording. Admins got lost moving between Azure Policy and their server configurations.
What changed. I recommended three changes to make right away (plain portal terms, API comments that map API terms to portal terms, and clearer "Name" column headers) and five design explorations, including a clear navigation model between Policy and configuration. The discussion the study started led the team to pause and rethink the Policy-to-configuration workflow before integrating further with virtual machines.
- Naming a core Azure Arc concept (2020). My research ranked "deployment target" first. When that conflicted with existing API terms, I made the case from the data for Custom Location, which shipped.
- One VM or two (Azure Arc, 2021). A rapid study with about 10 IT admins and MVPs. I recommended shipping two resources now rather than waiting for a single-resource model, and letting real usage decide later.
- The mute icon (Skype for Business and Teams, 2016). A 400-person study settled a year-long debate. The favored icon was misread 50% of the time, against 2–6% for the alternative.
- Call transfer for executive assistants (Skype for Business, 2016). Field observation, a survey and remote concept walkthroughs found that 91% of assistants ask the boss before transferring a call. The design moved to two top-level paths, "transfer" and "ask first".
- BlackBerry Messenger (2009–2011). Established BlackBerry's first UX telemetry program, and ran four rounds of research on BlackBerry Groups, which shipped in BBM 5 with an NPS of 50.
19 granted patents · M.A.Sc. Systems Design Engineering (HCI and Human Factors), University of Waterloo