How to extract a brief from a client who doesn't know what they want?

Stop offering solutions, ask questions. 'What's the biggest problem your customers have today?' 'If you could change one thing, what would it be?' 'How many contacts do you receive per month?' These 4-5 questions extract 80% of the real brief.

Do visual references help with briefing?

A lot. 'Clean' for the client is different from 'clean' for the dev. Send 5-10 similar sites and ask which one they like. Reduces 3 rounds of revision. Keep an organized folder by niche (Are.na or Notion) for quick pulls.

Is it worth making a prototype before signing the contract?

Worth making a quick prototype after the brief. 2-3 hours, home with 5 sections, client palette. Clients react to concrete much better than abstract. 'Liked it but section X needs more images' is real briefing, not vague opinion.

How to handle clients who change their mind weekly?

Signed scope document and iterative prototype. Each change is registered. After 3 iterations, changes are charged (R$ 150/h or extra package). 80% of clients stop changing when they see the 'approved vs pending changes' spreadsheet.

Client doesn't know what they want (and that's okay)

Client shows up saying: “I want a better website. Like, more modern”. And you’re standing there thinking… okay, but what’s modern? What’s the actual problem?

I spent years thinking it was the client’s job to show up with finished specs. Then I realized: it’s not. It’s my job to pull it out of them.

Most clients have never built a website before. They don’t know what’s possible. They can’t visualize it. They just feel a vague discomfort like “it feels off somehow, you know?”.

Your job is turning that vague discomfort into concrete requirements.

Start with questions, not solutions

First thing I do now is stop offering solutions. I ask questions.

“What’s the biggest complaint your customers make about your current website?” Real information comes out. Not “I want better design”. It’s “people can’t find the appointment form” or “they search here then have to call anyway”.

“If you could change one thing, what would it be?” Gold. Shows real priority. What actually hurts.

“How do customers find you today?” You discover the actual funnel. Maybe 80% from Google, 15% from referral, 5% from the website. Your site might be terrible but if it’s not the bottleneck, it’s not priority.

“How many contacts does your clinic get monthly?” Gives you scale context. 3 contacts a month versus 50 changes urgency completely.

You ask those 4 questions and you already have 80% of what you need.

Visual references speak louder than words

Client says “I want it clean”. Clean means Bauhaus to them. Minimalism to you. Pointless discussion.

I send links to 5-10 similar sites. “Which of these do you like?”. Suddenly they find one and say “this! Like this but with our clinic colors”.

Now you have direction. It’s not opinion, it’s reference.

I collect nice websites in a folder. When briefing a client, I bring references from sites like theirs. Clinic? I show 5 clinic websites I liked. E-commerce? Other e-commerce sites.

Time savings are insane. You avoid 3 rounds of revision just in that conversation.

Quick prototype beats 10 specification meetings

Once I understand the main problems and have visual references, I make a quick prototype. Doesn’t need to be pixel perfect.

Homepage with 5 sections, the style they chose, clinic colors. Generic clinic copy, placeholder images. Takes 2-3 hours.

Send it to client to look at. Now they can visualize it. “Oh I like it! But this services section could have more images”. Now you have concrete feedback.

Quick prototyping is the cheat code for avoiding abstract discussion.

I use Astro because I can clone a nice template and customize it in an afternoon. Use whatever you prefer.

The briefing is your responsibility

Here’s the important part: the briefing is not the client’s responsibility. It’s yours.

You need to show up with the right questions. You need to bring references. You need to make a quick prototype.

Clients are terrible at explaining what they want. But they’re great at reacting when they see something built.

Shift your mindset. It’s not “the client didn’t brief me well”. It’s “I didn’t extract the brief from them well enough”.

In practice

Here’s how my typical conversation goes now:

Start: “I’m going to ask some questions to understand better. Don’t worry if you don’t know technical details”. (Preemptive apology for the gaps).

Questions: mostly the ones I mentioned above.

Proposal: “Let me build a quick visual prototype. Next week you see it and tell me if we’re on the right track”.

Prototype: basic homepage, nice visual, brand colors, main sections.

Review: client sees it, gives concrete feedback, you already have direction for real development.

Result: projects with way less revision, happier client, you spend less time in ping-pong.

The actually hard part

The really hard part is when the client has tons of ideas. They want everything. Then you need prioritization.

Here I use the impact/effort matrix. “This is easy to do and changes conversion significantly. Week one. That thing is hard and changes little. Later”.

You become the expert. Client comes to you with questions.

Advanced briefing techniques

After doing this hundreds of times, I discovered techniques that work better:

Invert questions: instead of “what do you want?”, ask “what do you NOT want?”. Rejection lists are easier than wish lists.

Client: “I don’t want loud colors. Don’t want tons of text on the home page. Don’t want it to look like a loud startup”. Suddenly you have clear direction.

Compare competitors: “Your competitor made a design choice. Good or bad?”. Clients critique way easier than they request.

Use real benchmarks: instead of suggesting, bring 10 nice sites. Client picks 3. You clone the style. Done, clear spec without you suggesting anything.

Prototype cascade: don’t make one final prototype. Make 3 very different ones. Minimal/white, colorful/modern, traditional/conservative. Client sees, rejects 2, refines 1. Much more efficient.

Structured vs chaotic feedback

When client sees prototype, feedback matters. But some feedback helps and some hurts.

Chaotic feedback: “I don’t like this. It feels… I don’t know, different?”

Structured feedback: “I like the services section, but the booking page confuses me. And this blue nav color doesn’t match the purple logo.”

You can transform one into the other by asking:

“What do you like about this page?” “What don’t you like?” “If you could change one thing, what would it be?” “Does this color match your logo?”

Suddenly the client is giving feedback you can actually use.

Document everything

This is critical: document every briefing decision.

“Client wants minimalist home” → document it. “Appointment service is priority one” → document. “Doesn’t want mobile app, just web” → document.

Later when you’re developing and hit a question, pull the document. “Oh, we decided that was priority one. I’ll focus there”.

Six months later, client forgot they said it. Document exists. Call recording (if you recorded). You’re protected.

The client who changes mind every week

Some clients change their mind constantly. Every week it’s “actually I thought I wanted this but really…”

In those cases, prototyping is your savior.

You put the current idea in prototype. Client sees, changes mind. You reshape it. Client sees again. Repeat 5 times.

After that, client went from “I think” to “I’m sure because I saw it”.

Iterative prototyping is expensive in time but saves in rework later.

Prepare list of briefing questions
Build folder of site references by niche
Create quick prototype template
Test briefing process on next client
Document how to gather structured feedback
Create template for decision logs

A client who doesn’t know what they want is just one you haven’t explored well enough yet.