Distilling messy data into human logic.
I turn ambiguous, high-stakes B2B signal (compliance risk, support-ticket language, forum complaints, how customers actually hand trust to an AI agent) into research systems that product and legal teams act on, not reports they file away.
Selected work
Six systems, not just six studies, tagged the way they actually live in our shared research repository.
About
I've built my career as a UX researcher and designer across enterprise software companies, spending the last several years as Principal UX Researcher at Coupa. I started as the first UX research hire at a mid-market software company, building a research practice from scratch and leading the research strategy behind a full desktop-to-web platform migration for enterprise clients.
These days I split my time between hands-on research, building the systems that let that research reach the people who can act on it, and mentoring the researchers, designers, and product managers who do it alongside me. My range spans mixed-methods research and quantitative synthesis to stakeholder facilitation and research enablement, applied across procurement, risk management, and AI product domains.
Scaling research
Good research doesn't scale by hiring more researchers. It scales by building the channels that get it in front of people, and the systems that let more people contribute to it. Alongside the work above, that's shown up as a recurring internal newsletter surfacing findings across the company, co-presenting with Product Leaders at Coupa's Customer Advisory Boards, running the UX Research booth at Coupa's annual Inspire conference (which doubles as a recruiting pipeline), and presenting case studies live on the Inspire Expo Hall stage.
Bridging UX Research and Compliance
Turning a research signal into an early-warning system for Legal and Product, not just usability feedback.
How it started
My mentor, Coupa's SVP of Legal, asked me directly what Compliance could learn from UX research. The question landed at a good moment: research had long since surpassed the history of usability testing happening too late to change anything and I'd already been building deeper, earlier relationships with product teams to get ahead of product-direction decisions instead of reacting to them. I proposed that UX research act as a signal to Compliance whenever compliance-relevant topics came up in ongoing research, right as Legal was independently repositioning itself from a rubber stamp into a strategic partner. My mentor was enthusiastic, and we've been partnering ever since.
The problem
Compliance and legal risk kept surfacing in user research: regulatory blockers, data-governance concerns, workarounds customers built outside the platform just to stay compliant. But none of it had anywhere formal to go. It lived and died inside individual research reports.
What I built
A lightweight four-tag system: a compliance barrier (a legal or regulatory rule blocking adoption), a data-governance concern (storage, access, or audit-trail questions), conditional adoption (the "only if" constraints customers state before deploying), and a workaround (customers bypassing the product with outside tools). Each tag routes to an action: Product gets a prompt to revisit feature logic, Legal gets an early warning. I trained a small group of researchers to apply the tags consistently, added a quality-review process and a recurring audit cadence, and centralized everything in our shared research repository. AI-assisted synthesis cut analysis time from roughly two weeks to about two days.
Getting Legal to trust research
The harder problem wasn't building the taxonomy. It was getting Legal to trust UX research as a signal source at all. That meant reframing research as risk intelligence, not just usability feedback, and proving it with real findings before asking for a standing seat at the table.
Where it stands
Tagging is now part of standard research reporting. It's already surfaced real findings, including adoption blockers and shadow-IT risk tied to a new feature launch, directly to Legal and Product, and it's expanding into a regular sync with Compliance and a standing presentation slot at their council meetings.
What I took from it
A finding sitting in a report isn't the same as a finding reaching the right person at the right time. Building the distribution channel mattered as much as the analysis itself.
Building a Friction Index from Support Ticket Data
Reading the language inside support tickets as research data, and finding one workflow years overdue for a real fix.
The goal
My team set out to build what we called a friction index: going beyond raw ticket-volume counts into the actual language inside support tickets, looking for signal trends nobody was tracking yet. One product area, invoicing, stood out immediately: it had never had formal UX research done on it, only decade-old personas, and it carried an outsized share of our ecosystem's support tickets.
How it grew
Early into that analysis, the product's own design team reached out independently. They were planning a UI and workflow redesign and needed current personas, plus a sanity check on whether they'd correctly identified the flows and gaps. The two efforts merged into one.
What I did
I compiled every piece of prior research that touched the product, pulled qualitative data straight from its public community forum, and combined that with the design team's open questions to build an interview script for a new round of customer interviews. In parallel, I mapped support-ticket patterns against validated research findings, and found that many of the highest-volume ticket categories were issues we'd already identified and never resolved.
What I found
The same gap showed up in every workflow we examined: a consistent difference between the experience as designed and the experience customers actually had. Manual work stood in for automation that didn't hold up under real use, verification steps broke down at scale, and customers had built their own workarounds outside the product entirely. A small number of large accounts drove a disproportionate share of the ticket volume.
Impact
The design team agreed the backend and workflow issues needed fixing before any UI refresh went forward, and the project reframed from a visual redesign into a more fundamental fix.
What I took from it
Support tickets are a research data source, not just an operations metric. Reading the language inside them, and connecting it back to research, was more convincing than either one alone.
The Admin Role, Then and Now
What AI actually changed for the person running the system: a workload-and-trust problem hiding behind a training narrative.
What I kept hearing
While researching AI features, I kept hearing the same blunt request from administrators: stop pushing new AI capabilities and fix the features that already exist.
What changed, and what didn't
I compared the administrator role as it exists today against several years ago: same core goals, a very different day-to-day. The role had evolved from reactive ticket-fixing into something more strategic: system design, process advocacy, and now evaluating and configuring AI tools. But the automation AI had promised hadn't fully materialized. The manual work stayed, and a new layer of AI oversight, testing, and troubleshooting got added on top of it.
A second data point
Parallel research into AI feature pricing found customers couldn't reliably predict or forecast their AI credit costs. It reinforced the same conclusion from a different angle: AI was landing as more to manage, not less to do, and that was independently suppressing adoption too.
Impact
This reframed slow AI adoption for this role: from a training-and-communication-gap story into an evidence-backed workload-and-trust problem. It redirected prioritization toward fixing cost forecasting and easing the oversight burden, instead of pushing harder on adoption messaging.
What I took from it
This is one of the findings I'm proudest of, because it's a counter-narrative result (AI reducing workload less than promised) rather than one that just confirms what everyone already believed.
Turning Community Complaints into a Product Decision
Taking a forum's loudest critics seriously enough to reverse a mandatory rollout.
The problem
A redesigned item-management interface rolled out as a mandatory replacement for every customer. Within days, our community forum lit up with complaints about added complexity and extra clicks.
What I did
I read through the forum threads to find the most vocal, detailed customers, then ran interviews where they screen-shared and walked through the new interface live, narrating exactly where they got stuck.
What I found
The complaints held up under direct observation. These were specific, reproducible issues, and they showed up as measurable increases in effort for routine tasks, not just preference complaints.
Before: Mandatory Rollout
- Open item
- Click edit icon
- Redirected to "Create New"
- Re-enter data
After: Customer-Controlled Opt-In
- Toggle setting
- Choose interface version
Impact
The product team added an opt-in setting so customers could migrate to the new interface on their own timeline, instead of a forced switch. That's a reversal of the rollout strategy itself, not a cosmetic tweak.
What I took from it
It reinforced the value of going straight to a forum's loudest critics instead of dismissing that noise. They were usually right, and usually specific.
Trust and Auditability in an AI Agent-Building Studio
A year inside how customers decide how much autonomy to hand an AI agent.
Ongoing research, year oneThe problem
As customers began configuring their own agents inside an AI agent-building product, the same signal categories from my Legal and Compliance tagging work started showing up here too: mostly data-governance questions (can they see and audit what an agent actually did) and workarounds (choosing to do a task manually rather than hand it to an agent).
What I'm doing
Roughly a year of ongoing research into how customers configure, test, and build trust in agents over time, with particular attention to the moments a customer declines to give an agent more autonomy.
Impact so far
These findings are directly feeding product and security conversations about what agent activity needs to be visible, reviewable, and reversible before customers extend it more trust.
What I'm taking from it
This sits on the same throughline as the compliance-tagging work: the same class of concern, auditability and workarounds, resurfacing as the product itself evolves toward more autonomous features.
Certified UX Observer
Scaling discovery across the product org without scaling research headcount.
The problem
Demand for baseline usability checks and workflow validation was outpacing what a small UX research team could cover on its own, across every market Coupa operates in. Every ad hoc request (a quick sanity check on a new flow, a post-release validation) competed with the foundational, strategic research only the core team could do. Something had to give, and headcount wasn't the lever available.
My approach
I designed a governance framework and a short certification program that trains non-researchers (product managers, designers, product-ops leads) to run tightly scoped, low-risk evaluative studies themselves: usability sanity checks, workflow-gap spotting, post-release validation. Certification is one live workshop covering unbiased moderation (open-ended questions, sitting with silence instead of filling it) plus how to log sessions into the shared research repository correctly, followed by shadowing a real research-led interview.
The design leans on boundaries, not trust alone. A self-service intake screener asks three questions before anything gets scheduled: is this evaluative rather than foundational, does it avoid sensitive or high-risk territory, can it realistically be logged within 48 hours. Anything that fails routes straight back to the research team. Certified observers also apply the same compliance-signal tagging system from my Legal and Compliance work, so whatever they find lands in the shared repository in a form Legal and Product can already act on.
Stakeholder navigation
The real resistance wasn't from the observers. It was convincing the research team that widening who could do discovery wouldn't quietly erode data quality. I addressed that with hard scope limits on what a certified observer can touch, plus an ongoing audit: researchers spot-check newly tagged sessions weekly, and anyone who goes quiet has to recertify before running another one.
Impact so far
The program is in its pilot phase, with an initial cohort of five product managers and designers certified and running their own sessions. The next phase expands certification across product, design, and product-ops, increasing how much tactical discovery gets captured in the shared repository without adding to research headcount, while holding tagging accuracy to a standard the research team audits weekly.
What I took from it
Democratizing research isn't the same as giving up control of it. What made this safe to scale wasn't trust in good intentions. It was being explicit, in advance, about exactly where the line between "an observer can do this" and "this comes back to research" sits.