How to write an actionable website feature suggestion

A useful website feature suggestion explains the task you want to complete, what the current website makes difficult, and the outcome you want. Propose a solution if you have one, but keep it separate from the need. This gives the website owner something to evaluate without treating your preferred design as the only answer.

You do not need a technical diagnosis, private account data, or a long specification. One concrete task and a clear description of the obstacle are a good start.

Is this a problem or a suggestion?

A problem report describes an action that did not produce its expected normal result. A suggestion asks for different behaviour, even when the existing behaviour works.

For example, a filter that fails to apply is a problem. A request to remember a working filter for your next visit is a suggestion. These are illustrative situations, not reports from IssueProbe customers.

If you are unsure, describe what you observed rather than guessing the category. State whether the behaviour changed or whether you are asking for something the website has never offered. For a failing action, use the guide to writing a useful website problem report.

Start with the task, not a button request

“Add an export button” names a solution but leaves the purpose unclear. An owner still needs to know what you want to export, why, and what you do today.

Explain the task in this order:

1. Goal: What are you trying to accomplish?
2. Location: On which page or part of the website?
3. Current behaviour: What can you do now?
4. Obstacle: What makes the task difficult or incomplete?
5. Desired outcome: What would let you finish?

Describe your own experience. Do not claim that every visitor needs the same change or estimate how many people it would help unless you have evidence. A clear individual need is useful without an invented audience size.

Separate the outcome from your proposed solution

A feature can solve the right problem in the wrong way. Give the owner room to consider alternatives.

For an illustrative suggestion about saved filters, the desired outcome could be “return to the same view without selecting the filters again.” A proposed solution could be “let me save a named view.” Another design might meet the same need. Keeping those two statements separate makes that discussion possible.

Mention a workaround if you use one. Explain where it falls short, but do not invent a time-saving estimate. “I select the same filters each visit” is enough to identify the repeated task.

Use this short suggestion template

Copy these prompts and answer only the ones that help explain your request:

• I am trying to: Describe one task.
• On this page: Name the page or safe page path.
• Today the website: Describe the current behaviour.
• This makes it difficult to: Name the obstacle.
• I would like to be able to: State the desired outcome.
• One possible solution: Offer an idea, if useful.
• My current workaround: Explain what you do instead.
• I would consider this useful when: Describe an observable success condition.

Keep one main suggestion in each report. If you need several unrelated changes, separate descriptions make their purposes easier to evaluate.

Include context without private values

Evidence should clarify the interface, not reveal your private records. You can describe an option that is missing or a sequence of actions without pasting the information you entered.

Do not include passwords, session values, payment details, private form contents, or another person's records. If an image would help, check it for sensitive information before sharing it. In IssueProbe, a screenshot requires a visible visitor action, a preview, and explicit inclusion consent. You can remove it before sending.

A screenshot can show the current interface. It cannot prove that the requested feature is the right product decision. Similarly, browser errors can reveal a separate problem, but they do not establish the value of a proposed feature.

What should the website owner decide next?

Review the need before turning the suggestion into a code change. Ask whether it fits the website's purpose, whether an existing path already meets it, and what important facts are still unknown.

An investigation may help identify relevant source or a next step. It does not replace the owner's decision about whether the feature should exist. The guide to choosing which reports get an investigation explains why that decision should come before spending investigation quota on a suggestion.

How suggestions work in IssueProbe

IssueProbe accepts both problems and suggestions through its website widget. A visitor does not need an IssueProbe account. An optional reporter contact email is unverified and is available on authorized report detail for manual follow-up; IssueProbe does not email it.

When eligible and quota is available, a report can receive a bounded, read-only source investigation. A report submitted without monthly investigation quota remains stored without an investigation. A result separates its conclusion, evidence citations, unknown facts, recommended action, and draft response. It can state that the cause is unknown, and the recommended action requires human approval.

IssueProbe does not automatically implement a suggestion, release code, or send the draft to the visitor. See the illustrative example report for the review structure, and how to respond to a website report for manual follow-up that does not promise an unapproved change.