How to Choose an Article Topic From Real User Needs

Start with the reader’s task, not the topic label

Write the proposed need in three parts:

As a [specific reader], I need to [perform or decide something], so that I can [reach a useful outcome].

This structure is adapted from the GOV.UK user-needs method, which recommends identifying the user, the action, and the reason for the action. Its guidance also warns editors to be cautious with vague verbs such as “understand” unless understanding is necessary for a defined task (GOV.UK: Identify user needs).

For example, “beginner photography” is a subject, not yet an article task. Better candidates might be:

The second version is narrower because it names an audience, an action, and a decision. It also gives you a test for scope: information that does not help the reader make that decision probably belongs elsewhere.

Keep one main intent per article. A question asking how to choose a tool, a question asking how to use that tool, and a question asking whether the tool is suitable may be related, but they can require different prerequisites and outcomes. Combining them too early produces a page that is broad in title but incomplete for each task.

Collect evidence in an evidence ledger

A question is a lead, not automatically a topic. Record enough context to judge whether it represents a public information need. A simple spreadsheet is sufficient; GOV.UK specifically recommends recording supporting evidence alongside user needs and acceptance criteria (GOV.UK: Identify user needs).

Use one row per observed question or cluster of closely related questions:

Do not inflate frequency by counting the same question copied across several channels. Record the underlying need once and note the channels where it appeared. Conversely, do not dismiss a need merely because it has appeared only a few times if each example shows the same unresolved task and the answer could serve a wider public audience.

A useful ledger distinguishes evidence from interpretation. “Four readers asked whether a first exercise requires special equipment” is evidence. “Readers want a low-cost beginner guide” is an interpretation. Keep both, but label them separately.

Separate public needs from support-only questions

The key editorial question is not simply, “Did someone ask this?” It is, “Can a general page help a meaningful group of readers complete the same task?” Digital.gov’s plain-language guidance begins from the observation that people visit websites to do different things and recommends organizing content around the audience and what it needs to accomplish (Digital.gov: Principles of plain language).

Classify each candidate in the ledger:

A recurring public need:

Create or update an article when the question has a stable, general answer and the same task appears across people, channels, or situations. Examples include choosing among clearly described options, preparing for a common process, or diagnosing a broadly observable problem. The article should state its audience and boundaries so that readers can recognize whether it applies to them.

A support-only need:

A support-only question depends on private account data, an individual order, a personal configuration, or an action only an operator can perform. It may justify a support instruction or contact route, but not necessarily a general editorial article. Do not turn “Why did my account receive this message?” into a universal explanation when the answer depends on information unavailable to other readers.

You can still publish a public companion page if there is a repeatable general task, such as explaining what the message category means and what information a reader should gather before contacting support. Keep the private resolution outside the article.

A duplicate need:

A duplicate is a real question that an existing page already answers at the right level of detail and for the same audience. The correct action may be to improve the existing page’s opening, examples, navigation, or missing condition. A new URL would divide attention without adding a distinct task.

Without a complete site inventory, an editor cannot honestly declare that no duplicate exists. The practical response is to inspect the known relevant pages, mark the inventory check as incomplete if necessary, and avoid presenting a new article as the only answer.

Use a decision gate before assigning a title

Run the candidate through five gates. A “no” does not always kill the idea; it tells you what kind of work is needed.

Use the result as an editorial gate:

This gate is an editorial inference built from two principles in the sources: content should serve a defined audience and task, and the publisher should retain evidence for the need. It is a decision aid, not a search-engine formula.

Turn the winning need into a useful article brief

Once a topic passes the gate, write the brief before choosing polished wording. Include:

For the example topic, an acceptance checklist might be: the reader can convert a raw question into a user statement; identify the central task; classify the evidence as public, support-only, or duplicate; and choose create, update, hold, or decline. This follows the logic of GOV.UK’s acceptance criteria, which describe what must be true for a user need to be met (GOV.UK: Identify user needs).

Use the brief to control the title. “How to choose an article topic from real user needs” is appropriate for editors who need a repeatable selection method. “How to find the best content topics” would be broader and imply an unsupported ranking or quality judgment. Google’s own guidance asks whether a site has an intended audience, whether content helps readers achieve their goal, and whether the content is made for people rather than primarily to attract search visits (Google Search Central: Creating helpful, reliable, people-first content). Those questions reinforce the value of a precise editorial task, but they do not assure traffic or rankings.

Make the article answerable, readable, and maintainable

A real need can still produce a weak page if the draft makes the reader reconstruct the answer. Put the direct answer near the beginning, then explain the conditions that change it. Use the reader’s terminology from the ledger where it is clear, but define internal editorial terms such as “support-only” and “duplicate.”

Organize the article around decisions and actions rather than a list of loosely related keywords. Digital.gov recommends writing for the audience, organizing information, using short and simple language, and avoiding unnecessary jargon (Digital.gov: Principles of plain language). For an editorial method, that means showing the ledger fields, the decision gate, and at least one worked example—not merely advising editors to “understand their audience.”

Before acceptance, check each consequential statement:

If the answer is no to the last question because the inventory is incomplete, record that limitation. An honest “needs site-inventory review” is more useful than an unsupported claim that the topic is new.

Keep exploring this topic