บทความนี้เลยไม่ได้อยากบอกว่า client ที่ยังไม่ทำ user research คือผิด แต่อยากชวนมองว่า ในฐานะคนทำงานออกแบบ เราจะช่วยค่อย ๆ พาโปรเจกต์เข้าใกล้ผู้ใช้จริงมากขึ้นได้ยังไง โดยไม่ลืมความจริงของงาน ความสัมพันธ์กับทีม และบริบทของลูกค้าที่เรากำลังทำงานด้วย
แหล่งอ้างอิง
GOV.UK Service Manual — User research for government services: an introduction
GOV.UK Service Manual — Sharing user research findings
ISO 9241-210 — Human-centred design for interactive systems
Nielsen Norman Group — Usability Testing 101
Nielsen Norman Group — Why You Only Need to Test with 5 Users
Nielsen Norman Group — When to Use Which User-Experience Research Methods
Google Research — Measuring the User Experience on a Large Scale / HEART Framework
McKinsey — The Business Value of Design
In an ideal world, before designing a product, a website, or a new system, we'd always want to sit down with real users first. But in real work, we hear lines like these all the time.
“There's no time for research.” “Our client already knows their users well.” “Let's just build it — feedback can come later.” “The budget won't cover it.” “You won't get a straight answer from users anyway.”
As a UX/UI designer, the important question isn't only “Why won't the client do research?” — it's “If they don't see the value yet, how do we get the project closer to its users, within the limits we have?”
User research shouldn't be sold as an “extra step.” It's better explained as a way to lower the risk of a decision — because understanding users, what they need, and knowing which problem we're actually solving is the foundation of the whole design (GOV.UK Service Manual). If we don't know what real users want, how they use things, where they get stuck, or where they think differently from the team, we may be designing from the assumptions of people in a meeting room rather than the reality of the people who actually use it.
01Don't start with “we have to do research” — start with “what are we risking?”
Often the client doesn't hate user research; they just see it as expensive, slow, or something that makes the project more complicated.
If we open with “this project needs user research first,” some people hear “more time, more budget, and a later deadline.”
A better move is to shift from selling research to talking about risk — the risk of a decision. For example:
“Right now we're not sure users read this flow the same way the team does.”
“This is a key assumption — if it's wrong, we might have to redo the whole flow later.”
“Before we build it fully, could we check just the riskiest flow with 3–5 users, to see if anything slips past what we expect?”
Framed this way, research isn't a separate task that asks for more time — it's a tool for making decisions, and a way to “reduce the chance of building the wrong thing.” That view sits nicely with human-centred design, which says a system becomes usable and useful only when it starts from understanding users, their needs, and the real context of use (ISO 9241-210).
02First, understand why the client doesn't want research
Before you try to convince a client, you need to understand their resistance — because each reason needs a different answer.
Before pitching a method, listen for what the client is really worried about — budget, time, finding users, or a past report they couldn't use.
Some don't want to because the budget is tight.
Some because the timeline is packed.
Some find users hard to reach — they're not sure where to get people to test with.
Some worry about scope creep, because research might open up new problems.
Some believe they already know their customers well.
Some have been burned by a thick research report they couldn't actually act on.
So instead of saying “we can't skip this,” it's better to gently ask what they're worried about.
“Is the hesitation about research right now more about time, budget, or finding users?”
“If we kept it very light — 2–3 days, and summarised it straight into decisions — would that be workable?”
“Is there anything from the sales, admin, or support team we could use as a starting point first?”
Asking this way tells the client we're not forcing a process onto the project — we're helping find an approach that fits their real constraints.
03Turn research from “a big job” into “a small risk check”
One problem is that the moment people hear “research,” they picture something huge — recruiting lots of users, long interviews, a thick report, weeks of work.
But in UX/UI work, before real development, you don't have to start with heavy research. You can start small, fast, and answer one specific question, for example:
Test a prototype with 3–5 users
Interview 3 existing customers
Go through existing support tickets or complaints
Talk to the sales or support team who meet users every day
Run a short 30-minute remote usability test
You don't have to prove everything at once — check the riskiest assumption in the flow first: is the navigation clear, is the form too long, do users know what to do next?
The key is not to try to “prove everything” in one go, but to check the riskiest assumption first. That mindset is the heart of usability testing — we test to find problems in the design, spot chances to improve, and learn how real users actually behave (Nielsen Norman Group).
And the good news is that small research really does help. Usability research suggests that qualitative testing with around 5 users per round tends to surface most usability problems already — but it's important to read that correctly: the number fits qualitative usability testing that's about “finding problems to fix,” not statistical proof or precise measurement (Nielsen Norman Group).
04Offer it as options, not an ultimatum
If the client is still unsure, it helps to present research at several levels, so it feels like a choice rather than just “do it all” versus “do nothing.”
Option 1No ResearchFastestRisk
Design from the brief and the assumptions we have. Fine when the project is very small or the timeline is genuinely tight — but accept that the result may not match real users.
Option 2 · start hereLight ValidationA few daysRisk
Talk to 3–5 users or proxy users, check only the riskiest flow, then turn the insight straight into design decisions.
Option 3Standard ResearchSet directionRisk
Plan the research properly, interview or test several groups, analyse journeys and pain points — suited to work that needs a product direction or roadmap.
Once research becomes a choosable option, the client starts to see the trade-off clearly: skip it and save time but carry more risk; do a light version and spend a little time to avoid a mistake that could cost much more later. Importantly, the research method should follow the question you want to answer, the stage of the project, and the kind of insight you need — not a single recipe for every job (Nielsen Norman Group).
05Let the client “see” users, not just read a report
Sometimes no report — however good — hits as hard as watching a real user get stuck.
If you want more client buy-in, invite them to sit in on a research session. They don't need every round — one or two is enough. Or, if they have no time, cut short highlights — a clip, a quote, an observation tied directly to a decision. For example:
“4 of 5 users didn't understand ‘Submit Request’ — they thought it was filing a complaint.”
“3 users didn't notice the Next button because it sat below where they were looking.”
“Everyone understood this feature differently from what the team intended.”
Then don't hand over just the finding — turn it into a design decision. Research only pays off when the team can take what it learned and improve the work, and sharing findings so everyone sees the same thing helps the team spot gaps and raise questions together (GOV.UK Service Manual).
Finding
Users don't understand the word “Claim”
Decision
Rename the label to “Claim your benefit”
Impact
Less ambiguity at the sign-up step
This way research stops being “a document” and becomes evidence that makes the team's decisions easier.
06Tie research to a business metric the client cares about
If the client is on the business side, they may not buy “user empathy” as much as conversion, cost, adoption, or support workload — because in the end, good design should connect to a business outcome and be measurable, not just a pretty surface (McKinsey).
Translate research into the numbers the client cares about — drop-off before checkout, activation, retention, or lower support cost.
So translate research into the metric they care about, by type of work.
E-commerce: research shows where people don't buy, don't pay, or don't return — reducing drop-off before checkout.
Internal systems: where staff slow down, mis-enter data, or keep asking support the same thing.
SaaS: onboarding, activation, retention and feature adoption.
Corporate website: whether people understand the value proposition, find information, and can get in touch easily.
Put simply, don't just say “we should understand users” — say “if we understand users, here's how we lower the risk on conversion, adoption, or rework.” This connects directly to the HEART framework, since UX can be tied to goals, signals, and metrics like task success, adoption and retention (Google Research, HEART Framework).
07If the client still won't — do transparent assumption-based design
Sometimes, no matter how hard you try, the client still won't do research.
In that case, the right move isn't to quietly go along and design as if you're 100% sure — it's to make the assumptions explicit. Separate what you know from the brief, what you don't know yet, what you're assuming, the risk if an assumption is wrong, and where it should be validated later.
Assumption
Users understand the term “Campaign Wallet”
Risk
If they don't, they may not dare to use it
Decision
Add a short description under the heading
Validate
Test comprehension with 3–5 users before launch
This protects both the design team and the client, because everyone agrees on what level of data this design rests on and where it still needs checking — which is really an effort to keep human-centred design alive as far as the conditions allow: still trying to understand users, requirements, and context of use, even when full research isn't possible yet (ISO 9241-210).
08Lines to use with a client, without the pressure
Instead of saying “the work won't be good if we skip user research,” try lines that open options and lower the pressure. Tap the copy button in the corner of each card to reuse them.
We can keep designing — but I'd like to clearly separate what comes from real users and what's an assumption, so the team can decide more safely.
If the timeline won't fit full research, could we do a short light validation with 3–5 users on just the riskiest flow first?
This is a key decision. If users read it differently from the team, it could affect dev and post-launch use — so I'd like a quick check first.
If now isn't the right time, I'll note the risks and assumptions in the design handoff so the team can come back and validate in the next round.
These lines don't make the client feel guilty — they help them see research as a tool for deciding, not a step the designer is tacking on.
In short: bring the project closer to its users, bit by bit
When a client won't do user research, we don't have to win an argument about how important research is. What we can do is:
Turn research into the language of risk — start from the smallest but most important question in the flow.
Offer research in tiers — let the client choose their level of confidence and risk, by time and budget.
Let the client see real users — turn findings into decisions, not insights left floating.
Tie findings to a business metric — conversion, adoption, retention or support cost the client cares about.
If it still can't happen — record assumptions and risks transparently, and mark where to come back and validate.
Because in the end, UX isn't about completing research as a ritual — it's about helping the team decide on the reality of its users a little more, bit by bit.
Some projects may not start from perfect research, but they should end with a team that understands more clearly who they're designing for, and what they still don't know about them.
The goal isn't to win the argument — it's a team that gradually understands its users a little better, together.
A note from Tarn
The way I see it, doing UX in real work doesn't always mean we get to use the “most complete” toolkit. Many times we have to choose the approach that fits what's in front of us — the time, the budget, the team, the client, and the project's constraints.
Some projects have room for full research; some can only manage a short light validation; sometimes we start by talking to the team closest to the users first. But wherever we start, the thing I don't want us to forget is to ask ourselves: “Do we know enough about the user for this particular decision yet?”
And I want to thank the many clients who've kept an open mind toward the UX process — who gave space for asking questions, testing, and talking to real users, even when everyone had their own constraints.
So this article isn't trying to say that a client who hasn't done user research is wrong. It's an invitation to look at it differently: as designers, how can we gradually bring a project closer to its real users — without losing sight of the realities of the work, the relationship with the team, and the context of the client we're working with.
References
GOV.UK Service Manual — User research for government services: an introduction
GOV.UK Service Manual — Sharing user research findings
ISO 9241-210 — Human-centred design for interactive systems
Nielsen Norman Group — Usability Testing 101
Nielsen Norman Group — Why You Only Need to Test with 5 Users
Nielsen Norman Group — When to Use Which User-Experience Research Methods
Google Research — Measuring the User Experience on a Large Scale / HEART Framework
