UX research is the work of finding out how people actually behave with a product or interface, and turning that into a decision a product team can build against. It is not a report, and it is not a satisfaction score. Vivaldi has run research of this kind since 1999, as the evidence layer under the products and services we help companies design.
- Since 1999research behind product and service design
- 200+published case studies
- 10 officeson four continents
- 5xWirtschaftsWoche Best of Consulting, Strategy and Innovation
When companies bring us in
The trigger is rarely “we need more user research.” It is usually one of these.
- A product decision is stuck between two internal opinions and there is no evidence that settles it.
- The analytics show where users drop out and nobody can say why, because the data records behavior without motive.
- Research has already been commissioned, the deck was well received, and the roadmap did not change.
- A proposition is about to be built and the only validation so far is that the people who proposed it still like it.
- Different teams hold different pictures of the same user, and each has evidence for theirs.
Why most UX research does not change the product
The standard engagement starts with a method. Someone decides on interviews, or a survey, or a round of tests, the fieldwork runs, and a findings deck arrives. The findings are usually true. The product ships largely as it was going to.
The reason is that the research was never attached to a decision. A study commissioned as “we should understand our users better” produces understanding, which no one can act on, because acting requires choosing between options and understanding does not name any. By the time the deck lands, the team has already committed, and the research becomes something to cite rather than something to decide with.
We work the other way round. The first output of an engagement is not a method, it is a written statement of the decision the research has to settle and what each possible answer would mean for the roadmap. Fieldwork is designed backward from that. If the decision cannot be stated, that is worth knowing before anyone is recruited, and we will say so.
It is worth being straight about what this is not. Vivaldi is a strategy firm. We do not operate a usability lab, we do not maintain standing participant panels, and we do not sell research by the sprint. Where a study needs lab facilities or high-volume recruitment, we scope it with a specialist partner and stay responsible for the question and the conclusion. If what you need is continuous testing throughput, a dedicated research agency is the better buy and we will tell you that in the first conversation.
What our UX research services include
1. Framing the decision the research has to settle
Before any fieldwork, we write down the choice in front of the product team, the options on the table, and what evidence would move each one. This is a short piece of work and it is the part that determines whether anything else is useful. The output is a research question a stakeholder can disagree with, which is the test of whether it is a real question.
2. Qualitative fieldwork with the people who actually use the thing
In-depth interviews, in-market ethnographic work, and observation in the setting where the product is really used rather than in a room arranged for the purpose. This is where our practice is strongest: we have run ethnographic studies for consumer, healthcare and retail clients for two decades, and the method travels well into digital products because it records context, not just task completion.
3. Behavioral framing of what users do rather than what they say
Stated preference and actual behavior diverge, reliably and in predictable directions. We read interview and observational material through a behavioral lens, separating what people report wanting from what their behavior shows they will accept, and we flag where the gap is large enough to put a roadmap assumption at risk.
4. Concept and proposition validation before build
Concepts put in front of real users in their own language, early enough that the answer can still change the specification. The point is to disprove things cheaply. The output records what was ruled out and on what evidence, which is the part teams later need and rarely have.
5. Handover into product and design decisions
Findings written as decisions and their consequences, not as themes. Each one names the choice it settles, the confidence behind it, and what would have to be true for it to be wrong. This is what gets handed to the teams doing UX design, interaction design and interface design.
Not sure your research question is a real one?
Start with a scoping session. We will write down the decision your team is actually stuck on, work out whether research can settle it, and tell you plainly if the honest answer is that it cannot.
How a UX research engagement works
- Frame. Sessions with the product, design and commercial owners to establish the decision in play, the options, and the evidence that would move each. The output is a written research question with the roadmap consequences of each possible answer attached.
- Field. Qualitative work with real users in a real setting, sampled for the decision rather than for demographic tidiness. The output is primary material, with the sampling logic and its limits recorded so later readers can judge it.
- Read. Analysis that separates reported preference from observed behavior and identifies where the two part company. The output is a small set of findings, each one stated as something that is true about users and consequential for the product.
- Decide. A working session with the team that owns the roadmap, where each finding is resolved into a decision, a deferral with a trigger, or an open question that needs different evidence. The output is a record your teams can act on without us in the room.
Our view on how this is changing as products become model driven is set out in how AI changes UX and CX design in 2026.
Why companies choose Vivaldi for UX research
Three reasons come up, and they are related.
The first is that we are accountable for the conclusion, not the fieldwork. A research supplier is paid to run a study well. We are paid to leave the team able to decide, which means we will tell you when the study you asked for will not do that and propose a different one.
The second is that the research sits next to the strategy work rather than upstream of it. The same people who read the user material are in the room when the proposition, the portfolio or the service model is argued, so findings do not have to survive a handover to be used. The trade is that we are not the cheapest way to run a round of interviews, and we are not pretending to be.
The third is range. Two decades of ethnographic and qualitative work across consumer goods, healthcare, financial services and retail means we have usually seen the category before, which shortens the framing stage and makes the sampling argument easier to defend internally.
How to evaluate a UX research partner
Five questions worth asking anyone, including us.
- What decision will this research settle, and what will you do if the evidence points the uncomfortable way?
- Who reads the raw material, and are they the same people who write the conclusions?
- How will you sample, and what will that sample not be able to tell us?
- What is the deliverable, and does it name choices or themes?
- Would you turn down this project, and under what circumstances?
Strategy firm, specialist research agency or in-house research team?
| Criterion | Strategy firm running the research | Specialist UX research agency | In-house product research team |
|---|---|---|---|
| What it is best at | Settling a contested product or proposition decision with primary evidence | Volume and cadence: continuous testing, panels, lab facilities, fast turnaround | Continuity, context and institutional memory of the product |
| Typical deliverable | Decisions with the evidence and the confidence behind each one | Findings reports, test results, usability scores, tracked benchmarks | Tickets, specification changes, an internal insight repository |
| Main limitation | Not built for throughput, and priced for decisions rather than for study volume | Accountable for the study, rarely for what the roadmap does next | Hard to disagree with the team that commissioned it |
| Who it reports to | Product and commercial leadership together | The research or design function | The product owner |
Related work
This service sits inside Vivaldi’s service and product design practice. Research for product and interface decisions is what this page covers. For brand, category and market research that informs strategy rather than a product build, see research and insights.
The adjacent services are prototyping and testing, where a built thing is put under test, customer experience design, where the experience itself is designed, and digital product creation, where the product gets built.
UX research in the US and worldwide
We run UX research from ten offices on four continents, which matters more than it sounds for this service: the gap between what users say and what they do is shaped by local context, and a study designed in one market and translated into another usually measures the translation. Our teams in the US, Europe, Latin America and Asia run fieldwork in market, with researchers who can read the setting. Engagements are typically led from the office closest to the users, with the product team joined wherever it sits.
Have a product decision that evidence should settle
Tell us the decision and we will tell you whether research can settle it, what it would take, and whether we are the right people to do it.