Show HN: Most users won't report bugs unless you make it stupidly easy

Hacker News Discussion ↗

Product concept and setup

  • Tool is a draggable “bug” widget users drop onto broken UI elements to report issues, sending notes plus context (screenshots, browser info, logs).
  • Integration is a JS snippet; some want it as an npm package, or as an embeddable API so they can design their own UI.
  • Several people initially couldn’t find the site or expected “.app” to be a native app extension.

UI, wording, and behavior

  • Strong praise for the “point at the broken thing” interaction; seen as much easier than describing paths and states.
  • Concerns that “bug” and “Spotted a bug?” will confuse non-technical users; “Problem” or “Issue” wording is preferred.
  • Tooltip-only instructions are fragile since many users don’t read; people tried clicking instead of dragging and assumed it was broken.
  • Repeated popups on every load may feel noisy or imply the product is buggy.
  • Mobile behavior is buggy or unclear; dragging often fails or the popup covers too much of the page.
  • Paying customers expect to remove vendor branding and fully customize icon, text, and styling.

Volume, quality, and automation

  • Many argue the real cost is triaging low‑quality or nonsensical reports; public trackers can fill with spam, anger, or “page doesn’t work” with no detail.
  • Suggestions: dual modes (quick screenshot + markup vs detailed report) and using LLMs only for semantic grouping/deduplication and escalation, not rewriting or discarding reports.
  • Others respond that this “noise” is the price of free user testing, and the better focus is increasing signal by lowering friction and capturing more context automatically.

User motivation and incentives

  • Several commenters refuse to report bugs for paid products without compensation; discounts, credits, or rewards (like free licenses) are seen as strong motivators.
  • Many report giving up on bug reporting because issues disappear into black holes, get auto‑closed by stale bots, or are dismissed as “won’t fix.”
  • Consensus: users will only invest effort if they can see status, get follow‑ups, and observe bugs actually being fixed.

Company practices, alternatives, and trust

  • Some companies and OSS projects deliberately make bug reporting hard (logins, complex forms, support-gatekeeping), partly to reduce “customer‑found bugs” metrics.
  • Others highlight positive examples where easy reporting plus quick, visible fixes created a virtuous cycle of better reports.
  • Telemetry, session replay, crash reporters, and analytics are cited as complementary or alternative ways to discover bugs, with recurring concerns about privacy, PII in logs/screenshots, and opt‑in vs opt‑out behavior.