How to Research a Company's UX in 30 Minutes Before Your Next Interview

I got an interview for Staff Product Designer. I had a couple of days to prep, so I sat down to do what designers have always done before an interview. I dug into the product.

My first instinct was to build a tool to do the research because I’m a builder. The thought was this, “I can build a little app that pulls reviews from G2 and Capterra and the App Store, runs sentiment analysis, and shows me the points of pain and friction. It’d help with every future interview. Maybe it could be a side product.”

Thankfully I paused and caught myself before heading to the terminal. I’d build the tool, get sucked into scrapers and rate limits and anti-bot protection, and maybe I’d have a half-working tool in a few days and zero research done for the actual interview that’s happening. Pausing for self-reflection as a practice saved my bacon today.

So I did the boring, correct thing instead. I just did the research in Claude by hand. It took 30 minutes. It produced better material than any tool I could have built. Then I turned the workflow into a Claude skill so I can do it again in 10 minutes next time.

Here’s the workflow and what it gives me for my interviews. The skill is at the bottom of this post.

Why some candidates don’t do this

Walk into a design interview and ask “what are your biggest UX challenges?” and you’ve told the hiring manager three things:

1. You didn’t use the product.
2. You don’t have your own opinions yet.
3. You expect them to do the work of framing the conversation.

We may do this because real research can take a full day. You had to find the reviews, read them, organize them, write up patterns, formulate questions.

The economics are different now. With Claude doing search and synthesis in parallel, you can do that whole pass in 30 minutes. Which means there’s no longer an excuse not to.

Now, I should say, this is a summary of what’s been extracted from the sources this skill searches. It’s your job to review for yourself to think critically about the output and think through the issues raised.

The 30-minute workflow (as summarized by Claude)

The skill goes through seven steps after you pass the name to it. Duration is a rough estimate.

Step 1: Scope (2 minutes). Names the product and note whether it’s B2B SaaS, consumer mobile, consumer web, developer tool, marketplace, or mission-driven tech. Different categories have different signal-rich sources.

Step 2: Broad search pass (10 minutes). Do six or so parallel queries: G2 reviews, Capterra reviews, App Store reviews if mobile, Reddit, “alternatives to X” (reveals competitive friction), and Glassdoor (for internal product team complaints). Capture verbatim quotes with source names.

Step 3: Friction-targeted pass (5 minutes). Search with negative-sentiment anchors: [product] frustrating, [product] confusing, [product] missing feature, [product] doesn't work. Different sentiment words surface different shapes of complaint.

Step 4: Read the product’s marketing (5 minutes). Reading marketing first anchors you to the team’s framing. Read it last and the gap between promise and reality jumps out.

Step 5: Pattern-match (5 minutes). Group complaints into categories: wayfinding, error handling, onboarding, performance, feature gaps, integration friction, pricing clarity. If two or more independent reviewers mention the same thing, it’s a pattern. One-off complaints are noise.

Step 6: Generate improvements and questions (5 minutes). For the top two or three patterns, draft a concrete change and the framing for a question. Each question should reference a specific finding, not a generic platitude.

Step 7: Write it up (5 minutes). Friction patterns with quotes. Two or three improvements. Three to five questions. Under 1,500 words. If it’s longer, you’re hedging.

That’s it. The whole thing is in a Claude skill I’m sharing below.

Review the output

I ran this pass on the company I was interviewing with. For an example of what it outputs, here’s a sample of what the research produced using Notion.

Notion UX Sentiment Research

Sources scanned: G2 (10,149 verified reviews), Capterra (4.7/5 across 2,000+ reviews), Reddit (r/Notion), UX Planet, Medium, Hacker News, and targeted Google searches across alternatives discourse.

Time spent: ~30 minutes of search and synthesis.

The pattern: the flexibility that sells Notion is the same thing that breaks it

Every major friction cluster in Notion traces back to one architectural decision: the product is a canvas, not a system. That’s the pitch and the problem. Power users love it. Everyone else hits a wall somewhere between “open blank page” and “have a working workspace.” The complaints are not random — they cluster around four consistent themes, and they’ve been consistent for three years across independent reviewers.

Top friction patterns

1. Blank canvas paralysis. New users open Notion and find themselves asking “What’s a block? What’s a rollup? Why are there five database types?” (Medium, Hetvi Desai). The template gallery partially addresses this, but templates teach the format, not the logic. Users still have to understand the underlying data model before the tool clicks. Nuclino’s documentation on Notion alternatives summarizes the pattern: “Notion gives users a blank canvas rather than a system, requiring hours of building databases, templates, and views before actual work can begin. Once built, Notion systems require ongoing maintenance as pages pile up, databases get stale, and the system slowly becomes a graveyard of good intentions.”
2. Search doesn’t scale with the workspace. The more information lives in Notion, the harder it is to find anything. Quick Find doesn’t cover subpages. There’s no global search across databases from the main search bar. Keyword search “may fail to return relevant content that doesn’t mention the search keyword directly” (Unleash). The painful irony: Notion markets itself as a second brain, but the search behavior actively undermines that promise at scale. Hacker News threads describe it plainly: “with everything in Notion, finding things becomes tricky — especially with quick search… if everything is in Notion, the number of search results will increase and increase, so finding anything will take longer and longer.”
3. Performance degrades once teams actually use it. Databases over 5,000 rows load in 3–5 seconds. Databases over 10,000 rows make Notion “impractical as a primary database” for enterprise teams (NotionBoost). The root cause is architectural: Notion stores every element as an individual block in a centralized database, which creates exponentially more overhead as workspaces grow. Notion’s own help center has a dedicated article on “optimizing database load times” — which is a tell. When the product needs a help article for a performance workaround, it’s a systemic issue, not an edge case.
4. The May 2025 AI pricing change felt like a bait-and-switch. In May 2025, Notion retired the $10/month standalone AI add-on and bundled AI exclusively into Business and Enterprise plans. Free and Plus users now get 20 lifetime AI responses — total. Plus subscribers who had been paying $10 (plan) + $8 (AI add-on) = $18/seat lost AI access without an upgrade to $20/seat Business. Reddit’s reaction was mostly negative. Multiple review aggregators document users describing it as a trust breach. The capability didn’t change. The pricing architecture changed around them.

View the whole example on Github. The rest of the output includes a summary of what the friction points might tell you about the product team and a read on the product’s maturity stage. Take what’s useful to you as a starting point, but be sure to evaluate each point.

The report goes on to suggest areas for improvement, each anchored in a specific finding from the research. Do with that what you will, but I wouldn’t regurgitate this. For example, you might see a suggestion like this: “the most consistent friction in your Capterra reviews is wayfinding.” That could provide you with some specific questions you might ask, but make sure your question is grounded in the current reality in case the research is based on outdated information.

What this gets you

A few things change when you walk in with research like this.

• Asking question about a valid concern gives the interviewer a sense that you’ve done the work to research the product. With luck, the conversation might start to feel like a peer conversation, rather than a candidate audition.
• You stop being the candidate and the interviewer may see you as a person who could already be on the team who’s just having a working conversation about the product.
• You catch signals you’d otherwise miss. For instance, if you ask about IA work and the interviewer’s answer treats it as cosmetic, you learn something important about the role. If the answer treats it as structurally important to wayfinding, sensemaking or navigation, you learn something different. Either way, the question reveals fit.
• Interviews are designed around them evaluating you. Research flips part of that. You’re evaluating them too, with specifics.
• You give the hiring manager a clean way to advocate for you. After the interview, when they tell their team about the candidates they met, you’re the one who said something concrete about the product. That’s a much easier story to retell than “they seemed nice and gave good answers.”

Why this is pairing, not prompting

The instinct some might have with Claude is to write one long prompt and hope it works. “Research [Product X] for me and give me everything I need for my interview.” That’s transactional prompting. You ask, Claude answers, you take what comes out.

Pairing is different. You stay in the loop. You read the first round of results, you notice a pattern, you steer the next search at a friction word, you read the marketing site after the reviews not before, you push back on a finding that feels thin. You don’t leave your critical thinking behind.

The skill I’m sharing below codifies that pairing pattern. It’s a workflow with checks and time-boxes and decisions about when to stop collecting and start synthesizing. This is the difference between designers who use AI well and designers who don’t.

Stay in the loop. Don’t outsource the thinking. Use the model to optimize the parts that can be executed to make you efficient (search, parallelism, formatting). Hold onto the parts that shouldn’t be left to the LLM (judgment, pattern recognition, what to ask next).

The skill

I packaged this as a Claude skill you can drop into your Claude Code setup or use as a workflow template in Claude chat. It includes the methodology, the source matrix by company type, and the query patterns that consistently surface real friction.

How to install it:

1. Download ux-sentiment-research.skill
2. Drop the folder into your skills directory. Next time you have an interview, just say “research [company] for my interview using ux-sentiment-research” and let Claude work the pattern. Or you can use the slash command, e.g. /ux-sentimentresearch [Product]

You’ll find instructions for how to use with Claude Code or Claude.ai (web and desktop).

What I’d love to hear

If you run this on a company before an interview, I want to hear two things:

1. Did it surface something you wouldn’t have found in 30 minutes by hand?
2. Did it change how the interview itself went?

Find me on LinkedIn. I’ll be refining the skill based on what people actually report back.