UX Questions to Ask Clients
UX questions to ask clients and stakeholders at the start of a project, for designers and researchers running a kickoff meeting or a discovery session. They follow the order the conversation tends to take: the problem and why it matters now, the users, the evidence that exists and whether you can reach real users, the constraints, who decides and how you will work together, and how success will be measured.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The problem
What problem is this project meant to solve, and who has that problem?
Why ask it
A strong answer names a person and a moment: a new customer who gives up halfway through setting up an account. If you hear a feature instead, such as 'we need a dashboard', ask what people would do with it that they cannot do today.
Why is this work a priority now, and what set it off?
Why ask it
A lost deal, a jump in support requests, a rival's release or a new executive each bring a different yardstick with them. Whatever the trigger was, the first design review will be held up against it, so put it at the top of your notes in the client's own words.
What does the business need from this: more signups, fewer support calls, better renewals, something else?
Why ask it
You are asking for the number somebody will have to explain in a meeting. One clear goal lets you settle later design arguments by asking which option serves it. Three goals with no order means the ranking will happen during your reviews, so ask for it now.
What is not working in the product today, and how do you know?
Why ask it
The second half separates evidence from opinion. 'Half the people who start checkout leave at the shipping step' is a place to begin, and 'it feels clunky' is a hunch to test. Mark in your notes which complaints have something behind them.
What are the three to five things people most need to be able to do with the product?
Why ask it
Push for tasks phrased as verbs: pay an invoice, book a slot, compare two plans. That short list becomes the backbone of your research plan and your usability tests. When it runs to twenty items, ask which ones a person does in their first week.
Has anyone tried to fix this before, with a redesign, a new feature or a workaround?
Why ask it
Earlier attempts leave behind opinions, half-built screens and sometimes a person who is tired of the subject. Ask to see what was made and why it stopped, because whatever stopped it may still be in the building.
Do you already have a solution in mind?
Why ask it
Many clients do, and it is better said out loud than discovered in the first review. Treat it as a hypothesis: ask what makes them confident and what they would need to see to choose differently. If the reply is 'nothing', the job is execution, and you can scope and price it that way.
What is out of scope, and which parts of the product should I not touch?
Why ask it
Limits drawn at kickoff are cheap. The same limits found during a design review cost a round of work. If the excluded part is where the problem lives, for instance the login when the complaint is about getting started, say so before you agree to work around it.
What do your users compare this product with, including doing the job by hand?
Why ask it
Whatever people relied on before sets their idea of how things ought to work, and the rival is often a spreadsheet, a paper form or a phone call. Find out which of those habits the client wants to match and which it wants to break, then try the top two alternatives yourself.
Users
Who uses the product today, and who do you want to be using it?
Why ask it
These can be two different groups, and a design that courts the second can drive off the first. Ask roughly how large each is and which one pays the bills this year. If the reply is 'everyone', ask about the last five accounts that signed up.
Is the person who chooses or pays for the product the same person who uses it every day?
Why ask it
Where they differ, the buyer tends to ask for reports and controls while the daily user wants to finish the task and move on. You will need to hear from both, so ask whose unhappiness is more likely to end the contract.
What do you already know about your users, and how did you learn it?
Why ask it
Sort the answer into three piles as you listen: things someone watched happen, things users said, and things the team believes. Beliefs are a fine starting list. Trouble starts when a persona written in a workshop gets quoted as a finding.
How often does anyone on the team watch a customer use the product?
Why ask it
'Last Tuesday, on a support call' and 'at the launch event two years ago' describe very different clients. A team that rarely sees its users should be brought into your sessions as observers, or the findings will sound like your opinion.
Where are people when they use it, and what else is competing for their attention?
Why ask it
A phone held in one hand on a train, a shared terminal on a shop floor and a second monitor during a sales call each call for a different design. If the setting is unusual, ask to visit or to see photos, since a description given from a conference room leaves things out.
What are users doing just before they open the product, and where do they go straight after?
Why ask it
The product is one step in a longer job, and the joins are where needs hide. Listen for copying and retyping: numbers moved into a spreadsheet, a screenshot pasted into an email. Each of those is a handoff the design could take over.
What workarounds have users come up with?
Why ask it
Sticky notes on the monitor, a private spreadsheet, a colleague who 'knows how to make it work': every workaround is a requirement the user wrote for you. The people in support and training usually know them better than the product team does.
Are your users experts in this field or new to it, and how comfortable are they with software?
Why ask it
Experts tend to want speed, shortcuts and a lot on one screen. Newcomers want explanation and a clear next step. One layout seldom pleases both, so if the client says the audience is mixed, ask which group it would choose to disappoint.
How often does a typical user open the product: several times a day, once a month, once a year?
Why ask it
Daily users learn an interface by repetition and will trade some hand-holding for speed. Someone who files one claim a year arrives as a beginner each time and needs the screen to explain itself. Check the gap between visits in the analytics, since a team that lives in the product all day tends to guess high.
How does a new user learn the product: training, a help center, a colleague, or trial and error?
Why ask it
Whatever props the product up tells you where it fails to explain itself. A two-day training course is a list of things the interface does not make clear. Get the training material and the most-read help articles, and read them as a map of the hard parts.
Evidence
What research already exists, and can I read it before we plan any more?
Why ask it
That means all of it: old surveys, interview notes, the agency deck from three years ago. Reading it first keeps the client from paying to learn something twice. Check the date and the method on each piece before deciding how far to lean on it.
What analytics does the product collect, and can I have my own login?
Why ask it
Your own access beats screenshots sent on request, because each answer in the data raises the next question. If tracking is thin, or nobody trusts the numbers, raise it now: setting up measurement may have to be part of the project, or there will be no before to compare the after with.
Can I talk to users directly, and who would introduce me?
Why ask it
A good answer is a name and a route: the customer success lead will make introductions, or there is a panel of people who have agreed to be contacted. Reluctance, such as 'we would prefer not to bother customers', has to be talked through at kickoff. Sessions held only with stand-ins from inside the company tell you what staff think users do.
Is there a budget and a process for recruiting participants and thanking them for their time?
Why ask it
Recruiting often takes longer than the sessions themselves, so it belongs in the schedule from day one. Ask how incentives are handled here, since companies and industries differ on whether customers or employees can be paid, and someone in finance or legal may need to approve it.
What comes up most in support tickets, app reviews and sales calls?
Why ask it
This is research the client already owns and has seldom read in one sitting. Request the raw export, not a summary, and count the themes yourself. Keep in mind who is missing: people who gave up quietly never wrote in.
Who inside the company speaks with customers every day, and can I have an hour with each of them?
Why ask it
Support agents, trainers, account managers and salespeople can tell you where people get stuck before you have recruited a single participant. They are also the staff who will explain the new design to customers, so meeting them early earns you allies for launch.
What has to happen before I can record a session or look at customer data?
Why ask it
Do not assume. Find out who approves it at this company, which forms or agreements are needed, and how long that usually takes. With health, money or children involved the steps can be many, so get the answer from the client's own legal or privacy contact and build the wait into the plan.
Can I use the product the way a customer does, with a real account and realistic data?
Why ask it
An empty demo account hides most of what goes wrong: long names, hundreds of records, permissions that block a step. If a real account is not possible, ask for a copy of the environment the sales team demos from, plus a recording of a customer doing the main task.
Which of your beliefs about users would you most like to see tested?
Why ask it
It invites doubt without accusing anyone of guessing, and the answer hands you a research question the client already wants settled. A stakeholder who says none should be invited to watch a session in person, where a surprise is easier to accept than it is in a report.
Constraints
Which devices, browsers and screen sizes does this have to work on, and which do most people use?
Why ask it
Get the split from analytics, since guesses run toward whatever the team itself uses. A product opened mostly on phones but reviewed on large office monitors gets approved in a form its users never see, so agree at kickoff which screen the reviews happen on.
What is the product built with, and what does that make easy or hard to change?
Why ask it
You do not need the full architecture, only the fences: an old framework that makes some interactions expensive, a vendor platform with fixed templates, a release cycle of once a quarter. Have an engineer in the room for this one, and note anything described as 'impossible' to check again later.
Is there a design system or component library, and how closely am I expected to follow it?
Why ask it
Three answers are common: follow it strictly, extend it where needed, or it exists but nobody opens it. Each changes your estimate. Look at a recent screen in the live product next to the same screen in the library, because the gap between them is work somebody will have to do.
What brand guidelines apply inside the product, and who rules on exceptions?
Why ask it
Guidelines written for brochures and ads often break down on a dense screen: a brand color that fails contrast on a button, a typeface that is hard to read at small sizes. Find out who can approve an exception before you need one.
Which accessibility standard does the product have to meet, and who checks that it does?
Why ask it
What applies depends on where the client operates, who its customers are and what it has promised in contracts, so put the question to the client's own legal or compliance contact and do not guess. If no one owns it, say that you will design to a named standard and ask who will test the build.
Are there legal, regulatory or security rules about what a screen must say, ask or hide?
Why ask it
Required disclosures, consent wording, mandatory fields and session timeouts can each undo a clean flow late in the project. Ask who reviews screens for this and at what stage, and offer to show that person rough wireframes so the rules arrive before the polish does.
Which parts of the experience belong to someone else: a payment page, a sign-in provider, an embedded tool?
Why ask it
Users do not see the boundary, so a clumsy third-party step counts against the client's product all the same. List every one and find out what can be configured. Where nothing can change, plan the screens on either side to prepare people for the jump.
How much engineering time is set aside to build what comes out of this work?
Why ask it
A worrying answer is 'we will see what you come up with'. Designs with no build time behind them tend to end up as a slide deck, so ask which team, which quarter and how many people. If the capacity is small, design for it and say plainly what is being left for later.
What real content and data will fill these screens, and who is responsible for it?
Why ask it
Layouts built on tidy placeholder text fall apart when a product name runs to sixty characters or an account has no history yet. Ask for an export of real records, including the messy ones, and for the name of whoever writes interface text, error messages and emails.
How did customers react the last time the product changed, and how much change can they take at once?
Why ask it
Long-time users have habits built on the current screens, and some have training notes, scripts or integrations that depend on them. A story about angry calls after a button moved points toward a staged rollout, a preview period or a way back to the old view. If nobody remembers a change, ask support how releases are announced.
Working together
Who approves the design, and is there anyone who can overrule that person?
Why ask it
The named approver is seldom the whole story. A founder, a head of sales or a compliance officer who appears at the last review can send you back to the start, so ask who has done that on past projects and invite them to an early session.
Which stakeholders should I interview, and who will feel left out if I do not?
Why ask it
The second group matters as much as the first, because people who were not asked tend to find fault at the review. A half-hour conversation each with sales, support, engineering and marketing is cheap, and it shows you where their goals pull in different directions.
Where do people inside the company disagree about this project?
Why ask it
Most projects have one, and a client who can name it is easier to work with than one who says everyone is aligned. Once you know the two camps, you can frame research to answer their argument instead of having it replayed over your wireframes.
Who will I work with day to day in product and engineering, and when do the engineers first see the designs?
Why ask it
'At handoff' is the answer to worry about, because that is when you learn what cannot be built. Ask for one engineer to join sketch reviews from the first week. Fifteen minutes of their time early can spare you a redesign later.
How rough can the work be when I first show it to you?
Why ask it
Some clients are happy to react to sketches on paper. Others read anything unfinished as a lack of effort. If yours wants polish early, explain that it slows the cheap stage when ideas can still be thrown away, and agree on one rough check-in at least.
What do you expect to have in hand at the end: research findings, user flows, wireframes, a prototype, build-ready specs?
Why ask it
Go through the list item by item and write down yes or no. A client may picture finished screens while the designer has scoped a research report, or the reverse. Ask who will pick up each deliverable and what they will do with it, which tends to remove one or two nobody needs.
Which dates is this tied to: a release, a sales event, a contract renewal?
Why ask it
A date fixed from outside tells you how much discovery there is room for, and it is better to shrink the research honestly than to pretend it will fit. Pin down what would be shown on that day. A working prototype and a shipped product are very different promises.
What is the budget for this project, and how was the figure reached?
Why ask it
The second half shows whether the amount was sized to the problem or carried over from an earlier project. Go through what it was meant to cover: research, design, testing with users and a round of fixes. If one of those was never counted, say what the work will and will not include before anyone signs.
If what we learn from users points away from the current plan, how much of the plan can change?
Why ask it
Raise it before there are findings, while the question is still hypothetical and nobody is defensive. 'The roadmap is committed' is a fair answer and tells you to aim research at how to build the thing well. An open answer lets you question whether to build it.
Success
How will we know the design worked: which number should move, and by roughly how much?
Why ask it
You want one primary measure tied to a task, such as the share of people who finish setup or the time it takes to send a first invoice. 'Users will love it' cannot be checked, so follow up by asking what those happy users would do more or less of.
Where does the number we want to move stand today, and who can pull it?
Why ask it
With no starting figure there is nothing to compare the launch against, and the project gets judged on taste. If nobody can produce it, make measuring the current state the first task, even if it is only timing five people through the main flow.
Which other measure must not get worse while we improve the main one?
Why ask it
A shorter signup form can raise signups and also raise the number of confused new accounts calling support. Naming that second measure now, whether it is refunds, support contacts or error rates, protects you from a win that is reversed a month after launch.
Is there time and money to test designs with users before launch, and to fix what the tests find?
Why ask it
The second half is where plans fall short: testing is scheduled for the last week, with nothing left to act on it. Ask for at least one round early enough to change the design, and get it written into the timeline with the days for fixes shown.
After launch, who watches how the design performs, and is a second round planned?
Why ask it
First releases are rarely right in every detail. A client with an owner and a follow-up budget will learn from launch. Where there is neither, write your handover notes for whoever inherits the product: what was tested, what was assumed and what to watch.
What would make this project a failure in your eyes, even if it shipped on time?
Why ask it
Clients are often more exact about what they fear than about what they hope for. You may hear that long-time customers revolt, that sales cannot demo it, or that it looks like every other app. Whatever is named becomes a check to run on each concept before you present it.
How to run a UX kickoff with a client
Practical guidance for the conversation itself
Before the kickoff
Read what exists first
Ask for the brief, any past research, an analytics login and a product account a few days ahead. Go through the product yourself and write down where you got stuck. Then cross off every question on this page the material already answers, and turn the rest into follow-ups: 'The brief says cancellations are the problem. Where in the first month do people leave?'
Put each group of questions to the right people
One meeting with ten people gets you the official version. The problem, Working together and Success belong with the sponsor and the product lead. Users and Evidence get fuller answers from support, sales and anyone who has run research. Constraints need an engineer and, where rules apply, someone from legal or compliance. Plan a kickoff for the whole group and short one-to-one interviews after it.
Choose about ten for the meeting itself
An hour holds roughly ten questions once follow-ups are counted. Take one or two from each group, starting with those whose answer would change your plan: whether you can reach users, who approves, how much build time exists. The rest can go into stakeholder interviews or a written questionnaire.
Send the lookups in writing
Device splits, links to old research, the names of approvers, the accessibility standard and the fixed dates are things somebody has to go and find. Asked in the room they produce 'I will get back to you'. Sent a few days ahead they arrive answered, and the meeting can go to the questions that need a discussion.
In the meeting
Start with the problem, not the screens
Clients often open by pulling up the product and pointing at what they dislike. Let that run for five minutes, since it shows what they notice, then go back to the questions under The problem. Screen-by-screen complaints with no goal behind them become a list of fixes nobody can rank.
Trade each verdict for one case
Clients describe their users in verdicts: onboarding is confusing, the reports are too slow. Pick one and ask which customer it happened to most recently, which step they were on and what they did next. A named account and a single screen give you something to go and look at, and they show whether the verdict rests on many cases or on one loud one.
Mark what is known and what is assumed
Keep two columns in your notes, one for things someone has seen or measured and one for things the room believes. At the end, read the second column back: 'These are the things we think are true and have not checked.' That list is the first draft of a research plan, and hearing it aloud helps a client see why research is in the proposal.
Let disagreement show
When two stakeholders answer the same question differently, do not smooth it over. Write both answers where everyone can see them and ask what would settle it. Often it is something you can find out from users or from the data.
Close with owners and dates
Before anyone leaves, name who is sending the research, who is arranging analytics access, who will introduce you to users, and by when. Access that was promised loosely at kickoff has a way of arriving in week three.
After the kickoff
Write it up on one page
Within a day or two, send a summary: the problem in the client's words, the main users, the top tasks, the measure of success and where it stands today, the constraints, the approver, and the open assumptions. Ask for corrections. A stakeholder who corrects the summary now is less likely to be surprised by the direction later.
Turn the assumptions into a research plan
Rank the assumptions by how costly each would be if it were wrong and how little stands behind it. The top few become research questions. Match each to the lightest method that could answer it: five interviews, a look at where people drop out of a flow, an afternoon reading support tickets.
Size the work to the answers
The answers about budget, engineering time, dates and access to users tell you how much discovery the project can hold. A fixed date six weeks away with no way to reach users calls for a different plan than an open quarter with a research panel. Say which plan you are proposing and what it leaves out.
Bring the page to every review
When feedback drifts toward personal taste, the one-page summary lets you ask which option better serves the user and the measure everyone agreed on. It also shows when the goal itself has changed, which is a conversation about scope and not about the design.
Mistakes to avoid
Asking the client what users want
Stakeholders can tell you about the business, the constraints and what they believe. What users need has to come from users. Treat every 'our users want' as a belief to check, however confident it sounds.
Speaking in UX terms
'What are the jobs to be done?' gets a blank look in many rooms. 'What are people trying to get done when they open it?' gets an answer. The questions on this page are worded for a client who has never hired a designer or a researcher, so keep them plain when you adapt them.
Accepting 'everyone' and 'easy to use'
Both are placeholders. Follow each with a request for something specific: which customers signed up last month, easy for whom, doing what.
Leaving the access questions for later
Whether you can reach users, see the data and count on engineering time decides what kind of project this is. Put off, those questions tend to get answered by events, partway through the work, when the plan is hardest to change.
Running the same list on every project
A redesign of a mature product leans on Evidence and Constraints, because there is a lot of both. A new product has little of either and needs more time on The problem and Users. Choose for the project in front of you.