Feature Request Form Template (Copy-Paste)

A feature request form template is a short intake form that captures the problem, the user who has it, the desired outcome, and the exact place in the product the change should land. Use it as a public form, a Linear issue, or a GitHub issue so every request is comparable and searchable.

Most forms fail because they ask "what should we add?" instead of "what can the user not finish?", so the team inherits a guessed solution.

I have sat in reviews where three founders described the same button three ways and the engineer built a fourth. The form is the fix, but only if the location field is a named element, not a paragraph of "the thing on the right."

If you already have a prose feature request template, this post is the form version of that same discipline.

What should a feature request form template include?

A feature request form template needs six fields: title, problem, user, current behavior, desired outcome, and location. Priority and attachments come after those six, never instead of them.

Lead with the problem, not the widget. "Add a dropdown" is a solution guess. "First-time buyers cannot tell shipping is free before they enter a card" is a problem the team can solve more than one way.

The location field is the one most public forms skip. Write the screen name plus the control, and if you can, the accessibility name: AXButton "Checkout" in the cart footer.

That is the same habit that makes a product feature request template usable by an engineer or an AI agent. A form that only stores a screenshot forces someone to re-identify the control later.

Keep the form short enough that a customer or a PM will finish it. Seven required fields is already too many for a public intake; make title, problem, user, outcome, and location required, and treat current behavior and priority as optional.

Feature request form template you can copy

Paste this into Typeform, Tally, Google Forms, Linear's intake, or a GitHub issue form. The field names stay the same so you can search across sources.

Title: [Outcome] for [user] on [screen]
Problem: What can the user not finish, and why does it matter?
User: Who has this? How often?
Current behavior: What happens today, on which screen?
Desired outcome: What should be true after we ship? (this is the test)
Location: Screen + named element (role + label if you have it)
Priority: P0 / P1 / P2 and one sentence why
Evidence: screenshot, clip, or capture bundle (optional)

If you run GitHub Issue Forms, map each line to a textarea or input with those ids. If you run Linear, put the same fields in the description template so a Slack-filed request still has a slot for location.

The outcome line is acceptance criteria. Write it as a testable sentence: "A first-time buyer sees that shipping is free before the card field appears."

How do I turn this form into Linear or GitHub issues?

A form that dumps into email is a graveyard. Route each submission to Linear or GitHub with the field names intact so engineers do not have to reformat them.

Linear's intake and GitHub Issue Forms both accept a structured body. Keep Location as its own heading so you can search Location: later.

If you review builds on a Mac, you can skip typing the location. Hold ⌥⌘A, circle the control, and say the request. A point-and-speak app can resolve the named accessibility element, transcribe on-device, and file the bundle to Linear or GitHub.

That workflow is the same one we use for point-and-speak bug reports in Linear and GitHub. A feature request is a bug report that describes a missing outcome instead of a broken one.

The agent-facing path is also valid. If your team ships with Claude Code or Cursor, the form's location field can become a resolved element path instead of a screenshot the model has to guess from.

Vague captures should stay flagged, not auto-guessed. If confidence is low, ask the requester which of two similar buttons they meant.

Public customer form

Type: External intake.

Required fields: Problem, user, outcome, location.

Route to: Linear "Intake" team or a GitHub discussion category.

Internal PM form

Type: Roadmap candidate.

Required fields: All six plus priority.

Route to: Linear project or GitHub issue with a feature label.

Agent-ready form

Type: Spec for Claude Code, Cursor, Codex, or Zed.

Required fields: Outcome, location as a named element, current behavior.

Route to: Local MCP instruction or a tracker ticket the agent can read.

What makes a public feature request form get junk?

Public forms attract solution dumps. People write "add dark mode" because that is easier than describing the glare on their laptop at night.

You cannot stop that with a longer form. You stop it by making the problem field required and the solution field optional, labeled "your guess, we may ignore it."

Ask what they cannot finish. "I cannot find last month's invoice on my phone" is more useful than "add a filter chip."

The other junk source is missing location. Ten people will file "the button" and mean ten buttons. A customer feedback tool that stores a screenshot without a name still leaves the engineer to re-identify the control.

Browser annotation tools help on websites. Jam.dev is free and strong at console logs, but it is Chromium-only. Marker.io is the agency default at $39+/mo, also browser-only, no voice, no native apps.

If your product is a Mac app, an Electron IDE, or a desktop build, a browser form cannot circle the real control. Native capture plus a named element is the honest upgrade.

How do I score and batch incoming requests?

A form is only useful if you can compare rows. Score on frequency, severity of the blocked job, and whether the location is specific enough to implement.

I use a three-bucket triage once a week. Bucket A is a named element plus a testable outcome. Bucket B is a clear problem with a fuzzy location. Bucket C is a solution with no problem.

Bucket C goes back with one question: what were you trying to finish? Bucket B gets a follow-up capture. Bucket A goes on the roadmap or into an agent session.

When two requests share a location, merge them. That is the hidden value of a named element: you can see that five "checkout" complaints are the same AXButton.

If you review on a Mac, fill Bucket B yourself. Circle the control, speak the request, and attach the resolved role, label, and frame so the next person does not have to hunt.

PinVari's launch price is a one-time $39 license (first 500, then $59) if you want that capture loop on your own Mac, filed to Linear or GitHub, without a subscription for the core app.

Feature request form vs a free-text Slack message

Slack is where requests are born. The form is where they become work.

A Slack message of "can we make this less confusing" has no user, no outcome, and no location. Paste the five required fields under the message, or do not file it.

If the request starts in a live review, record it while you still have the build open. Voice-only (⌥⌘V) is enough when you do not need to circle; a full mark (⌥⌘A) is better when two buttons look alike.

Deictic words need a pointer. "Make this shorter" is useless unless "this" is bound to the element under the pointer at the moment you said it.

That binding is how a form stays honest when a PM is talking faster than they can type. Each mark can carry its own words if you circle three things in one breath.

FAQ

What is a feature request form template?

A feature request form template is a reusable intake with fixed fields for problem, user, outcome, and location. It is the form version of a feature request, meant for customers, PMs, and support to fill the same way.

The point is comparability. If every request uses the same field names, you can search, merge, and hand the row to an engineer or an agent.

How is a feature request form different from a bug report?

A bug report describes current broken behavior. A feature request describes a job the user cannot finish yet.

Both need a location. Both get worse when they lead with a guessed widget instead of the job. Use the same location discipline so your tracker is one system.

Should customers pick priority on the form?

No. Ask for frequency and impact, then you assign P0, P1, or P2.

Customer-set priority floods the top of the board. A sentence like "this blocks every first-time checkout" is more useful than a red dropdown.

Can I use this feature request form template in Linear and GitHub?

Yes. Paste the fields into a Linear description template or a GitHub Issue Form. Keep Location as its own heading.

If you capture on a Mac, attach the named accessibility element and a cropped screenshot so the issue is executable, not just readable.

What if the requester cannot name the UI element?

Let them circle it. On macOS, accessibility can resolve role, label, and frame under a point, with a confidence score.

If confidence is below 0.8, ask. Do not silently guess which of two similar buttons they meant.

Do I need a screenshot if the location field is filled?

A screenshot still helps humans. The named element is what helps agents and search.

Use both when you can. A cropped region plus AXButton "Checkout" beats a full-screen PNG with an arrow drawn in Preview.