I run a lot of user interviews with people who aren’t designers—clients, stakeholders, product managers, sales reps, and end users who use a product but don’t think in design terms. Early in my career I treated those conversations as either "market research" or "usability testing" and expected neat, actionable answers. That rarely happened. What I got instead were vague phrases: “It feels off,” “I don’t like that,” “It’s not intuitive,” or worse, long lists of feature requests that didn’t map to real problems.

Over time I learned how to run interviews that invite useful insight from non‑designers, and how to translate fuzzy comments into concrete UX fixes. Below are the approaches I use—practical, repeatable, and suited for small teams or solo projects.

Set expectations before the interview

Non‑designers often come to interviews with assumptions. They think you want them to “design” for you or to provide solutions. I start by disarming that impulse.

  • One‑line brief for participants: “I’m here to learn about how you do X so I can make that experience simpler or less frustrating.”
  • Explain your goal: “I’m not asking for perfect ideas—tell me what you wanted to do, where you got stuck, and how you solved it.”
  • Reassure them: “There are no right or wrong answers; your honest reactions are the most useful thing.”

Setting that frame reduces defensive or overly inventive feedback. People relax and describe behavior and motivation instead of prescribing a feature.

Use task‑based prompts, not design questions

Non‑designers often give opinions when asked about visuals or flows. Replace opinion questions with task prompts focused on real goals.

  • Poor: “Do you like this layout?”
  • Better: “Imagine you need to complete X—show me how you would do it.”

Task prompts produce observable behavior. Even if the user describes or talks through a process, you’ll get concrete signals: pauses, repetitions, confusions, and workarounds.

Ask probing, contextual questions

When someone says “It’s confusing,” probe for context. My go‑to follow ups:

  • “What were you trying to achieve just before that moment?”
  • “What did you expect to happen?”
  • “Can you show me where you’d click next?”
  • “Have you tried other ways to do that? What was different?”

These prompts turn vague judgments into specific situational details—what screen, what button, what intention. The aim is to capture the gap between intent and outcome.

Translate language into observable problems

Non‑designers speak in domain language or feelings. Your job is to map that to an observable problem statement you can prioritize and fix. I use a simple template for each note:

  • Evidence: what the user did or said (quote or action)
  • Context: where in the flow it happened and what they were trying to do
  • Problem hypothesis: a short sentence describing the friction
  • Impact: why this matters (time lost, errors, abandonment)

Example:

  • Evidence: “I didn’t know that was clickable.” (user hesitated and moved mouse around)
  • Context: On the dashboard, the icon for reports is an unlabelled glyph
  • Problem hypothesis: The report icon is not visually discoverable or labeled
  • Impact: Users skip a key feature, reducing engagement and perceived value

Use lightweight synthesis techniques

After 5–10 interviews, stop hoarding notes and synthesize. You don’t need a 50‑page report—use affinity mapping and a simple spreadsheet or board.

  • Put quotes and actions on virtual sticky notes (Miro, FigJam, or even Google Sheets)
  • Group into themes like “navigation confusion,” “copy unclear,” “missing affordances”
  • For each theme, write a short design problem (e.g., “Users can’t identify critical actions on the page”)
  • Estimate severity and frequency: How often did this occur? Did it block task completion?

This lightweight synthesis gives you a prioritized list of real problems rather than a pile of opinions.

Convert problems into actionable fixes

Once problems are clear, find fixes that are small, testable, and measurable. I aim for three types of actions:

  • Quick wins: microcopy changes, labels, button placement tweaks, or hint affordances. These can be shipped in hours or a day.
  • Design patterns: consistent visual affordances, improved hierarchy, or clearer navigation that require design + dev iterations.
  • Research follow‑ups: A/B tests or prototype tests when the fix has multiple plausible versions.

Example mapping:

Problem Unlabeled icons on dashboard
Quick fix Add labels under icons; use tooltip on hover
Pattern Create an icon + label component with accessible aria attributes
Follow‑up Prototype two label treatments and test completion times

Translate feedback into design tickets

Stakeholders love to provide ideas; designers and engineers need tickets. I write tickets that include the problem evidence, hypothesis, acceptance criteria, and a suggested solution—but I leave room for iteration.

  • Title: Make it action oriented (e.g., “Improve discoverability of reports on dashboard”)
  • Problem: One sentence and a quote
  • Acceptance criteria: What success looks like (e.g., 90% of test users click reports within 10s)
  • Suggested solution: Mockup or Figma frame with a clear change

That structure prevents tickets from being vague feature requests and keeps the team focused on solving user problems.

Bring stakeholders into synthesis, not into redesign

When non‑designers attend interviews, they often want to jump to “how to fix it.” I invite them to the synthesis session instead. Watching themes emerge helps them switch from idea mode to problem mode. Keep the session structured:

  • Share synthesized themes and example quotes
  • Ask stakeholders to rank problems by business impact
  • Co‑create acceptance criteria, not solutions

This gets buy‑in and prevents premature feature bloat.

Measure and iterate

Finally, once a change ships, measure. Use simple metrics tied to your acceptance criteria: task success rate, time-on-task, conversion, or even qualitative follow‑ups. If the numbers don’t move, iterate with another small experiment rather than reverting to a long wishlist.

Running user interviews with non‑designers is part facilitation, part translation. You’re converting lived experience into observable problems, and then into experiments teams can run. With the right framing, probing, and synthesis, vague feedback becomes a steady source of usable UX improvements—without turning every meeting into a design critique.