Feature Request Template: A Form Users Will Actually Fill In

A good feature request template asks about the problem, not the solution. It asks what the person was trying to do, what stopped them, how they get round it today, how often it happens and what it costs them, and who they are, so someone can follow up. Their idea for a fix goes in an optional last field, because it is useful evidence but rarely the best answer. For people outside the team, cut it to four questions and collect the rest yourself. Below are the fields, a template to copy, the short form, good and bad examples, a triage flow and how to reply.

This page is about the form. Getting requests out of emails and chat threads and onto a board with an AI assistant is covered in turning feature requests into tasks, and running one list for requests and bugs together in tracking bugs and feature requests in one board.

Ask for the problem, not the solution

People describe what they want as a solution: “add a CSV export button”, “integrate with our calendar”. Behind each is a need that could often be met another way, sometimes by something you already have. The GOV.UK Service Manual puts it plainly in its guidance on learning user needs↗ (opens in a new tab): focus on the user’s problem rather than possible solutions, for example needing a reminder rather than needing an email or a letter.

A form that opens with “describe the feature you want” gets solutions. A form that opens with “what were you trying to do?” gets problems, and problems can be compared, combined and solved in the way that suits the product.

The fields that matter

• Title. The outcome in the requester’s words: “Send monthly totals to our accountant without copying them by hand.” Not “Export button”.
• Who is asking. Their role and account, and whether others have the same need. One finance lead at a large customer and forty people on the free plan are both evidence, of different kinds.
• What they were trying to do. The job, in a sentence or two, with the situation that triggered it.
• What gets in the way. What happens today, and where in the product.
• The workaround. How they cope now. A painful workaround is strong evidence; “we just don’t do it” may be stronger.
• How often, and what it costs. Daily, monthly, once a year; minutes or hours; a lost sale, a missed deadline, an error.
• What good would look like. The outcome, not the screen: “the numbers reach the accountant on the first of the month.”
• Their idea, optional. Keep it; it shows how they think about the problem. Do not treat it as the specification.
• Evidence and contact. A screenshot or a link, and whether you may follow up and how.

The template

Title:          <the outcome, in the requester's words>

Requested by:   <role, account or team> · <date> · <how it arrived>
Also asked by:  <others with the same need, if known>

Trying to do:   <the job, and what triggered it>
What happens:   <what gets in the way today, and where>
Workaround:     <how they cope now, or "none">
How often:      <daily / weekly / monthly / rarely>
Cost:           <time lost, money, errors, a deadline>

Good would be:  <the outcome, not the design>
Their idea:     <optional: what they suggested>

Evidence:       <screenshot, link, quote>
Follow up:      <yes / no, and how>

The short form for people outside the team

Customers will not fill in thirteen lines, and should not have to. Ask four questions, make only the first two required, and fill in the rest at triage.

What were you trying to do?
What got in the way?
How do you manage today?            (optional)
Anything else we should know?        (optional: ideas, screenshots)

• Do not ask for priority or urgency. Everyone’s request is urgent to them, and the answer tells you nothing you can compare.
• Collect what you can automatically: who they are, their plan or account, the page they were on.
• Say what happens next on the confirmation screen: “We read every request. We will reply when we decide.” Then do it.

If your project lives on a code host, a structured form helps. GitHub’s issue forms↗ (opens in a new tab) are YAML files in .github/ISSUE_TEMPLATE with name, description and body keys; the body lists fields such as textarea, input and dropdown, and any field can be marked required. GitHub describes them as a public preview, subject to change.

name: Feature request
description: Tell us what you were trying to do
labels: ["enhancement"]
body:
  - type: textarea
    id: goal
    attributes:
      label: What were you trying to do?
    validations:
      required: true
  - type: textarea
    id: blocker
    attributes:
      label: What got in the way?
    validations:
      required: true
  - type: textarea
    id: workaround
    attributes:
      label: How do you manage today?
  - type: textarea
    id: extra
    attributes:
      label: Anything else we should know?

Good and bad examples

Title: Dark mode!!!

Please add dark mode, every app has it. Thanks.

Title:        Read the rota at night without the screen dazzling
Requested by: Night-shift nurse, ward account · 12 Sep · in-app form
Trying to do: Check tomorrow's rota on my phone at 3am on a dark ward
What happens: The white screen lights up the room and wakes patients
Workaround:   Turn brightness to minimum; then I can't read it
How often:    Every night shift, three or four times
Good would be: I can check the rota at night without lighting the room
Their idea:   Dark mode

The second version might still end in dark mode. But it also says who needs it, when and why, and it opens other answers, such as a dimmed night view of the rota alone. A second pair:

Title: Integrate with Xero

Title:        Month-end totals reach our accountant without retyping
Requested by: Finance lead, Acme account · 24 Sep · email
Trying to do: Send monthly sales totals to our accountant
What happens: I copy 40 lines from the Reports page into a spreadsheet
Workaround:   Copying by hand, about two hours a month; errors twice this year
Good would be: Totals arrive in the accounting system, or in a file it imports
Their idea:   A Xero integration

A triage flow

1. Acknowledge. Every request gets a reply within a set time, even if it only says “received, we review requests weekly”.
2. Search before filing. Most requests have been made before in other words. Add the new requester to the existing item as a comment, with their words and their reason, rather than filing a second one. A request with twelve names on it is easy to prioritise.
3. Sort it. Is it new, a change to something that exists, or something broken dressed as a request? Mozilla’s Bugzilla, for example, files enhancements↗ (opens in a new tab) as new features, UI and performance improvements and other requests for user-facing change, separately from defects. Features, enhancements and bugs has the edge cases.
4. Fill the gaps. If the problem is unclear, ask one question, not five: usually “what were you trying to do when you noticed this?”
5. Decide. Next, later or no, and write down why. One person makes the call; the Scrum Guide↗ (opens in a new tab) gives ordering the backlog to the Product Owner, and in a small team it is whoever decides what happens next.
6. Tell the requester. See below.

Closing the loop with the requester

A requester who hears nothing stops asking, and the ones who stop are often the ones you most wanted to hear from. Reply three times: when it arrives, when you decide, and when it ships. A “no” deserves a reason and, where there is one, a workaround. Do not promise dates you have not planned.

Received:  Thanks, we have this as FET-212. We review requests every
           Monday and will tell you what we decide.

Decided:   We are building a monthly totals file your accounting system
           can import. It is next after the current release.
   or:     We are not going to build this. <reason>. In the meantime,
           <workaround>.

Shipped:   The monthly totals file is live under Reports. Thank you for
           asking; tell us if it does what you needed.

Feature requests on a fenbs board

On fenbs a request becomes a task of kind feature or enhancement, or bug if triage finds something broken. The request itself goes in the task’s note, the problem box, which is written once and kept. The plan box stays empty until somebody knows how it will be built.

• Requesters can file directly. Give customers or colleagues the suggested Reporter role on a team board: they add tasks and comment, edit only their own, and cannot move tasks between lanes. Whoever files a task follows it, and gets an email when it moves or someone else comments, which covers the “any news?” question.
• Duplicates are held back. When an AI assistant files a task with fenbs_create_item, fenbs compares it with open tasks and those finished in the last 14 days, and returns the likely match instead of filing a copy, so the assistant can add the new requester as a comment.
• Declines are recorded. When a task is moved to Completed you choose how it ended: Completed, Won’t fix, Duplicate, Cannot reproduce or Obsolete. A decision with a wider reason, such as “we will not build integrations this year”, goes on the Decisions page, where the decider is always a person and the tasks it affects are linked.
• There is no voting and no custom request form. Demand is recorded as comments on the task, in the requesters’ own words.