A team keeps hearing the same question: “Can we pay for an order by invoice?” The first response is often to create a large “Payment methods” page, add a table, a downloadable document, and a contact form. But the visitor may be trying to do something much more specific: find out before checkout whether invoice payment is available for their company and what happens next. A page that makes sense inside the company does not necessarily solve that task.
Before writing, name the outcome the person is trying to reach. That is the user need: not the name of a section, not a site feature, and not a process owner’s wish. The UK Office for National Statistics guide to user needs ties that approach to evidence: a need explains what someone wants to do and why.
Separate the visitor’s task from the team’s solution
“We need a page with a document about invoice payments” already contains a solution. It says nothing about who will open the page, what question they have, or whether a document will be useful at that moment. The proposed solution may be helpful, but it is not what you need to test first.
Write the task in three parts:
When I choose a payment method for my company, I want to know whether I can pay this order by invoice, so that I can prepare the documents and complete checkout without getting stuck.
This wording does not promise a document, a table, or a chat. It does give you a way to assess the future content: can people see the conditions, the documents they need, and the next step before they start checkout? If the answer depends on the country, customer type, or order amount, that is part of the task, not a minor footnote.
It is useful to write down an incorrect version beside it: “As a buyer, I want to download a document about payment methods.” That describes a way of delivering information, not an outcome. A document can be part of the answer to the need, but it should not limit the search for a better explanation before it starts.
Do not treat a guess as evidence
An editor almost always begins with a hypothesis: “It looks as though people are missing the invoice-payment conditions.” That is a reasonable starting point, not an established fact. Mark it as a hypothesis and look for observations that could confirm or challenge it:
- anonymised support requests and questions from demonstrations;
- site-search wording and pages after which people continue looking;
- short interviews, or a review of a draft with someone who did not write it;
- an observation of the route: did the visitor find the rule and name the next step?
One question does not prove that everyone needs a page. Several similar phrasings help you decide what to investigate first. Keep the visitor’s words: “pay by invoice”, “an invoice for a company”, “which details do I need?” Do not replace them with an internal process name before you know that readers understand it.
When you have no evidence, a small check is more honest than building content on a confident assumption. For example, show a draft answer to three people in the target role and ask each of them to explain whether invoice payment is available and what they would do next. That tests understanding, not how attractive the writing looks.
One page, one main task
The topic of payment can hide several different needs. An accountant needs documents for an order that already exists. A manager wants to compare options before buying. A customer whose payment failed is trying to fix a specific transaction. Those people have different contexts, different urgency, and different safe next steps.
Do not answer every question with the same introduction. For each need, decide whether you can provide a general, verifiable answer. A payment-rules page can explain available methods, conditions, and documents. A question about the status of a particular payment needs order data and should lead to an agreed support channel. A clear boundary is more useful than a general promise to “help with payment”.
Needs sometimes conflict. A manager needs a short overview for a decision, while an accountant needs precise bank details and exceptions. In that case, make one task the main route and connect it to separate reference material. Do not hide an important condition at the bottom of a page to keep it short, and do not make someone read technical details that do not help them decide.
Build the page around the outcome
Once you have chosen the task, test every part against one question: does it help the person complete it? In this teaching example, a sensible order could be:
- State who can pay by invoice and under which condition.
- Show which information or documents are needed before checkout.
- Explain the next step and where to check an exception.
- Put detailed payment details and rules for an existing order behind a separate protected route when they depend on a specific transaction.
Background information, the history of a payment method, and the internal division of responsibilities belong only where they help someone decide. People usually come for an answer to the current question, not a tour of a process. Clear headings should make a condition, action, or limitation easy to find.
flowchart TD
A[Observation: a recurring question] --> B[Hypothesis about the visitor's task]
B --> C[Collect phrasings and check the context]
C --> D[Describe the outcome without a ready-made solution]
D --> E{Is there a general, verifiable answer?}
E -->|Yes| F[Build a page around the condition and next step]
E -->|No| G[State the boundary and an agreed route to help]
F --> H[Test the page against the original question]
G --> H
H --> I{Does the person know what to do?}
I -->|No| C
I -->|Yes| J[Record the observation and review it later]This teaching diagram shows an editorial check. It does not measure the effect of a particular website.
Test the completed task, not the page
Take the original wording and two nearby questions: “Can a company pay?”, “Do I need an invoice before I buy?”, and “Where do I get documents after payment?” For each one, write down the expected outcome in advance. In the first case, the person should see whether the payment method applies; in the second, understand what to prepare; in the third, reach the route for an existing order rather than a general article.
Ask a reviewer to say out loud what the answer, limitation, and next step are. If they found the word “invoice” but do not know whether the method applies to them, the task is not complete. When an answer requires personal data or action on a payment, check that the page does not invite people to guess the status and instead sends them where it can be checked.
With Dzen Chat, you can run that set of questions against prepared public materials: see which source is shown, whether it matches the task, and whether the boundary for an individual case is visible. The assistant does not replace a rule on a page or check a particular payment. It helps reveal where a visitor received a general answer instead of the next step they need.
A new page is justified when the team can name the task, show the basis for it, and test an understandable result. If all that remains is “let’s make another section”, return to the visitor’s wording. It will show whether you need new content, a connection to existing material, or an honest clarification of the boundary.
Discuss a Dzen Chat pilot using your typical questions and prepared sources.
