Interviewers for client-facing roles, such as agency, consulting, design, IT services and account management, often ask: “How do you handle ambiguous instructions from clients?” or “Tell me about a time a client brief was unclear.” They want to see whether you clarify before you build, and how you do it without making the client feel interrogated.
Below are four answers with notes on what each one does well or badly. First, here is what the interviewer is weighing up.
Why unclear briefs matter so much
Vague requirements are expensive. The Project Management Institute’s Pulse of the Profession research (2013) found that “nearly half (47 percent) of unsuccessful projects fail to meet goals due to inaccurate requirements management.”
A 2014 PMI Global Congress paper by Elizabeth Larson explains why this happens so often. It notes that “Stakeholders rarely provide their requirements in a straightforward manner”, that clients often arrive with their own solution rather than the underlying problem, and that “elicitation requires finding out the real needs behind the stated wants.”
That gives you the standard your answer is judged against. A good answer shows that you:
- noticed the ambiguity early instead of guessing;
- asked about the goal behind the request, not just more detail about the request;
- made something concrete, such as a summary, sketch or sample, so the client could react to it;
- confirmed the agreement in writing;
- handled later changes without conflict.
Example 1: the weak answer
“If a client is vague, I just ask lots of questions until I understand exactly what they want. I’m a good communicator, so I usually get there. Sometimes I’ll just do my best interpretation and then make changes if they don’t like it.”
Notes:
- No example. “I usually get there” can’t be tested.
- “Lots of questions” can tire a busy client. The interviewer wants to know which questions you ask and when.
- “Do my best interpretation and change it later” is exactly the expensive rework the question is trying to uncover.
Example 2: marketing agency, “make it pop”
Illustrative answer: “A retail client asked us to ‘refresh’ their summer campaign and ‘make it pop’ with a week’s notice. Instead of starting designs, I asked for a twenty-minute call and opened with one question: what would make this campaign a success for you? It turned out the real problem was that last year’s campaign got clicks but few in-store visits. So ‘pop’ actually meant a stronger reason to visit the shop. I wrote a half-page summary covering the goal, audience, channels, what was out of scope and the deadline, and asked them to reply ‘agreed’ or correct it. They changed one line about budget. We presented two directions rather than six. They chose one in the first round, and we delivered on time.”
Notes:
- Goal before detail. One good question about success uncovered the real need. This is the “real needs behind the stated wants” in practice.
- Written confirmation with an “out of scope” line protects both sides.
- Result: fewer rounds of revisions is a measurable benefit of clarifying early.
Example 3: software or IT services, a solution instead of a problem
Illustrative answer: “A client’s operations manager asked us to ‘add an export button to every screen’. That’s a solution, not a requirement, so I asked what people would do with the exports. They were copying data into spreadsheets to build one weekly report for the regional director. I mocked up that report as a single screen in about an hour and showed it to them. Their reaction was, ‘That’s what we actually need.’ We built the report instead of exports on thirty screens. It was a much smaller job, and I recorded the change in the scope document so the decision could be traced if anyone asked later.”
Notes:
- Spotting a solution in disguise is a skill interviewers in technical roles listen for specifically.
- A quick prototype turned an abstract conversation into something the client could react to. The Larson paper describes modelling and prototyping as giving a structure for asking the right questions.
- Traceability: recording why the scope changed matters in client work, where people and memories change.
Example 4: events or operations, where clarification has to be quick
Illustrative answer: “I coordinated a corporate dinner where the brief just said ‘around 150 guests, smart, keep it simple’. With three weeks to go, there was no time for long workshops. So I sent the client three short options with prices: a seated set menu, a buffet and canapés only. Each option had one photo and a list of what was included. I also asked the two questions that would change the plan most: are there any guests with accessibility or dietary needs, and is there a fixed end time for the venue? Their answers ruled out one option immediately. We confirmed the choice by email the same day.”
Notes:
- Options instead of open questions. When clients are busy or unsure, it is easier to choose than to describe what they want.
- Prioritised questions. The candidate asked only the questions that would change the plan.
- Speed: it shows that clarifying the brief doesn’t have to slow the project down.
The pattern behind the strong answers
| Step | What you do | Phrase you might use with a client |
|---|---|---|
| 1. Spot it | Notice vague words (“modern”, “simple”, “soon”) or a solution with no stated problem | “Before I start, can I check what this needs to achieve?” |
| 2. Find the goal | Ask about outcome, audience and constraints | “How will you know this has worked?” |
| 3. Make it concrete | Use a summary, sketch, sample or options | “Here are two directions. Which is closer?” |
| 4. Confirm | Agree in writing, including what is out of scope | “Reply to confirm, or correct anything I’ve got wrong.” |
| 5. Manage change | Assess the impact of new requests before agreeing | “Happy to add that. Here’s what it does to the timeline.” |
Showing respect for the client matters at every step. The UK Civil Service behaviour framework, as set out in the Scottish Government’s candidate guide, puts it simply: “Respect the needs, responses and opinions of others.” In practice, that means never suggesting the client is the problem, even when the brief was poor.
Variations of the question
- “What do you do when a client keeps changing their mind?” Focus on step 5. Explain how you show the impact on cost and time, and let the client decide.
- “What if the client can’t explain what they want?” Lead with step 3, since options and samples help.
- “What if you’re given vague requirements by your own manager?” Use the same steps. An internal stakeholder is still a client.
- “Have you ever got it wrong?” Yes is the believable answer. Describe what you would clarify differently now.
If you have no client experience yet
Use a university project with a vague assignment brief, a part-time job where a customer’s request was unclear, or a volunteer role where an organiser gave loose instructions. Use the same five steps and say plainly that it wasn’t a paid client role. Students can build the experience around examples like these with the student resume builder.
If you are applying for analyst or consulting roles, where requirements work is central, the business analyst resume builder shows how to describe requirements gathering as results on your resume, and the cover letter guide helps you mention one short example before the interview.
Frequently asked questions
How many clarifying questions is too many?
Ask the few questions whose answers would change your plan, starting with the goal. If you need more, put them in one written list rather than sending them one at a time.
Should I ever just make an assumption?
Sometimes, if time is very short. State the assumption in writing when you deliver, such as “I’ve assumed X; tell me if that’s wrong”, so the client can correct it quickly.
What is the difference between an unclear client brief and scope creep?
An unclear brief is a problem at the start. Scope creep happens when requests grow during the work. Good answers often cover both: clarify early, then manage changes through impact assessment.
How long should my answer be?
About two minutes. Spend most of it on what you did to clarify the brief and how you confirmed it.
Sources
- Requirements Management: Core Competency for Project and Program Success, Project Management Institute
- I still don’t have time to manage requirements: My project is later than ever, Project Management Institute
- Success profiles: candidate guide (behaviour definitions), Scottish Government