Research as the Foundation, Not the Preamble
Early in my career, I watched a product ship that had been built entirely on stakeholder assumptions: no user interviews, no usability testing, no data. The product was logically sound on paper. Users hated it. The features they'd built answered questions nobody was asking, and the problems users actually had went unsolved.
That experience crystallized something I've carried through every project since: research is not a step you do before design begins. It is what design is. Every sketch, every wireframe, every design decision is a hypothesis about user behavior. Research is how you test those hypotheses before the product ships instead of after.
Over 12+ years spanning Yahoo! and eBay, I have led and contributed to research programs across the full spectrum: from scrappy guerrilla testing in hallways to structured longitudinal diary studies, from Mixpanel funnel analysis to moderated usability testing with eye-tracking. The methods change by context. The commitment to evidence doesn't.
A Multi-Method Practice
No single research method answers all questions. I select and combine methods based on what I'm trying to learn, the fidelity of the design, and the time and budget available. Here are the methods I practice most frequently and the questions each is best positioned to answer.
User Interviews
Semi-structured conversations that surface mental models, motivations, and the "why" behind observed behavior. Best for early discovery and hypothesis generation.
Diary Studies
Longitudinal self-reporting by participants over days or weeks. Captures real behavior in real context, the experiences that don't show up in a one-hour session.
Contextual Inquiry
Observing users in their actual environment, at their desk, in their workflow, with their real tools. Reveals friction and workarounds that users never mention in interviews.
Usability Testing
Structured task completion with think-aloud protocol. Identifies where design fails users and why, the fastest, cheapest way to find problems before they ship.
A/B Testing
Controlled live experiments measuring the impact of design changes on real behavior at scale. Best for validating hypotheses that require statistical significance to trust.
Analytics Review
Quantitative analysis of product usage data: funnel analysis, drop-off mapping, feature adoption rates. Tells you what is happening; pairs with qualitative methods to tell you why.
Stakeholder Workshops
Structured collaborative sessions with internal stakeholders to surface assumptions, align on problem framing, and build shared understanding before design begins.
Empathy Mapping
Synthesizing research observations into a structured map of what users say, think, do, and feel, making research findings tangible and actionable for design teams.
Journey Mapping
Visualizing the end-to-end user experience across touchpoints, exposing gaps, pain peaks, and moments of opportunity that product-centric thinking misses.
How Research Shaped Key Design Decisions
Research findings only matter if they change what you design. Here are four examples where research directly redirected a project, where what we learned from users overruled what we assumed, and made the product significantly better.
When Sellers Told Us the Real Problem Was Trust, Not Effort
We assumed the pain point was time. Sellers told us something different. "I never know if I priced it right. I don't know if my photos are good enough." The real problem wasn't effort. It was confidence. That single insight redirected the entire design from a faster listing flow to an AI assistant delivering real-time pricing benchmarks and quality signals.
Seller journey map: identifying the confidence gap
Seller personas: casual vs. power seller needs
When a Single Observation Changed the Design Direction
During a contextual observation, a senior account strategist spent five minutes navigating menus before saying: "I spend more time finding campaigns than actually analyzing." That one sentence reframed the entire project. We redirected from building a better data visualization system to building a better navigation system first.
Research synthesis: user goals vs. current system affordances
Analytics review: navigation drop-off mapping
When Quantitative and Qualitative Research Told Different Stories
Analytics showed users spending significant time on data tables. The team called it success. User interviews told the opposite story: users were struggling, not thriving, hunting for buried data and copying it into spreadsheets. High time-on-screen was a measure of friction, not engagement. Research corrected a misinterpretation that would have left a broken experience untouched.
When Users Blamed Themselves for a System Failure
Spam had measurable false-positive rates, yet satisfaction surveys looked fine. Interviews revealed why: users blamed themselves, not the system. "I must have accidentally marked it." Almost no one attributed the failure to Yahoo! Mail itself. That finding redirected the work from improving filter accuracy to designing transparency and recovery mechanisms that rebuild user trust.
Research insight: users attributing system errors to personal mistakes
Design outcome: transparency and recovery patterns for spam false positives
Research Is Not a Phase. It Is a Practice
The phrase "we don't have time for research" is one of the most expensive things a product team can say. Every hour not spent in research is potentially hours, weeks, or months of engineering time building the wrong solution with high fidelity. Research is not a luxury for well-funded teams. It is insurance against shipping at the wrong answer faster.
My approach to research is grounded in a few core beliefs:
- Users know their problems; designers know the solutions. Never ask users to design the product for you. Ask them to show you their world. Design emerges from deep understanding, not feature suggestions.
- Volume of participants is not the measure of rigor. Five well-recruited, well-interviewed participants in the right context will surface more signal than a survey of 500 wrong ones. Method selection matters more than sample size.
- Research findings must travel. Insight locked in a research report that no one reads is not insight. It is wasted effort. Research synthesis, storytelling, and stakeholder communication are as important as the research itself.
- Quantitative data tells you what is happening; qualitative data tells you why. Neither is sufficient alone. The strongest product decisions integrate both: the scale of the data and the humanity of the story.
- Validation is not the same as research. Research that only confirms what you already believe is not research. It is confirmation bias with a budget. Good research must be genuinely open to disconfirming your assumptions.
That question sits at the center of everything I design. Research is the only way to know if you've answered it honestly.
Want to see the research documentation?
Full research artifacts, including interview guides, synthesis boards, journey maps, usability test recordings, and analytics breakdowns, are available on request.
Connect on LinkedIn