Show HN: Most users won't report bugs unless you make it stupidly easy
Most feedback tools are built like people actually want to report bugs. They don’t. Unless you make it dead-simple, or better yet - a little fun.
After shipping a few SaaS products, I noticed a pattern: Bugs? Yes. Bug reports? No.
Not because users didn’t care but because reporting bugs is usually a terrible experience.
Most tools want users to:
* Fill out a long form
* Enter their email
* Describe a bug they barely understand
* Maybe sign in or create an account
* Then maybe submit it
Let’s be real: no one’s doing that. Especially not someone just trying to use your product.
So I built Bugdrop.app - It’s a little draggable bug icon that users can drop right on the issue, type a quick note, and they’re done. No logins. No forms. Just context-rich feedback that your team can actually use — with screenshots, browser info, even console logs if they hit an error.
And weirdly? People actually use it. Even non-technical users click it just because "the little bug looked fun."
I didn’t want to build another "feedback suite". I just wanted something lightweight, fast, and so stupidly simple that people actually report stuff. If you've ever had a user say “something’s broken” and then ghost you forever, you probably get where I’m coming from.
What I’m most proud of? People are actually using it. And their users? They’re actually reporting stuff. Even non-technical ones.
Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects. Not trying to sell you anything — just sharing something I built to scratch my own itch.
If you submit a really detailed bug report, such as one where the problem was reproduced under a debugger, it becomes a "the reason you suck" speech. This really upsets some dev teams. The usual responses of the "turn it off and on again" and "reinstall" don't make the complaint go away.
There are two bugs in Firefox I'd like to report, but it's futile. One is that, launched on Ubuntu, Firestorm does disk I/O for about three minutes on launch. During that period it can't load complex pages, although it loads ones without Javascript fine. The other, again on Ubuntu, is that it freezes when large text boxes are being filled in. This only happens on some sites.
FYI, there’s a bug with the bug, it doesn’t move on mobile
The problem with bug reporting is that they rarely seem to get fixed. I used to do a lot more bug reports. But you often hear back nothing, and then the bug is never fixed, even if it would be an easy fix. These days, I don't often report bugs.
Some teams have a frickin' bad attitude and couldn't care less. Try submitting a bug about how menus are displayed 5px from where they are supposed to be in a GTK app rendered on a X11-server that runs on the Windows desktop and see if the GTK developers care. Or try telling the react-testing-framework folks that they're asking me to put handrails in my bathroom when my house is burning down. Have experiences like that and you'll conclude it isn't worth filing bug reports.
Now the linux-industrial complex is a special case, if you are a software engineer and know how to isolate a problem and submit a great bug report you will often hear from people who will say you sent them the best bug report all quarter. It helps if the team is working with web tech, younger, more diverse, and never heard of the GPL.
The devs for the game factorio encourage players to post bugs on the forums. The devs use forums as a issue tracker and respond to bugs with fixes. I have no idea if that makes it more satisfying to report bugs or not, but I always thought it was cool.
I would defibitely file bugs with factorio because of the devs, but never found any. Truly amazing game.
Transparency in the form of a public ticket tracker would solve that.
> screenshots, browser info, even console logs if they hit an error.
Possibly disclosing sensitive information (which the user may not realize).
The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports, or the "my neighbour is a spy for the government and I have proof" reports (real types of reports for a browser company, for example, which surely exist for other places users think that "is" the internet like Facebook).
I agree that reporting bugs can be hard, but the amount of spam that follows an effective open form, of craziness to uselessness, outweighs the useful bug reports.
Having two types of reports: one which is a simple screenshot taker with the ability to draw a circle over what is wrong, and one which is a more detailed report, would be useful.
Some LLM that filters out what is a useless report be a useful report would be good, too.
With all due respect, That is the price you pay for your users doing _free_ software testing for you! We are on the “listen to your users” mecca and you’re complaining that listening to your users is hard and you wish a machine could help you with it.
> you’re complaining that listening to your users is hard and you wish a machine could help you with it.
That's entirely the wrong take, IMO.
Listening to users is easy, but the users often don't say anything when they speak. Those non-reports are basically spam that should be automatically thrown away.
When a mozilla application crashed it'll ask you to leave a comment to try and help resolve the issue when it prompts to send crash info, and you used to be able to see all those comments on https://crash-stats.mozilla.org (it seems to be behind login or restricted access now). There was a lot of vitriol and unhelpful comments that any developer would need to wade through to get to anything to give them a lead
>for your users doing _free_ software testing for you!
In comparison to _paid_ software testing, which doesn't change the point at all: if they were paid to find bugs, they wouldn't be paid for useless and unactionable reports.
>you’re complaining that listening to your users is hard
Sometimes - and I'd wager most of the time - they are, yes, unless your product solely attracts technically competent and advanced users that can attempt to understand/reason about what is causing the issue.
On the LLM idea, if you could group reports by issue (by parsing the user provided input and whatever context you save from the page screenshot into some embedding) and then only escalate things when several different IPs have reported a similar thing within X amount of time, I think you could handle two birds with one stone. Limits how annoying spammers can be, and also makes the good reports easier to understand since a few bug reports combined should make a better whole.
I however wouldn't shorten/transform reports with an LLM, or make spammy reports inaccessible. Just doing the semantic grouping for escalation. It's true you're getting free work from your users, and the human factor is pretty important here, even if an LLM might sometimes misinterpret it.
> The difficulty in reporting a bug comes from the friction required to filter the "page doesn't work" with no further explanation reports
This so much.
I can't tell you how often I've seen someone trying to get tech support on something say "When I load the program, I get an error" but don't even say what the error says. I understand that most people have never worked a QA job and so don't know how to write a good bug report, but certainly I would expect someone to copy/paste the error message.
Reporting bugs is work, and is a two-way street: if submission is a black hole (possibly with some scripted replies from someone uninvolved in fixing bugs), then bugs will not be reported.
Any involvement in reporting / fixing bugs is development. Why do app developers think their customers need to be or want to be developers?
What other industry relies on its customers as implicit developers?
Making bug reporting easier means an intentional push to foist more of Development's work upon customers and a bias towards more bugs.
BUG OR FEATURE?
If you can't tell, then we can understand why Knuth call it "the art" of computer programming, as in the artist's uncertainty of creation as compared to the engineer's confidence.
The fact that half the SW industry prefers to avoid a distinction between bugs and features— as in bugs that don't get reported are regarded as features— shows the profligate laziness and opportunism of so called Software Engineering.
AI is a stunning example of a global industry built by computer technologists who don't care about understanding their own work, and lack the creative and social spark to conduct themselves as artists.
Just listen G. Hinton babble philosophically for 10 minutes and you will grasp the magnitude of incompetence at work.
For many corporations, there are probably perverse incentives against making it easy to report bugs.KPI of reported bugs as an indicator of software quality, for example.
Certainly seems like there must be some KPI against fixing the bugs. You can look to any big tech software and find oodles of long standing bugs which never receive attention.
It's not just a problem in the corporate context. Open source projects usually make it a pain in the ass to submit bug reports too, in a clear effort to gatekeep the process to experienced developers. Simply because developers prefer to only deal with other developers and don't want to hear complaints about their software from the unwashed masses.
Just this week I was working on something similar but specifically for users who have disabilities, so they can more easily report issues to site owners. I also combined general annotation capability so other users (of my browser extension) can read their comments. And also compatibility with Hypothesis (https://github.com/hypothesis, https://hypothes.is), also using the W3C Web Annotation spec. I hadn't thought of the drag-and-drop bug metaphor; I like it. I had also considered recording mouse and keystroke events up until the time that the bug is marked, and then bundling those events (sanitized) with the bug report for more precise repro steps, but of course that's a bigger ask for the opt-in.
Bugdrop won't work for most users, since they don't real tooltips.
1. I load https://bugdrop.app/
2. The site days 'try bugdrop' and points to the left bottom corner.
3. I click the bug. Nothing happens.
On further inspection, there is sometimes a tooltip that tells me clicking won't work and I need to drag the bug over the part of the UI that failed, but I didn't read that when I first used it and I won't use it a second time.
I love this. Especially the sane pricing.
Only thing I would add is after submit it should allow you to enter an email address or something so that (a) the user can get updates on the progress of fixes; and (b) be contacted if the dev needs more info.
I love the UI concept. Being able to point at a broken thing rather than try to uniquely describe the position/state/path to a broken thing is smart!
Hooooever, "bug" could be a bit ambiguous to a lot of people. Looks like in a real deployment, you have a little tooltip that says "Spotted a bug? Drag me there!". That makes sense to developers and the like... but those are also the sorts of people most likely to write a good bug report anyway. The people most unlikely to write a bug report are the sorts of people who will read "spotted a bug" as "there is an insect... game?... on this site?".
"Issue" or "Problem" would be better, but keep the bug graphic! It's cute. :)
When I took a look quickly, it also shows the "Spotted a bug? Drag me there!" every time the page loads - which could quickly get overwhelming, and make the user wonder why the developer is so certain that they will run into a bug. (Why do developers not make "report a bug" obvious? Because just seeing it implies there are enough bugs that a link is necessary.)
I also have no idea how well this works on mobile - and seeing that the Pro plan doesn't remove attribution seems like a mistake.
The most I have tried with reporting bugs in a mobile app is going to settings and seeing if there’s a bug report button or something like that. Not worth the effort considering the low probability of it being even looked at.
Congrats on shipping!
Here's some quick feedback -- hope it's useful:
1. Is the little bug icon sufficiently visible? I'm not sure...
2. Do visitors automatically know what to do with the bug? You have a tooltip, but do all visitors know what "Spotted a bug?" means?
3. [more of a suggestion; perhaps it does this already] Would be great if the bug position pulled in a CSS class or the content surrounding the "dropped" bug -- to give more context to the site owner.
Or just use post hog or clarify to have sessions and check them? That helped me to find bugs without reporting.
The other method I used is to have audit logs, identify when there are errors in certain steps.
Nature takes the path of least resistance. In my experience, especially people. Make it easy people will use it, make it difficult and they won't.
It's the reason apple became apple, even though I don't think the iPhone is intuitive today.
> Make it easy people will use it, make it difficult and they won't.
It doesn't have to be difficult. It just has to be not easy.
Kindle made it easy to report errors in ebooks, but I always found myself wondering if the errors I was flagging were even being looked at.
What made you go with this design choice instead of Google's "Feedback" button that lets you take a screenshot?
I won't report bugs in paid software/services because it's not my job, I'm not paid for it, I'm user of the service, not free workforce so they can reduce amount of QA staff or skip it completely. Give me a discount and then maybe, just maybe I'll think twice about reporting something. Bugs renders your soft unusable? Fine, there is plenty of competition out there who will do it right.
A clickable link with a form (partially pre-filled) and a big banner that says if the bug is verified I get 10-25% off something AND a followup email (reiterating the offer) + tracking link, would motivate most people I know.
> because it's not my job
I've worked with people who uttered this phrase many times. You really should put this on your CV because it's an incredibly helpful indicator of character trait.
So you:
A) only pay for perfection and
B) experience zero friction or cost in moving services?
I think trying to argue with the sentiment, misses the point entirely. I think we can all agree, bug reporting could use a renaissance.
So instead of getting a fix, you'll choose to be angry.
It is an approach, for sure.
I tell my customers that they should spend 1hr per month “improving the vendor”.
See, if you rely on a vendor, then you need them to survive. It’s a parasite-host relationship. You need to tell them what you need, and oftentimes they will bend the roadmap in favour of the most demanded features. Alternatives:
- They choose their most amusing feature,
- They choose the most lucrative feature among the new possible markets while ignoring all bugs, which is the most rational way to address bugs unfortunately,
- You don’t tell them, they don’t improve, they die / they triple the price of the product by lack of audience, and you have to migrate your data to another product.
Nice, I hope you are spending 1h per month for each customer as well advising them how the can get the most out of your service and/or improve their integration - otherwise it would seem like you are expecting unpaid work from your customers, which is ridiculous.
This sounds neat! Do you have a site that describes how it's added to an existing project?
Not OP but, the website is bugdrop.app
FAQ says "The Bugdrop snippet is tiny and loads asynchronously"
So, you add a snippet of JS to your site.
Not a fan of made-up testimonials, but otherwise it looks nice. How do you prevent spam?
I imagine it's been quite difficult to educate users to use this tool?
Love this! That said, wanted to try it on your website, can't report a bug that the bug reporting doesn't work on Safari MacOS... the submit button does not do anything.
Seems it needs some text to submit ( and entering just spaces doesn't count ) - ideally the Submit button shouldn't enable until there is valid text?
There's the other side of the coin of reporting bugs besides initial friction: if the user feels like the bug reports end up in a black hole, then they will disincentivized from doing so.
What happens after the user files a bug from their point of view? Is there a follow-up, or is it like throwing a message in a bottle?
Okay but what have you built?
Why not a video snippet? Why a note?
Here's a quick bug report: I didn't know how I can check out the app you built. There were no links in your post. Only "Bugdrop.app", the name. I tried Googling it and it turns out Bugdrop.app is your actual domain. You should point that out: Bugdrop.app => https://bugdrop.app/
On macOS .app is the standard extension for any installed app.
this sounds like a vital improvement.
Every bug I encounter in my favorite game I do not report because they want:
* My email, yet again.
* A long form
* A bug description rather than a narrative of what I experienced
You write that "reporting bugs is usually a terrible experience". I find bugs ALL THE TIME, and yet, when I even try to find a way to contact ANYONE, let alone a developer, they leave no door open at all. No method, no form, no contact name, no nothing. I (along with many, I presume), actually want those companies to excel. I WANT to let them know what to fix. But, they just don't want to hear about it. Really sad I think.
In my experience it's because the companies have not hired any persons whose job is to triage bug reports. People do find bugs all the time, and making it super frictionless to report bugs will result in a deluge of reports. Some reports will be outright spam, some could be mistaking a feature for a bug, some could be duplicates. Someone needs to do the triage and try to reproduce before the issue is forwarded to developers. Few companies have the role of Quality Test Engineer (QTE) to do this job; most don't so they have no means to triage the bug reports.
The only exception is indie apps I pay for on the App Store. There is usually only one or perhaps two people behind it, so by definition that person is SWE, QTE, PM and several jobs rolled into one. And this is unsustainable unless the app is paid.
Wait... Isn't that what AI is for? To do that for "free" and removing the time an actual person has to spend on it? Separating the spam and duplicates, etc?
The difficult part is the step of reproducing the bug. Will companies trust AI enough to allow the AI to operate on their UI, according to instructions written by bug reporters who are strangers on the internet?
I think if you take for example apps on the Atlassian Marketplace, probably all of them have an easy way to contact them (Probably because they get Jira for free, granted).
I develop for iOS and Android. All my apps have a Send Feedback button which opens an email in the user's default email client with my address in the To field, pre-filled subject line and some diagnostic info in the body (things like version number, device type, iOS version etc). I get all my bug reports and feedback that way and respond to them via a reply email when I have released the update to fix it.
I had really simple feedback form in my Android app that was just text area and submit button. Then some ashole tester from Google put @ in it and suddenly I'm collecting PII. It was easier to just remove the feedback form.
And that is why companies use telemetry. As privacy advocate I still let telemetry to be collected as long as it is transparent. And I can filter it if there is something too disturbing.
[dead]
[dead]
[flagged]