User needs versus what users ask for

A request names a solution, a need names a job

'We need more blog posts' is a request. 'Make the form easier' is a request. Neither tells you what is wrong.

I treat a brief as the start of a diagnosis. The thing someone asks for is usually the most visible part of the problem, and it is often not the part worth fixing.

You might ask for more articles because enquiries have slowed. The cause could be that your services page never explains who you help. You might ask for a shorter form because people abandon it. The cause could be that they should not have to complete that form at all.

My position, and the one I will defend: writing before you understand the need is expensive guesswork, and the request is the least reliable evidence in the room. It is not that people mislead you. They describe the solution they can see.

What counts as a user need

A user need is something the reader has to do or find out. It is stated without naming the thing you will build.

GOV.UK guidance on identifying user needs uses a 3-part format: as a [user], I need to [do something], so that [reason]. It also gives the failure case directly. 'A benefits calculator' is not a user need, because it names a solution that may or may not be the right one. The need is getting the financial help you are entitled to. A calculator is one answer to that, and possibly not the best one.

The Nielsen Norman Group makes the same point through grammar in its guidance on user need statements: write the need as a verb, not a noun. 'Select from options' is a need. 'Dropdown menu' is a solution wearing the costume of one. NN/g also notes that users do not always know what they need, even when they say they do.

That gives you a quick check on any brief. If the sentence contains a deliverable, it is a request. If it contains a task and a reason, it is a need.

Three things get confused here, so it is worth separating them.

• A want is what someone says they would like. It is useful evidence and poor instruction.
• A need is the job they are trying to finish. It survives being asked 'so that what' twice.
• A requirement is what you have decided to build once you understand the need. It comes last.

Translating 5 common requests

This is the table I work through when a request arrives. The middle column is a hypothesis, not a conclusion. The third column is what would have to be true for the hypothesis to hold, and it is the part most people skip.

The request	The likely job underneath	Evidence that would confirm it	What the answer might be instead
We need more blog posts	Prospects arrive interested but cannot tell whether you are a fit	Traffic is steady, enquiries are not, and sales calls repeat the same 4 questions	Rebuild the services page around those questions
Make the form shorter	People do not know what happens after they press submit	Abandonment clusters at the final screen, not the long middle	State the next steps and the response time before the form
We need a downloadable pricing guide	Someone wants to judge affordability without talking to you	Enquiries ask for a ballpark before anything else, then go quiet	Publish how you price, with a range and what moves it
We need more case studies	A buyer has to justify the choice to somebody else	Deals stall after a good first call, at the point a third party gets involved	One page they can forward, covering scope, cost basis and risk
Redesign the homepage	Visitors cannot work out what you sell in the first screen	People land, scroll, and leave for the about page to find out what you do	Fix the opening screen and the navigation labels, not the design

The right-hand column is a suggestion, not a prescription. The value of the table is that it forces a hypothesis into the open where evidence can contradict it.

A public-sector example: 'make the form easier'

This is a composite of a pattern I saw repeatedly in government work, not a single project. Treat it as illustration.

A team had a form for reporting a change of address. It asked for name, old address, new address, reference number, date of the move and contact details. People complained that it was long and confusing.

The obvious response was to simplify the wording and cut a few fields. That would have made a bad process slightly less irritating.

The better question was why people were filling it in at all. The organisation already held most of the information. The user had logged in, so their name, reference number and current address were known. Asking them to type it again added work without helping anyone decide anything.

The need was not a friendlier form. It was a service that showed the details it already held, asked for the one thing that had changed, and confirmed what would happen next.

That distinction changes the job completely. Responding to the request means rewriting labels. Understanding the need lets you challenge the process behind the page. The best content work often removes content rather than producing more of it.

A business example: 'we need more blog posts'

A business owner described a familiar problem. Their site had steady traffic and too few enquiries. Their conclusion was immediate: more blog posts. They arrived with a topic list ready, and wanted a publishing schedule.

The business sold a specialist service. It was not a casual purchase. Prospects usually arrived after a bad experience with a cheaper provider, or when an existing arrangement had failed.

I looked at the site before discussing article ideas. The homepage led with broad language about quality and expertise. The services page listed what the business did, but not how projects worked, what a typical engagement involved, or why it suited someone who had been let down before. There was no example of a finished project and no explanation of how pricing was decided.

Publishing more articles would have brought more people into the same unresolved journey.

They were not missing topics. They were missing the information that turns interest into confidence. The first job was to rebuild the core pages around the questions prospects already asked in sales calls:

• what problem do you solve that another provider has not
• what will I get, and what will I need to do
• how do you decide what this costs
• how will I know this is the right fit before I commit

Only then did blog content make sense, answering early questions and reaching people who could not yet describe their problem. Those articles now had somewhere useful to send them.

I should be clear about the limits of that account. I did not run a controlled comparison, and I have no before and after enquiry figures I can publish. What I can say is that the questions the new pages answered were the questions the owner was already answering by email, one prospect at a time.

What people say and what they do

This is the same gap I look at in the 'Why We Buy' series.

Someone may say they want more choice, then leave a page that gives them 6 similar options and no help choosing. Someone may say price matters most, then choose the more expensive option because its process looks clearer and less risky.

Your reader may tell you they want more information. What they may need is confidence that they will not make an expensive mistake. Those call for different content.

That is why a content request is not research. When someone says they need more blog posts, they may be right. I want to see what people do on the site, where sales conversations stall, and which questions keep coming back, before I agree.

Where user needs and business needs pull apart

Most of the time they do not conflict. Helping someone decide quickly is good for both of you.

They do conflict in specific places. You want an email address before you show pricing. The reader wants the pricing. You want people to stay on the page. Some of those people should leave, because you cannot help them.

When it happens, name it rather than dressing the business need up as a user need. 'We gate this because it qualifies leads' is a defensible decision you can weigh. 'Users prefer a personalised quote' usually is not, unless you asked them. I have written more about what happens when clarity loses that argument in plain English as a conversion tactic.

The one question, and where to find the answer

The question I come back to is: what is the reader trying to get done before they ask for this.

Ask it when a client wants a new landing page. Ask it when your team wants to rewrite a form. Ask it when someone proposes a content calendar because traffic dipped.

The evidence is usually already in the business. GOV.UK guidance points content teams at analytics, call centre data, previous research and third-party sources such as Citizens Advice. The small business version is the same idea with smaller inputs:

• enquiry emails, read for the questions that repeat
• the questions you answer on sales calls before anyone asks about price
• the point in the journey where people stop, from your analytics
• watching one person use the page and noting where they hesitate

If you are working with a strategist, give them more than the deliverable you want. Show them the customer messages. Tell them where prospects disappear. Then ask 4 direct questions: what is happening just before people ask for this, what are they trying to decide or avoid, what do they already know, and if we fixed this request perfectly, what problem would remain.

The answer may still be to write more blog posts. Sometimes the request is right. It should be the conclusion of the work rather than the start of it.

Pick the last request someone made of your website and run it through the table above. If you cannot fill in the evidence column, that is the work to do first.