A bug report without the environment is a story about a bug.

Four questions, one structure

Everything else is a nice-to-have. A report that answers these four can be triaged by someone who was not there, which is the only definition of an actionable report.

<form action="${host}/f/FORM_ID" method="POST">
  <label for="actual">What happened?</label>
  <textarea id="actual" name="actual" rows="3" required></textarea>

  <label for="expected">What did you expect to happen?</label>
  <textarea id="expected" name="expected" rows="2" required></textarea>

  <label for="steps">Steps to reproduce</label>
  <textarea id="steps" name="steps" rows="4" required></textarea>

  <label for="env">Browser or app version (optional)</label>
  <input id="env" name="environment">

  <label for="area">Area</label>
  <select id="area" name="area" required>
    <option value="">Choose one</option>
    <option value="billing">Billing</option>
    <option value="forms">Forms</option>
    <option value="reports">Reports</option>
  </select>

  <button type="submit">Send report</button>
</form>

Collect the environment, do not interrogate it

Asking someone to find their browser version is friction in exchange for a value that is recorded anyway. What the form should ask is the thing only the reporter knows: what they were doing, and what they expected. Everything mechanical — referring page, device type, time — arrives on the record without a field.

Route by area, not by reporter

A single bug inbox becomes a triage meeting. A route rule keyed on an area field sends the report to the person who owns that part of the product, and the area field doubles as the severity signal when the same area fills up.

The report is not the fix

A form record is not an issue tracker. Its job is to capture the report reliably and get it in front of someone; the tracker is where state lives. Export or forward the report into that system, and do not expect the form to be the place where a bug is discussed.