What UX Research Actually Produces
UX research has a reputation for producing decks nobody opens. Here is what it should actually produce, and how to tell if you are getting it.

UX research has a reputation problem, and it is partly earned. Too many engagements end with a long deck, a set of personas nobody refers to again, and a design that would have looked the same without any of it. That is a failure of scope, not of the discipline.
Research Answers a Question. Start With the Question.
The most useful thing you can do before commissioning research is write down the decision it should inform. "Should onboarding be one screen or three?" is a research question. "Understand our users" is not — it has no wrong answer, so it cannot produce a finding.
A good UX research engagement starts by narrowing that down, and will push back if the question is too broad to answer.
Testing and Reviewing Are Not the Same Thing
This distinction matters more than any portfolio. "We validated it with stakeholders" means the design was reviewed by people who already know how it works. Usability testing means watching people who match your actual users try to complete a task, and counting how many cannot.
The second one is a different activity with a different cost, and it is the one that finds the problems. Five sessions with the right people reliably surfaces the biggest issues in a flow.
Your Support Tickets Are Free Research
Before paying for anything, read the last few hundred support conversations. The questions people ask are a map of where the interface is unclear, and they are already written down. The same is true of your search logs and your analytics drop-off points.
Any agency proposing a redesign without asking for these is designing on taste. That is a reasonable thing to ask them about early.
What the Output Should Look Like
Findings, not observations. "Seven of eight participants could not find the pricing page from the product tour" is a finding — it names a problem, its size and where it happens. "Users want clarity" is an observation, and nobody can act on it.
Each finding should carry a recommended change and a rough sense of how much it matters. That is what turns research into design work rather than into a document.
Flows Before Screens
Once the findings exist, the path through the product gets designed before individual screens do. A screen that looks right inside a broken flow still fails, and no amount of UI design polish rescues a sequence that asks for the wrong thing at the wrong moment.
A System, So It Holds
The last output is a component system with rules, not a set of flat mockups. Without it, feature twelve looks nothing like feature one and you are commissioning another redesign in two years to bring them back together.
If you want to know which of these your product actually needs, send us your analytics and support tickets — we would rather read those first than quote from a brief. Our UI/UX design services page covers how the disciplines split.



