Feature Request Form: Template & Best Practices

A feature request form that developers can execute on includes the named element you're talking about, a cropped screenshot of that element, and enough context (window title, URL, accessibility path) that the developer or AI agent knows exactly what to change. Most forms ask for "description" and "impact" in freeform text fields, then force a followup Slack thread to clarify which button or where in the app.

A good form treats the what (the element) and the where (its location and state) as structured data, not prose. When you file "change the font size on the submit button" but don't identify which submit button in a multi-page checkout, you've created a meeting, not a task.

What fields should a feature request form include?

A complete feature request form has three layers: identification (title, category, priority), element resolution (the named UI component or code path), and context (screenshot, window, URL, user environment).

Identification layer:

• Title (short, starts with a verb: "Add dark mode toggle to settings")
• Category (UI, API, performance, integration)
• Priority (P0/P1/P2 or High/Medium/Low)
• Requester (name, role)

Element resolution layer:

• Element name (the accessibility role + label: AXButton "Submit Order")
• Element path (parent chain: Application > Window > Group > Button)
• Frame/coordinates (x, y, width, height in screen pixels)
• Confidence score (if auto-resolved: 0.0-1.0, where <0.8 flags uncertainty)

Context layer:

• Screenshot (full screen or cropped to the marked region)
• Window title (the app or browser tab where the element lives)
• URL (for web apps; read from the browser's AXWebArea attribute, not guessed from the title)
• OS version (macOS 14.6, Windows 11, etc.)
• App version (if known)

Most product feedback tools skip the element resolution layer entirely, leaving "description" as the only place to specify what you mean. That's why half your Linear issues say "the button on the dashboard" and spawn a screenshot request in comments.

How do you capture the exact element in a feature request?

The macOS Accessibility API exposes every on-screen UI component as a named AXUIElement with a role (button, text field, menu item), a label, and a frame. When you point at any UI element, AXUIElementCopyElementAtPosition returns that element's identity.

Tools that leverage this API can resolve "this button" to AXButton "Sign In" (frame: 1024,768,120,40) automatically.

Manual method (if your tool doesn't auto-resolve):

1. Open the Accessibility Inspector (Xcode → Xcode → Open Developer Tool → Accessibility Inspector).
2. Click the crosshair, hover over the element.
3. Copy the Role and Title fields (AXButton, "Submit").
4. Note the Frame (x, y, w, h).
5. Paste into your feature request form under "Element name" and "Coordinates."

Automatic method (point-and-speak):

1. Hold ⌥⌘A, circle the element, say "increase font size here."
2. The tool resolves the element, transcribes your voice on-device, and captures a cropped screenshot.
3. It writes AXButton "Submit" (confidence: 0.94) plus the spoken instruction into the form , or hands it directly to your AI coding agent over MCP.

PinVari uses the second method: you hold ⌥⌘A, circle any on-screen button or field, and speak. It resolves the named element, reads the window's full accessibility tree, and returns a structured JSON payload (role, label, frame, parentChain, screenshot) that your agent or tracker can execute on.

For AX-blind surfaces (Canvas, some Electron windows), it falls back to on-device Vision OCR and flags lower confidence.

What is the best feature request template for software?

A software feature request template that developers trust includes the resolved element, a before/after mockup or description, and the business reason. Here's a copyable starting point:

**Title:** [Verb] [Element] in [Location]
Example: Add keyboard shortcut to "Export" button in dashboard toolbar

**Category:** UI / API / Performance / Integration / Other
**Priority:** P0 / P1 / P2
**Requester:** [Name, Role]

**Element Details:**
- Role: [AXButton, AXTextField, AXMenuItem, etc.]
- Label: ["Export", "Submit Order", etc.]
- Parent Path: [Application > Window > Group > Button]
- Frame: [x, y, width, height]
- Confidence: [0.0-1.0 if auto-resolved]

**Current Behavior:**
[What happens now when you interact with this element]

**Requested Behavior:**
[What should happen instead]

**Why This Matters:**
[Impact: time saved, user pain removed, revenue open]

**Attachments:**
- Screenshot (cropped to element region)
- Full window screenshot (if context matters)
- Screen recording (if interaction is complex)

**Environment:**
- OS: macOS 14.6 / Windows 11 / Ubuntu 22.04
- App version: 2.1.3
- Browser (if web): Chrome 118, Safari 17
- URL (if web): https://app.example.com/dashboard

This template works in Linear, GitHub Issues, Jira, Notion, or any tracker that accepts markdown. The key is the element resolution block: when a developer reads AXButton "Export" (frame: 1200,80,90,32), they know exactly which button in which toolbar without opening the app.

How do you organize feature requests by category?

Group requests by surface area (UI, API, CLI), functional domain (auth, billing, export), or requester type (customer, internal, agent-generated). Most teams use a two-level taxonomy: UI > Dashboard, API > Webhooks, Performance > Database.

Recommended categories for product teams:

• UI (buttons, forms, navigation, modals)
• API (endpoints, rate limits, error codes)
• Performance (load time, memory, latency)
• Integration (third-party connectors, webhooks)
• Security (auth, permissions, encryption)
• Documentation (missing guides, outdated examples)

Tag each request with both category and priority. A P0 UI bug blocks users; a P2 API enhancement can wait.

Linear and GitHub Issues support labels; Jira has component fields. The goal is a backlog your AI agent can query (pinvari_list_requests category:UI priority:P1) without asking you to re-explain the list.

What is the difference between a feature request and a change request?

A feature request asks for something new (a dark mode toggle that doesn't exist). A change request modifies something that already exists (increasing the font size on an existing button).

The form fields overlap: both need the element, the before/after states, and the reason. The difference is in priority scoring: change requests often tie to a live user pain and rank higher.

For change requests, add a Current State section describing the existing behavior or appearance. Example: "Current: 'Submit' button uses 14pt font, hard to read on 4K displays.

Requested: 18pt font." This gives the developer or agent a clear delta.

Some teams maintain separate trackers; others use a Type: Feature / Change / Bug field. PinVari treats both as instructions: you point at the element, say "make this bigger" (change) or "add a dark mode toggle here" (feature), and the resolved payload includes the element's current state (role, label, value, enabled/disabled) so the agent knows what it's changing.

If you want the Mac point-and-speak capture that names the element, see PinVari pricing. One-time $39 launch for the first 500 licenses, then $59.

FAQ

#

What is a feature request form?

A feature request form is a structured template that captures what you want built or changed, why it matters, and , critically , which exact UI element or code path you're talking about. Good forms include the element's name (role + label), its location (frame, parent chain), a screenshot, and the business reason.

Bad forms leave "description" as the only field, forcing followup questions about which button or where in the app.

#

How do I write a good feature request?

Start with a verb-first title ("Add export button to dashboard toolbar"). Identify the exact element using its accessibility role and label (AXButton "Export").

Attach a cropped screenshot showing the element in context. Explain the current behavior, the requested behavior, and why it matters (time saved, user pain removed).

Include environment details (OS, app version, URL if web). Avoid prose like "it would be nice if" , write executable instructions.

#

What should a feature enhancement request template include?

A feature enhancement template needs the same fields as a feature request: element name, element path, frame, screenshot, window title, URL, current state, requested state, and reason. The difference is emphasis on before/after: clearly describe what the element does now and what it should do instead.

Example: "Current: 'Save' button disabled until all fields filled. Requested: enable 'Save' even if optional fields empty, show warning on submit."

#

How do you auto-populate a feature request from a screenshot?

Tools that read the macOS Accessibility API can resolve any on-screen element to its role, label, and frame. You point at the element, the tool calls AXUIElementCopyElementAtPosition, and gets back AXButton "Submit" plus parent chain.

PinVari does this via a ⌥⌘A hotkey: you circle the element and speak, it resolves the AX tree, transcribes your voice on-device, and auto-fills the request form with element_role, element_label, frame, parentChain, and a cropped screenshot.

#

What is the difference between a feature request and a bug report?

A bug report describes broken behavior (the button should open a modal but does nothing). A feature request describes new or changed behavior (add a dark mode toggle that doesn't exist).

Both need the named element and a screenshot, but bug reports emphasize steps to reproduce and expected vs actual, while feature requests emphasize why this matters and impact. Many teams use the same form with a Type: Bug / Feature / Change dropdown.

#

How do you organize hundreds of feature requests?

Tag each request with category (UI, API, performance), priority (P0/P1/P2), and element path (so you can detect duplicates). Use a scoring formula like (Impact × Alignment) / Effort to rank them.

Auto-cluster requests by theme (keyword extraction or embedding similarity) to surface when five people ask for the same thing. Store the resolved element as structured JSON so your AI agent can query category:UI priority:P1 and list every high-priority UI change without re-reading prose descriptions.