What to do when a client cannot define their needs?

The client does not need to know the final solution

A client hires a specialist, among other reasons, because they themselves do not know how best to solve their problem. A business owner may notice that the website is not generating inquiries, employees are wasting time manually re-entering data, or the brand looks less professional than the competition. However, they do not have to know whether they need a form redesign, a new information architecture, CRM integration, brand repositioning, or a completely different solution.

Expecting the client to prepare a complete and correct specification can be unrealistic. It is a bit like a mechanic expecting the driver to diagnose the fault on their own before the visit and identify the parts that need replacement. The client should be able to describe the symptoms, the context, and the expected result. The specialist's job is to help them move from that information to the right solution.

However, this does not mean that the freelancer has to come up with the entire project on their own based on a single sentence. Discovering needs requires collaboration. The client brings knowledge about the company, the audience, the constraints, and previous experiences. The contractor brings industry knowledge, the ability to ask questions, and an assessment of the feasibility of the proposed solutions.

The client does not need to know how to build the solution. However, they should participate in determining what problem we are solving and how we will know that the project has been successful.

Briefstreak

Why can't the customer define their needs?

Vague requirements do not always result from a lack of preparation. Sometimes the project is simply at a very early stage. The client sees the problem, but has not yet analyzed it. In other cases, they know the result they want, but do not understand the available options or the technical constraints.

He knows the problem, but he doesn't know the possible solutions

The client knows that too many people abandon their purchase, but cannot identify the reason. They may assume they need a new online store, even though the problem is a complicated delivery form. They may ask for a mobile app, even though their audience would be satisfied with a well-functioning web dashboard.

It is natural that a client describes a need through the lens of a solution they know. Your task is not to automatically reject their idea, but to check why they thought of it in the first place and what effect they want to achieve with it.

There is no single version of needs in the company

The person ordering the service may represent only one point of view. The owner wants to increase sales, marketing wants to publish content easily, customer service expects fewer repetitive questions, and users need a simpler process. All of these needs may be valid, but they are not always consistent with one another.

If the project has several stakeholders, it is not enough to ask one person what they need. You need to determine who will use the solution, who approves it, who finances the project, and whose daily work will be changed.

The client cannot separate priorities from ideas

During a conversation, the client may mention several dozen features, inspirations, and loose concepts. That does not mean that all of them are requirements. Some are an attempt to imagine the project, some are an addition for the future, and some are ideas heard from the competition.

If everything is treated as equally important, the scope will quickly become too large and costly. Therefore, needs must be prioritized according to importance, impact on the goal, and the consequences of leaving out a given element.

The client is afraid to provide the budget

Some clients avoid giving direct answers because they believe the contractor will use any information to raise the price. They do not want to provide the budget, the expected scope, or the importance of individual elements. They hope to receive a complete proposal first and only then decide what they really need.

In such a situation, it is worth explaining that the same goals can be achieved at different levels. The budget is not used to automatically set the price, but to choose a realistic solution. Without this information, you may prepare a proposal that is completely inappropriate to the client’s capabilities.

The client has never ordered a similar service before

A person ordering a first website, visual identity, advertising campaign, or IT system may not know what decisions they will need to make. They do not know the industry process, the typical stages, or the factors affecting the price.

Instead of judging such an inquiry as unprofessional, you need to guide the client through the process. Good questions should be understandable without specialized knowledge and focus primarily on the company, users, problems, and expected results.

The problem is still too poorly understood

Sometimes neither side knows the answer at the beginning. It is not known why customers abandon the form, which processes take the most time, or whether users need the planned feature. The answers require data analysis, user interviews, an audit, a workshop, or building a prototype.

In such a project, one should not pretend that the scope is known. The first product of collaboration should be a better understanding of the problem, and only the second the proper solution.

First separate the need from the proposed solution

One of the most important elements of discovery is distinguishing between what the client actually needs and what they propose to build. The statement “we need a mobile app” describes a solution. It does not explain who will use it, in what situation, what problem should disappear, or why the existing tools are not enough.

The same is true for a request for a new logo, a website redesign, a social media campaign, or process automation. Each of these ideas may be valid, but before starting implementation, you need to understand the reason behind it.

Don't start with the question: “What are we supposed to create?”. Start with the question: “What should change after the project is completed?”.

Briefstreak

It helps to rephrase the client’s answer. If they say they want a new website, you can summarize: “I understand that the main problem is the small number of inquiries from business clients, and the goal of the project is to increase the number of valuable contacts. A new website is currently being considered as a way to achieve this goal.” Such a statement leaves room to check whether a complete redesign of the entire website is actually necessary.

Start with the current situation, not with a list of features

When the client cannot define their needs, the question “What functions should the system have?” usually will not help. The answer will be very general or based on random inspirations. It is easier to talk about what is happening now.

• How is this process currently carried out?
• Who takes part in it?
• What triggers the entire process?
• Where do the most problems arise?
• What takes the most time?
• What errors occur most often?
• What tools does the client use today?
• What works well in the current solution and should be retained?
• What workarounds do employees or users use?
• What happens if the problem is not resolved?

A description of the real process provides much more information than an abstract list of expectations. The client may not remember that they need a data export, but while describing the work they will mention that every Friday they manually copy the results into a spreadsheet. It is precisely in such details that the most important requirements are often hidden.

Determine what the client is trying to achieve

A project should lead to a specific change. Simply creating a website, a film, a brand identity or an application is delivering a product, but it does not explain its purpose. To choose the right scope, you need to understand what the solution will be needed for by the client.

It is helpful to think in terms of the task that the customer or their audience is trying to complete. The user does not need a form for the sake of having a form. They want to get a quote quickly. The company does not need a dashboard just because it looks professional. It wants to notice sales declines earlier and make better decisions.

• Why is this project needed right now?
• What problem is to be solved?
• Who feels this problem most strongly?
• How do users cope with it currently?
• What should become easier, faster, or cheaper?
• What decision or action should the solution help with?
• What will be possible after implementation that cannot be done today?
• What are the consequences of leaving the current situation unchanged?

Define the outcome, not just the deliverables

The result of the project should include both what the contractor delivers and the change the client expects. The deliverable may be a new website. The expected result is easier access to information and an increase in the number of valuable inquiries. The deliverable may be automation. The result is shortening the process from two hours to several minutes.

Not every result can be guaranteed. A freelancer designing a store does not have full control over the number of sales, because it is also influenced by the offer, traffic, prices, and marketing activities. However, it is still possible to define the indicators that the design is meant to affect, as well as the conditions that allow its quality to be assessed.

• How will the client know that the project has succeeded?
• What user behavior should change?
• Which process should take less time?
• Which errors should occur less often?
• Which information should become more easily accessible?
• What minimum result justifies carrying out the project?
• When and how will the result be evaluated?

Ask about specific situations from the past

Questions about the future often lead to declarations and wishes. A client may say that the system should be "intuitive", "modern", "scalable", and "simple". Everyone understands these words differently. Questions about specific events are much more useful.

• When did this problem last appear?
• What exactly happened then?
• Who tried to solve it?
• How much time did it take?
• What tools were used?
• What was the most frustrating part?
• How did this situation end?
• Does a similar problem happen regularly?

A concrete example makes it possible to see the context, the sequence of actions, the participants, and the constraints. It also often reveals the difference between what the company considers its official process and how the work looks in practice.

Do not ask only what the customer wants

A direct question about expectations is necessary, but it cannot be the only method. People omit tasks that seem obvious to them, do not remember all exceptions, or propose solutions based on limited knowledge.

Depending on the type of project, it is worth supplementing the conversation with an analysis of existing materials, data, forms, procedures, messages from customers, call recordings, website statistics, or tools used. When designing processes, observing users’ real work may also be helpful.

The client may say that their employee performs the task in a simple way. Only observation will reveal that between stages they use a private spreadsheet, copy data from messages, and manually check several exceptions. These actions may be of key importance to the project, although they did not appear in the original description.

How to ask questions in order to receive useful answers?

Ask one question at a time

A question containing several threads usually leads to an answer to only one of them. Instead of asking at the same time about the audience, purpose, budget, features, and deadline, break the conversation into shorter parts. This way, it is easier to notice ambiguities and ask a follow-up question.

Avoid jargon

The client may nod in agreement even though they do not understand the question about information architecture, webhooks, personas, the funnel, key visual, or the staging environment. Use language that describes actions and results. Technical terminology can be introduced later, when it is actually needed.

Ask for examples

When a client says the project should look professional, ask which specific materials they consider professional and what exactly they like about them. When they expect ease of use, ask for a description of the task that the user should be able to perform without help.

Ask about the reason

It's not about mechanically repeating the question “why?” after every answer. However, it is worth understanding the motive behind the requirement. If a client wants login through social media, ask what problem it is supposed to solve. Perhaps users forget their passwords, registration takes too long, or the company wants to obtain a specific type of data.

Summarize in your own words

After the more important part of the conversation, present your own understanding of the situation and ask for confirmation. Do not merely repeat the client's words. Try to organize the relationships between the problem, the audience, the goal, and the proposed scope.

I understand that the biggest problem is not the number of messages itself, but that they go to different people and it is not clear which inquiries have already been handled. So the priority is a shared place to manage requests, and automatic replies are for now just an addition. Am I summarizing that correctly?

Example summary

Determine who really uses the solution

The person buying a service is not always its user. An owner orders a system for employees, the marketing department a website for customers, and a manager a report for the board. Each of these groups may have different goals, constraints, and levels of knowledge.

If users do not take part in determining needs, the project may meet the expectations of the decision-maker, but make everyday work more difficult. It is not always necessary to conduct large-scale research. Sometimes a short conversation with a few people carrying out a given process is enough.

• Who will use the solution most often?
• Who makes the purchasing decision?
• Who will approve the result?
• Who will provide the materials and knowledge?
• Whose responsibilities will change after implementation?
• Who will maintain the solution after the project is completed?
• Are the needs of the various groups consistent with each other?

Turn general descriptions into criteria

Words like “modern”, “simple”, “premium”, “fast”, “flexible”, or “intuitive” are not requirements yet. They are a direction that needs to be clarified.

If the site is to be fast, determine whether you mean technical load time, easy information finding, a short purchasing process, or efficient content management. If the system is to be simple, specify what tasks the user is to perform and what mistakes they are currently making.

• What exactly does this term mean in this project?
• What example meets this expectation?
• What example definitely does not meet it?
• Who will evaluate this element?
• How will we objectively know that the requirement has been met?

Help the client set priorities

When the conversation is going well, the list of needs usually grows. That is not yet a problem. The problem appears when all items are considered mandatory, despite the limited budget and deadline.

Priorities can be set by asking about the impact of giving up a given element. If the project without a specific feature still solves the most important problem, it is probably not essential in the first version.

• What absolutely must be included in the first version?
• Without what will the solution fail to meet its basic purpose?
• Which elements deliver the greatest value?
• What can be done manually at the beginning?
• What can be moved to the next stage?
• Which requirements result from law, safety, or contracts?
• What would the client give up first with a smaller budget?

A good approach is to divide them into necessary, important, optional, and left for the future elements. Simply assigning labels is not enough — each decision should result from the project goal and the available constraints.

Show the solution on an example before you build the whole thing

Some needs cannot be clarified through conversation alone. Only after seeing an example may the client notice what is missing, what is unnecessary, or what the information flow should look like.

Depending on the project, sketches, mockups, mood boards, sample content, prototypes, samples, process maps, or small demo versions may be helpful. Their purpose is not to perform part of the project for free, but to quickly verify important assumptions before costly implementation.

A prototype should answer a specific question. It may check whether the user understands the form layout, whether the system can be integrated with existing data, or whether the proposed style matches the brand positioning. There is no need to design the entire solution in order to verify the most important risk.

When should discovery be paid?

A short qualification before an offer is usually part of sales. You can ask a few questions free of charge, assess the fit, and establish the basic scope. The line is crossed when the client needs real analytical work: an audit, consultation with multiple people, data analysis, workshops, process mapping, or preparation of a detailed concept.

Such a stage has independent value. After it is completed, the client should better understand the problem, priorities, risks, and possible solutions — even if they commission the implementation to someone else. That is why discovery can be a separate service, not a free add-on to the estimate.

• The project is complex and involves many processes.
• The requirements of several stakeholders are contradictory.
• It is not known which solution is feasible.
• The existing system or documentation needs to be analyzed.
• An accurate estimate requires preparing a concept.
• The project will be costly, and incorrect assumptions may generate significant losses.
• The client expects a workshop, audit, research, or a detailed recommendation.

What can be created within a paid discovery?

• Problem and project objective description.
• Current process map.
• List of stakeholders and users.
• Organized requirements.
• Priorities for the first stage.
• Assumptions and constraints.
• List of risks and unknowns.
• Recommended solution variant.
• Preliminary architecture or mockup.
• Implementation plan and more detailed estimate.

Do not prepare a fixed price when the scope is still unknown

One of the riskiest mistakes is giving a binding price just because the client expects it. If it is not known exactly what is to be done, any specific amount is based on hidden assumptions.

The contractor may assume a simple version, while the client assumes a more elaborate one. The difference only comes to light during implementation. Additional charges appear, conflicts arise, and the client is left with the impression that the freelancer is trying to change the previously agreed terms.

When the scope is unclear, you can provide an estimated range, price the discovery phase, or bill the first part on an hourly basis. A project price makes sense only when both parties understand what result, scope, and level of responsibility it covers.

At this stage, I can provide only a range of 15,000–30,000 PLN net, because we do not yet know the number of integrations or the data flow rules. I propose starting with a paid workshop and analysis. After this stage, you will receive the recommended scope, plan, and a detailed cost estimate for implementation.

Sample response

Document assumptions, not just decisions

In projects with high uncertainty, it is important to record not only what the parties agreed on, but also what assumptions the scope is based on. If the price assumes that the client will provide ready-made content, access to a specific system, or the involvement of one decision-maker, this should be clearly stated.

The assumption may later turn out to be false. This does not automatically mean that someone made a mistake. It is important that the parties can assess the impact of the new information on the scope, price, and schedule.

• What do we currently consider to be true?
• Which information has been confirmed?
• Which data is still missing?
• Which decisions must be made later?
• What can significantly change the scope?
• Who is responsible for checking the individual assumptions?

How do you conclude discovery with a concrete summary?

The conversation should not end with a vague feeling that both sides roughly understand the project. It is worth preparing a short summary and asking the client for confirmation.

1. Describe the current situation.
2. Name the most important problem.
3. Identify the users and stakeholders.
4. Define the main project goal.
5. Define the expected result.
6. List the scope of the first stage.
7. Write down the out-of-scope elements.
8. Present the most important assumptions and risks.
9. Indicate the materials and client decisions needed.
10. Define the next step.

The summary does not have to be a long specification. However, it should allow the client to notice whether the contractor has correctly understood their situation. If differences already appear at this stage, it is much cheaper to clarify them before implementation begins.

What not to do when the client does not know their needs?

Don't guess for the client

You can formulate hypotheses and recommendations, but they should be clearly marked. If you independently assume what the client needs and then build the entire offer around that, you risk preparing a solution for a problem that does not exist.

Don't turn the conversation into an interrogation

A long list of questions asked without context can overwhelm the client. Explain why a given piece of information is needed, respond to answers, and skip questions that are not relevant to a specific project.

Don't suggest the answer too early

The question “Do you need an application with an admin panel and automatic notifications?” steers the client toward a specific solution. It is better first to ask who manages the information, how they do it currently, and when they need to contact users.

Do not treat inspiration as a specification

The client may show a competitor’s website or an example project and say that they want something similar. It is necessary to determine which elements are important to them and why. The inspiration may concern the style, structure, functions, or overall impression, but it rarely describes the full requirements.

Do not promise a result that cannot yet be assessed

If you do not understand the problem, you cannot responsibly guarantee that the proposed solution will produce the expected effect. You can commit to carrying out an analysis, preparing recommendations, or completing a specific scope, but do not pretend to be certain where significant unknowns still remain.

When is it better to refuse cooperation?

Unclear needs in themselves are not a red flag. The problem is a lack of readiness to discover them together. If the client does not know the scope but answers questions, shares materials, and accepts the analysis phase, the project can be a very good collaboration.

Risk increases when the client simultaneously cannot define needs, refuses to participate in discovery, expects an immediate fixed price, and wants a full guarantee of the result. In such a setup, the contractor assumes responsibility for decisions for which they did not receive sufficient information.

• The client does not want to answer basic questions.
• They do not provide the materials needed for analysis.
• It is not known who makes the decisions.
• Each stakeholder expects something different, but no one wants to set priorities.
• The client requires a fixed price without defining the scope.
• They expect a free preparation of a complete strategy or concept.
• They do not accept any limit on the number of revisions.
• They want the contractor to guarantee a result dependent on many external factors.

Example: the client wants a “modern website”

The client is requesting the preparation of a modern company website. They do not know how many subpages they need, what features should be included, or what exactly modernity means to them.

Instead of immediately asking about the preferred style, the freelancer establishes why the company is considering a change. It turns out that the current website was created eight years ago, works poorly on phones, and presents an outdated offer. Most clients come from referrals, but after visiting the website they mainly contact the company about the cheapest services. The company wants to win larger B2B contracts.

Further discussion shows that the most important thing is not just modernizing the look. The website should explain the offer for larger companies, present projects, address common concerns, and direct potential customers to the appropriate form. The company does not need a blog, an online store, or an extensive client panel.

The vague brief has been turned into a specific goal, target audience, scope, and way of evaluating the project. Only at this point can we responsibly discuss the structure, deadline, and price.

Example: the client wants an app for company management

The original request is very broad: the company wants an application in which employees will manage clients, tasks, documents, and reports. Attempting to estimate the entire system at this stage would be guesswork.

During discovery, it turns out that the biggest problem is not the lack of a single system, but the manual transfer of data about new orders between the sales department and fulfillment. Errors at this point cause delays and complaints.

Instead of starting with an elaborate application, the first stage can be organizing the order form, a central fulfillment list, and automatic assignment of the responsible person. The remaining functions are saved as possible development stages, but they do not increase the cost of the first version.

How to use a brief when the needs are unclear?

The brief should not require the client to have specialized knowledge or a ready-made list of solutions. If the form starts with questions about technology, formats, features, and detailed structure, someone at an early stage may abandon it or give random answers.

A better brief leads the client from the information they know to the information that needs to be clarified together. First, it asks about the company, the audience, the current situation, and the problem. Then it asks about the goal, priorities, constraints, materials, deadline, and budget. Questions about the solution appear only later.

It is worth allowing the client to choose the answer “I don’t know” or “I need a recommendation.” Uncertainty is important information. Thanks to it, the freelancer knows that a given area requires a discussion, analysis, or presentation of options.

Example order of questions in the brief

1. What does the company or project do?
2. Who will use the result?
3. How are you currently solving this problem?
4. What is not working in the current solution?
5. Why do you want to address this right now?
6. What result will be a success for you?
7. Which elements are most important?
8. What materials and resources are already available?
9. What is the expected deadline?
10. What budget or budget range is planned?
11. Who will participate in decision-making?
12. In which areas do you expect recommendations from the contractor?

How does Briefstreak help organize unclear queries?

In Briefstreak, you can prepare a separate brief for a specific service and guide the client through questions in a logical order. Thanks to single-choice and multiple-choice answers, text fields, attachments, date questions, and conditional logic, the form can adapt to the client’s situation.

A person who is only just looking for a solution does not have to answer the same detailed questions as a client with a ready-made specification. They can first describe the problem and the expected result. Based on these answers, the freelancer decides whether they can prepare an offer, need an additional conversation, or should propose a paid discovery.

A structured brief does not replace thinking or conversation. However, it limits chaotic message exchanges, reveals missing information, and helps both sides see which decisions have already been made and which still require work.

Step-by-step process

1. Do not ask the client for a finished specification.
2. Determine why the project is needed right now.
3. Ask for a description of the current situation and a specific example of the problem.
4. Separate the need from the solution proposed by the client.
5. Identify the users, the decision-maker, and the other stakeholders.
6. Define the expected result and how it will be evaluated.
7. Analyze the existing materials, data, and processes.
8. Turn general statements into specific criteria.
9. Set priorities and the minimum sensible scope.
10. Record unknowns, assumptions, and risks.
11. If necessary, propose a paid discovery or prototype.
12. Only after clarifying the scope prepare a binding quote.
13. Send the client a summary and obtain their confirmation.
14. Treat later new information as a change in assumptions that must be consciously assessed.

Summary

A client who cannot precisely define their needs does not have to be a difficult or unprepared client. Very often, they are simply at a stage where they understand the problem better than the possible solutions. That is exactly when they need a specialist the most, someone who will help them organize the situation.

However, you should not fill in all the gaps with your own assumptions. Effective discovery is a collaborative process: the client provides knowledge about their company and users, and the contractor helps turn that knowledge into goals, priorities, requirements, and a realistic scope.

It is best to start with the current situation, specific problems, and the expected change. Only later is it worth talking about functions, appearance, technology, and materials to be delivered. This way, the solution results from the need, not from the first idea that came up during the conversation.

If determining the requirements requires an audit, workshops, data analysis, or developing a concept, it should become a separate, paid stage. A freelancer does not have to solve a complex problem for free just in order to be able to provide a price.

The goal is not to eliminate every unknown before the start. In many projects, that will be impossible. The point is to identify the most important assumptions, consciously limit risk, and establish a process through which subsequent decisions will not be made randomly.