Research process

How I Research

A look at how I scope, run, synthesize, and connect research to product decisions.

Most of my work starts before any design decisions are made. I've spent the last several years embedded in enterprise environments where the cost of building the wrong thing is high and the workflows are too complex to understand from a conference room. That context shaped how I approach research — less about running a standard playbook, more about figuring out what kind of problem I'm actually dealing with before deciding how to study it.

01 — Scoping

Before I write a discussion guide or recruit a single participant, I try to get clear on what the team actually needs to know and what decision the research is serving. A lot of research fails not because the methods were wrong but because nobody agreed upfront on what a useful answer would look like.

I typically start by mapping what's already known, what's assumed, and where the real uncertainty is. That usually surfaces the actual research question underneath the one I was handed.

02 — Recruiting & Access

Getting to the right participants is often the hardest part, especially in enterprise contexts where users are hard to reach and protective of their time. At Union Pacific I worked through internal stakeholders to get time with warehouse workers during active shifts. At T-Mobile I coordinated access to CARE Experts and Mobile Experts across call center and retail environments.

I've learned to treat recruiting as a design problem — the framing of the ask, the timing, the incentive structure all affect who shows up and how open they are.

03 — Methods I Reach For

I use mixed methods and match the approach to the question.

Contextual inquiry — when I need to understand what people actually do, not what they say they do. My Fort Worth warehouse session at Union Pacific surfaced usability issues with Zebra handheld devices that no lab study would have caught.

User feedback sessions with prototypes — when I need directional signal on a design decision quickly. Most of my T-Mobile work ran this way — testable artifacts in front of real CARE Experts inside their actual workflow context.

Ethnographic observation — when behavior is the data. Watching 7 T-Mobile retail locations during live device upgrades told me things about billing transparency that no interview could.

Journey mapping — when the problem is systemic and spans multiple touchpoints or teams. I've run cross-functional mapping sessions that brought together engineering, product, CX, and operations in the same room to find where handoffs break down.

AI-assisted synthesis — I use Dovetail AI to accelerate clustering and pattern identification across large transcript sets. It cut my synthesis cycles by ~40% at Union Pacific without replacing the analytical judgment about what the patterns actually mean.

Contextual inquiry at Union Pacific's Fort Worth facility

Observing Zebra handheld workflows in an active warehouse environment

04 — Synthesis & Translation

This is the part I think about most. A lot of research stops at findings — here's what users said, here's what we observed. What I try to do is go one step further and make explicit the connection between the insight and the decision it should inform.

At T-Mobile the bill comparison research didn't just validate a prototype. It reframed the problem entirely — the tool wasn't the issue, the billing experience was broken at a systemic level across eight journey phases. That reframe changed the roadmap, not just the UI.

I document synthesis in whatever form will actually get used by the team — journey maps, user role cards, service blueprints, or a one-page brief with a clear \'therefore\' at the bottom.

Omni-channel billing transparency journey map for T-Mobile — Omni-channel billing transparency journey map — T-Mobile

Supply chain process flow mapping at Union Pacific — Supply chain process flow mapping — Union Pacific

05 — Connecting to Design

I don't hand off research and move on. The most useful thing I can do after synthesis is stay in the room while design decisions get made — flagging when a direction contradicts what the research showed, and helping the team understand the tradeoff they're making if they choose to move forward anyway.

At Union Pacific I evaluated four technical approaches to the contract workflow problem and made a recommendation with explicit UX rationale. That's the moment where research earns its place in the product process — not as a validation step at the end, but as the thing that shapes what gets built.

Usability testing findings feeding directly into SAP Fiori design decisions

If you want to see any of this in practice, the T-Mobile and Union Pacific case studies show the full arc from research question to design outcome.

T-Mobile case study Union Pacific case study