Search for "bug report template" and you will find a hundred variations of the same form. Title, environment, steps to reproduce, expected result, actual result, severity, screenshots. Copy it into your issue tracker, and within a month roughly nobody fills it in.
This is usually diagnosed as a discipline problem. It is not. It is a design problem: the template asks a human to transcribe information that a machine already has, and humans correctly refuse to do tedious work with no visible payoff.
So this post has two halves. First, a template you can copy that is worth keeping. Then the more useful argument — which fields to delete, because something else should be filling them in.
The template
## Summary
One sentence. What is broken, from the user's point of view.
## Steps to reproduce
1.
2.
3.
## Expected
What you thought would happen.
## Actual
What happened instead.
## Impact
Who is affected, how often, and is there a workaround?
## Environment
Browser / OS / device / app version / URL / logged-in account type
## Evidence
Screenshot, recording, console output, failing request, request IDThat is the whole thing. Nothing here is novel — the value is in what each field is actually for, which is where most templates go wrong.
Summary
The most commonly botched field. A good summary is written from the outside: "Checkout button does nothing on the payment step for saved cards." A bad one is written from the inside of a guess: "Stripe token race condition."
Guesses in the title are corrosive because they anchor everyone who reads the report afterwards. Half of triage time on badly-titled bugs is spent disproving a diagnosis that the reporter invented and nobody questioned.
Ask for the observation. Diagnosis is the fixer's job.
Steps to reproduce
The field everyone knows matters and almost everyone writes badly, in a specific way: reporters write the steps they believe are relevant rather than the steps they took.
They skip "I had two tabs open." They skip "I'd been on the page for about an hour." They skip "I came in from the email link, not the nav." Those omissions are usually the bug.
The instruction that helps: write what you did, starting from opening the page, including the boring parts.
The starting state matters as much as the actions. Logged in as what? With what data already in the account? On which plan? A reproduction that starts from a fresh account frequently does not reproduce.
Expected and actual
These look redundant next to the summary. Keep them anyway.
Splitting them catches a whole class of report that is not a bug: cases where the software behaves exactly as designed and the user expected something different. That is real and worth knowing — it is a documentation bug, or a UX bug, or a bug in the sales pitch — but it is not a code defect, and it is enormously cheaper to identify at triage than after two days of investigation.
The pair also forces precision. "It doesn't work" cannot survive being split into expected and actual. One of the two boxes will be embarrassing to leave vague.
Impact
The field most templates leave out, and the one that most determines what happens next.
Severity dropdowns do not work. Every reporter picks "High," because from inside their blocked task everything is high. Ask instead for the three things severity is trying to approximate:
Who — just me, everyone on my team, every customer on Safari?
How often — once, every time, roughly one in ten?
Workaround — is there another way to get the job done?
"Every time, all mobile users, no workaround" and "once, only me, refreshing fixes it" sort themselves without anyone touching a dropdown. And "one in ten" is doing more work than it looks: intermittent means race condition, caching, or load-dependence, and that shapes where a developer looks before they have looked anywhere.
Environment
Necessary, and the single worst use of a human's time on this list. Hold that thought.
Evidence
Screenshots are the default, and they are the weakest form of evidence in common use. A screenshot proves the page looked wrong. It says nothing about why.
Ranked by what actually resolves bugs:
The failing request — method, URL, status, response body, and a request or trace ID if you have one. A request ID turns a client-side report into a server-side log search, which is the shortest path from report to root cause that exists.
The console error with its stack — points at a line of code.
A recording — shows timing and sequence, which screenshots cannot.
A screenshot — shows the final state.
Most templates ask for the fourth and never mention the first three, because the first three require DevTools and reporters do not have DevTools open.
Now delete most of it
Look back at the template and sort the fields by who can supply them.
Only a human can supply: summary, steps to reproduce, expected, and the "who and how often" part of impact. These require intent. No amount of instrumentation knows what someone was trying to accomplish or what they expected to see.
A machine can supply, better: environment, actual behaviour, and all four kinds of evidence.
Every field in the second group is a field where you are asking a person to do a worse job than a script could do, and paying for it in abandoned reports.
Consider what "Environment" really asks. Browser and exact version — most people cannot find this. OS version — same. Viewport size — nobody knows this, and it is the field that would have explained the layout bug. Page URL — they will paste the URL of the page they are on now, which is your support form. App version or build hash — invisible to them by design.
Six pieces of data, each trivially readable from the browser, each requiring a support round-trip when a human is asked to supply them.
The same argument applies harder to evidence. You are asking a non-technical user to open DevTools, find the network tab, reproduce the bug, identify which of two hundred requests is the relevant one, and copy its response. This is a request they will not fulfil. And it is one line of instrumentation.
What the form should look like
Strip it to what only a human knows:
## What went wrong?
[free text]
## What did you expect to happen?
[free text]
## Has this happened before?
( ) First time ( ) Sometimes ( ) Every timeThree fields. Thirty seconds. Meanwhile the report arrives carrying the browser, OS, viewport, URL, the console including everything logged before the report was opened, the network log with statuses and timings, a session replay of the last few minutes, and the user's clicks and inputs in order.
That is the trade the whole exercise is about: the human writes the sentence only they can write, and the machine attaches everything else.
This is what BugDump does. One script tag puts a report button on the page; the user types what went wrong; the report arrives with the telemetry already attached, along with an annotated screenshot they can blur before it ever leaves their browser. The free tier is 500 reports per project.
Two things to keep doing by hand
Automating capture does not automate everything, and it is worth being clear about the limits.
Triage still needs a person. Twelve reports of the same broken checkout should become one task with twelve pieces of evidence, and only a human recognises that they are the same bug. That grouping is where duplicate reports stop being noise and become data — twelve reports across five browsers and two operating systems is a matrix, and the pattern in it usually names the cause. BugDump models this directly: reports are evidence, tasks are the thing you fix, and many reports attach to one task.
Closing the loop still needs a person. A report submitted into a void teaches someone not to report again. Whatever tool you use, the reporter needs to see that the thing they filed moved. Give them a status page, or send them a message when it ships — a public portal where they can watch their task go from Confirmed to Done is the cheapest version of this that works.
Templates are a proxy for the real goal, which is a report a developer can act on without a follow-up question. If a form gets you there, use the one above. If instrumentation gets you there without a form, that is strictly better — the best bug report template is the one nobody has to fill in.