← Builds

Build · Internal

UX Sentiment Research

Vendor-blind UX research that reads what users actually say about a product, separates friction from marketing copy, and writes you the questions to ask on the next call.

Local & private · Friction-theme tagging across noisy practitioner voice · Three-view output: Briefing / Critique / Prep

Challenge

The hardest part of researching a product isn't finding what the company says about it; it's finding what users say without the marketing copy drowning them out. Reviews are biased toward extremes. Forum threads are sparse. Reddit complaints sit right next to recommendations in the same post. Existing UX research tools either survey users you have to recruit yourself, or aggregate sentiment into a single 0-to-1 score that hides the actual story.

My reference point is Michael Angeles' UX sentiment analysis: close-reading practitioner voice with the editorial judgment that separates real signal from noise. That's the work I wanted, but at scale. Most products my team and I look at, we'd never get the editorial time to do at Michael's depth, so the usual choice was "trust the vendor's deck" or "skip it." I wanted a third option: something that reads the whole pile of practitioner-voice writing about a product, surfaces the recurring frictions, separates them from the marketing line, and tells me what a sales conversation should push on.

Build

The Briefing view of a real run: the dominant friction patterns, each with sample quotes and source attribution

The question was whether Qwen could carry enough of that pattern of attention, reading sparse snippets, recognizing friction beneath the language, and setting marketing claims against user reality, to extend the practice across a far wider portfolio. The hard part is that user friction shows up in sparse, off-topic-adjacent snippets, too thin for embedding similarity to cluster cleanly. So instead of embedding-first retrieval, the pipeline asks Qwen to tag each snippet with a short normalized friction theme (learning-curve-too-steep, billing-cancellation-friction, mobile-app-performance-slow) and then clusters the themes.

Marketing-vs-reality contradictions surface by matching the product's own claims against the resulting friction patterns. The output is a three-view report: a Briefing for the skim, a Critique for the depth, and a Prep view that drafts interview questions anchored to specific findings.

The Critique view: the product's marketing claims set against user-reported friction

Outcome

The Prep view: interview questions to ask the team, each anchored to a specific finding

A typical session returns a clear-eyed view of a product: the four-to-six dominant friction patterns with sample quotes and source attribution, two-to-three concrete UX improvements anchored to those patterns, marketing claims the evidence cannot substantiate, and a set of pre-loaded interview questions if you're about to talk to the company. Every claim links back to its source; when the evidence is thin it says so. The three views map to how the work actually gets used: Briefing in a stand-up, Critique in a strategy doc, and Prep on the way into a vendor call. It isn't replacing user-recruited research; it's the thing you do before deciding whether user-recruited research is worth the budget.

The Stack

Same pattern as Deep Research: Claude as pair-programmer for the hard parts, Qwen on local hardware doing the recurring work, including friction-theme tagging, pattern aggregation, marketing-vs-reality contradiction detection, and the synthesis itself. Nothing about the product I'm researching, or my notes about it, leaves my hardware.