Every team has a Slack thread that looks like this. Someone pastes a screenshot of a page with a red circle drawn on it. Underneath, it says "this is broken." Then the questions start.
Which page was this? Logged in or out? Phone or desktop? What did you click before it happened? Can you check the console? Does it happen every time?
By the time the answers come back, it's the next day, the person who reported it has moved on, and half the answers are guesses. The bug might get fixed. It might get closed as "can't reproduce." Either way, two people just spent an hour doing a job that software should have done in a second.
What a developer actually needs
A screenshot shows what something looked like. A bug report explains why it happened. The gap between the two is almost always the same handful of facts:
- Where it happened. The exact URL, including query strings, and which element on the page.
- What it was running on. Browser, version, operating system, viewport size, and pixel ratio. A layout bug at 390px wide is invisible at 1440px.
- What the page was saying. Console errors and warnings from the moments before the report. A failed request or an uncaught exception often explains the bug outright.
- How they got there. The clicks, scrolls, and inputs that led up to it. "It broke" is a symptom. "It broke after changing the quantity to 3" is a reproduction.
- What they expected. The one thing only a human can supply: what should have happened instead.
Notice that only the last item needs the reporter at all. The first four are facts the browser already knows at the moment someone notices the problem. The trouble is that we ask people to collect them by hand, after the fact, from memory.
Why people don't include them
It's tempting to blame reporters for vague bugs. But think about who is reporting. A client reviewing a staging site. A marketing lead checking a landing page before launch. A customer who just wants to finish checking out. None of them should need to know what a viewport is, let alone open DevTools.
Even engineers skip the details when they're in the middle of something else. Filing a thorough bug takes five minutes. Ignoring it takes zero. So the report that arrives is the one that was easy to make, which is a screenshot and a sentence.
The fix isn't training people to write better bug reports. It's making the easy report and the complete report the same thing.
Capture context at the moment of noticing
The best time to capture technical context is the instant someone notices a problem, while the page is still in the broken state. That's the idea behind dropping a dot directly on the page. The reporter points at the thing that's wrong and writes a note in their own words. Everything else gets attached for them:
- An annotated screenshot with the dot marking the exact element.
- The page URL and the element's position, so you can find it again.
- Device and browser details, including screen size.
- Recent console output, warnings and errors included.
- A session replay of the moments before submitting, so you can watch what happened instead of reading about it.
The reporter does the human part. The browser does the rest.
A quick test for your current process
Pull up the last five bugs your team closed as "can't reproduce" or "works for me." For each one, ask which of the five facts above was missing. In our experience it's rarely a mystery. It's almost always the environment or the steps, and both were knowable at the time.
Then look at the bugs that got fixed fastest. Odds are they came from someone who happened to include a URL, a browser, and a console error.
Where this goes next
Good QA isn't about finding more bugs. It's about shrinking the distance between "someone saw a problem" and "someone understands the problem." Every question a developer has to ask is a round trip, and every round trip is a chance for the report to die.
This is the first post in Feedback Loop, our Friday series. Over the next few weeks we'll be writing about feedback loops, how AI-assisted development is changing what QA looks like, what modern sites need from a feedback tool, and why reports should land in the tools your team already uses. On Wednesdays, Field Guide covers the practical side with checklists and how-tos. If there's a topic you'd like us to dig into, let us know.
In the meantime, the next time someone sends you a screenshot with a red circle on it, you'll know exactly what's missing.