Asking the Right Questions: How Should a Web Project Brief Be Taken?

"Build me a nice website."

This sentence is the most dangerous brief you can hear at the start of a web project. Nice according to whom? Serving what purpose? For whom?

A project's success largely depends on the questions asked before it begins. Right questions lead to right projects; wrong questions lead to wrong projects.

Wrong Questions vs Right Questions

Most initial meetings pass with surface-level questions. These questions gather information but don't bring understanding.

Problem Instead of Page Count

Wrong: "How many pages do you want?"

The client says "5 pages." But what those 5 pages will contain, what purpose they'll serve, and how they'll relate to each other is unclear.

Right: "What problem are you trying to solve?"

The client says "our customers can't reach us." Now you understand the real need: a contact-focused, trust-building structure is needed.

Emotion Instead of Color Preference

Wrong: "What colors do you like?"

Personal color preference can be irrelevant for the brand. Liking purple doesn't mean the brand should be purple.

Right: "What should your brand make people feel?"

A brand that says "reliable and professional" and a brand that says "energetic and bold" require completely different design decisions. Color becomes the result of that decision, not the starting point.

Differentiation Instead of References

Wrong: "Do you have reference sites?"

References are useful but should be used carefully. They can create a "just copy this site" expectation.

Right: "What makes you different from your competitors?"

Understanding differentiation from competitors creates unique positioning. Reference sites are used as tools, not as goals.

Context Instead of Date

Wrong: "When should it be done?"

A date can be a constraint, but understanding why that date matters is more valuable.

Right: "What's the most critical date and why?"

A client saying "my investor presentation is March 15" and a client saying "I'm not in a rush but as soon as possible" require different process strategies.

Briefing Stages

A good briefing isn't about asking random questions — it's a structured discovery process. There are four main areas.

1. Business Goals

This section answers not "what will we do" but "why will we do it."

Questions to ask:

• Why do you need this project? (What's the real trigger?)
• If this project is successful, what will have changed in 6 months?
• How will you measure success? (More customers? More sales? Brand awareness?)
• Do you have an existing digital presence? Why is it insufficient?

Why it matters:

Every decision made without knowing the business goal is an assumption. "Nice site" is a concept everyone understands differently. "Increase online sales by 30% in 6 months" is concrete and measurable.

2. Target Audience

You won't be using the site. Your users will.

Questions to ask:

• Who will use your site? (Age, profession, digital habits)
• What do users want to do when they come to the site?
• Which devices do they access from? (Mobile-heavy?)
• If you have an existing site, what are users complaining about?
• What does the decision-making process look like? (Immediate purchase? Research and return?)

Why it matters:

A B2B software company's users behave completely differently from a boutique cafe's users. The same solution won't work for both. Designing without understanding the user is like driving with your eyes closed.

3. Technical Requirements

The section that defines the project's technical boundaries and needs.

Questions to ask:

• Will you update content yourself? (CMS need)
• What external systems need to be integrated? (CRM, ERP, accounting, shipping)
• Is there a need for payment processing?
• Is multi-language support needed?
• Do you have specific functionality expectations? (Calculator, filtering, user panel)
• Do you have an existing domain and hosting?

Why it matters:

The sentence "let's add a payment system too" spoken mid-project blows up the scope. If asked at the start, it's included in the plan.

4. Constraints

Every project has realistic boundaries. Knowing them is the foundation of an honest relationship.

Questions to ask:

• What's your budget range? (Doesn't have to be exact, a range is sufficient)
• Do you have a time constraint? (Launch, event, season)
• Is content ready or will it be created? (Photos, copy, video)
• Who is the decision-maker? (How does the approval process work?)
• Have you done a similar project before? What went well, what went badly?

Why it matters:

Determining scope without knowing the budget is impossible. The "how much will it cost?" question can only be answered after "what will be done" is clear. But knowing the budget range helps keep scope realistic.

Listening Is More Important Than Asking

Asking the right questions isn't enough — you need to truly listen to the answers.

Seeing Behind What's Said

When a client says "I want a modern site," you need to understand what they mean. "Modern" means something different to everyone.

• An animated, dynamic experience?
• A clean, minimal design?
• Looking more current than competitors?

Follow-up questions: "What do you mean by modern? Can you show me an example you like?"

Taking Notes

Notes should be taken at every briefing meeting. Live notes, then organize.

Why? Memory deceives. "The client wanted this" arguments come from meetings where notes weren't taken.

Validating Assumptions

The question "As I understand it, you want X — is that correct?" shouldn't be underestimated. Misunderstandings are corrected here — not during the project.

After the Briefing

The meeting is over. Notes are taken. What happens now?

Scope Document

Information from the briefing is transformed into a structured scope document:

• Project purpose (1-2 sentences)
• Target audience definition
• Feature list (P0/P1/P2 prioritized)
• Technical requirements
• Constraints (budget, time)
• Excluded items (what won't be done — this is important too)

Mutual Approval

The scope document is sent to the client. The question is asked: "This is what we understood — is it correct?"

If this step is skipped, "but that's not what I meant" arguments will occur throughout the project.

Expectation Management

A good brief aligns expectations. Both sides know what will be done and what won't.

When an out-of-scope request comes, the response is ready: "This is outside scope. We can add it — here's the additional cost and timeline."

For Clients: Preparing a Brief

If you're reading this article as a client, strengthening your brief is in your hands.

Preparing for the First Meeting

Before meeting with the agency, think about:

1. Why? — Why do you need this project?
2. For whom? — Who will use your site?
3. What will change? — What will be different if the project succeeds?
4. How much? — Your budget range (even approximate)
5. When? — Is there a critical date?

Answering these five questions makes the meeting much more productive.

References

List sites you like and don't like. But instead of just "this is nice," say "I like this specific feature about it." What you like is as important as what you don't want.

Conclusion

Every good project starts with a good question.

Projects that come with "build me a site" usually end problematically. Projects that come with "I want to solve this problem" usually succeed.

The difference is in the questions asked. Right questions lead to right understanding; right understanding leads to right solutions.

A brief isn't just a form. It's the project's foundation. And if the foundation is solid, whatever you build on it will be solid.