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

I use to report bugs all the time with details of the bug and what I was doing and if possible how to cause it. But then when you encounter the same bugs years later doing some very common task that you momentarily forgot to do your work around for, it made me wonder why I was wasting my time reporting it. These days I rarely report bugs unless it is brand new software released a few weeks ago at most, or a brand new release of older software with a new bug. If something isn't completely breaking the use case of a program, or doesn't have any viable work around, I just don't expect it to ever get fixed. So why waste the time? Im not getting paid for it, it likely won't be fixed, and 49/50 bugs I encounter are things that seem impossible to miss with any real QC.

Doing decent bug reports as a user most of the time it feels like following the turnip truck to town picking up turnips that fell off the truck, giving them to the farmer, but knowing they will likely be thrown in the trash because they didn't care about them to start with. If they did they would have made sure to not overload the truck to start with and not be obviously dropping so many turnips on the side of the road and leaving them there.

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.

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.

Most companies don’t have a user accessible way to file bugs. Often, you have to call support, speak to a muppet, then convince them that your issue is real and they’ll file it. Trust me, I find bugs in products all the time and I actually try to file bug reports, but it’s rare that I can.

Some of this is because one of the worst bug-related metrics is “customer found bugs.” This means that your developers missed it during unit testing and your test team missed it during system and final testing. Nobody actually wants customers to be able to file bug reports because they make the team look bad.

> If you've ever had a user say “something’s broken” and then ghost you forever, you probably get where I’m coming from.

As a consumer who reports bugs, I’d actually say the opposite problem is just as common — when the company ghosts you after you’ve taken the time to report an issue.

I’ve lost count of how many times I’ve used the official channels — bug trackers, support forums, contact forms — only to hear nothing back. No acknowledgement, no follow-up, no notification when it’s fixed. Honestly, I don’t think I’ve ever had a company let me know that a bug I reported was resolved.

Reporting a bug to most companies feels like sending a wishlist to Santa. That’s why many people don’t bother. They assume it’s a waste of time — and most of the time, they’re right.

Personally, if a company fails to engage over a bug report, I don’t waste my time reporting anything else. In many cases, I just move to the competition. I’m sure I’m not alone.

If a user goes to the time of helping you fix your software, the least you can do is spend some time on them.

The response is usually the problem.

If I file a bug I get either:

1) nothing

2) a reasonable response that may or may not include resolution

3) a shared debugging journey that takes three hours of my life

Number 3 devs mean well and have admirable commitment…but I’d rather not sign up for an epic trek to throw a ring into mountain doom. I just want to point out an issue and provide some basic info.

So these days the only thing I do for the most part is send crash logs.

I don't know if this is the case now, but about a decade ago, in order to report a Bug to Microsoft you had to create a Premier Support ticket, which cost $1000+, but free if it's a Bug. So basically, if what you report is not a Bug, determined by them, it's treated like a Tech Support ticket and no longer free. I recall discussing this with a representative and let them know that I'm basically doing them a favor by reporting the bug -- why would I want to take the chance to possibly have to pay for it if they happen to determine "it's not a bug -- it's a feature". I got the standard corporate-speak answer which I just waved off as ridiculous: "Look, we will absolutely not charge you if it's determined to be a bug"... :|

I've since have seen Microsoft use User Voice and the products (at least Visual Studio) has a great way to give feedback to the team, something I've used multiple times, including for feature requests. And of course, for their Open Source products, they have Github Issues, which is awesome.

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.

I had a lot of success adding links and buttons to report bugs on error pages and messages. Doing that while whatever abnormal state led to the message is still hot allowed me to gather a lot of information about the state of the application to be attached to any bug report. Initially I used the Macintosh bomb icon for it, but some users found that too cryptic compared to a text message.

“Stupidly easy” is bad copy imo. I honestly did not want to scroll through the front page after seeing it. In a sentence it does not have nice flow and from a business perspective it feels immature. I would tighten up that copy a lot but that is just my opinion. Also, might be in the minority but I avoid any products that put ProductHunt flags on the page, especially prominently at the top.

A couple of years ago I played PUBG which crashed occasionally. I rarely submitted bugs, even if it was as simple as pressing a button in the crash reporter. This is because sending the bug report took a while and blocked you from restarting and rejoining the ongoing game. This applies mostly to multiplayer games but if your app has a crash reporter, give the user a chance to restart the app and report the bug later.

Maybe adding a clickable/highlighted actual url in the post to make it more stupidly easy to go to your website, if not on the title itself (not sure if you can add that now) could also be a good idea. For stupid people like me that spent more than 10 seconds after reading it trying to figure out where I should click.

Totally get this. I once spent days trying to get users to submit decent bug reports through a fancy form and got almost nothing useful. The moment we switched to a simple “click here to report” button with an optional note field, the volume and quality went way up. Simpler is better, especially when the user is already frustrated.

In 2022 and 2023, I made a push to find and fix bugs in OpenZFS using static analysis tools. I found many obscure bugs. One was a theoretical issue that should have affected big endian systems and been an annoyance for users, but there were no bug reports saying anyone had been affected. After I opened a PR with a fix, people told me that they had been affected, but did not think it was worthwhile to file a bug report. This surprised me. This is the PR:

https://github.com/openzfs/zfs/pull/13968

> screenshots, browser info, even console logs if they hit an error.

Possibly disclosing sensitive information (which the user may not realize).

Really excited to try this.

1) I'm surprised to not see the bugdrop feature in the admin section, which means I currently have to report the bug here :-)

2) I was also surprised that it didn't seem to need to confirm my email, seems standard these days.

Otherwise, stoked to try this. I already reported a "bug" on your front page and it went very smoothly.

3) Didn't receive an email receipt confirming that the bug was reported after I had entered my email, not sure if that's planned or not.

Thanks!

When I encounter a bug, I will almost never report it either, I’ll hope that someone else will or the developer will notice themselves while using their product.

Reporting a bug is work. If it is certain that the bug will be fixed upon reporting this work may be worth doing for selfish (or non selfish) reasons, but I almost never have confidence that it is.

> Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects.

Maybe people could combine this reporting solution with a bug capture solution I built a few weeks ago? It's a web-based screen recorder which allows a user to gather together several different areas of the screen into one place, add a talking head of themselves and demonstrate/explain the problem they've encountered. The resulting video could be added to the bug report. I built the tool because showing the problem is always better than trying to explain it in words.

Tool: https://kaliedarik.github.io/sc-screen-recorder/ GitHub repo (it can be forked, self-hosted, etc): https://github.com/KaliedaRik/sc-screen-recorder

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.

Yes! Similarly for text books, which are riddled with errors, generally speaking. They should have have an email address for reader-submitted errata printed in large friendly letters on the inside front cover.

The first job I had as a software engineer was at a trucking company that had a desktop Swing application. If an exception happened, the user would get a pop-up with buttons to email support the stack trace or cancel. The email went to all the IT staff and someone would usually reply within an hour, often with a fix.

The engineering work was atrocious looking back. I probably fixed 50 random NullPointerExceptions in my 3 years there this way. But, it was one of the most productive places I've worked at because everything was done simple and there were no barriers between users and developers.

Because it is an extremely futile exercise.

I have a bug in my Honor (200 pro) phone were after some time, whatsapp's notifications with no sounds are changed by the SO automatically to Gentle Notification (no popup, only number on icon) I want to have a popup, but without sound. I might have reported several times, well, they have not done anything about it.

I also reported something to Lutris just to be told, not our problem wont fix. which is the same feeling of, why have I bother doing this.

And after a few of those, if you have a bug, you moved on. In this case I regret going with Honor instead of Samsung, and it would be likely the last Honor phone I got and I do not recommend to anybody. And with Lutris, I would rather use windows and be able to see my screen instead of a black box when logging into epic.

If you don't fix the bug, the user will stop reporting, and will find a workaround.

Sounds like a great idea.

I have found that users don't give feedback, positive or negative, until they encounter some extreme (usually negative).

I have found the best way to encourage feedback, is to make it dirt simple. Just a text entry field, with some way to respond, so you can follow up.

Most of the work needs to be on my end.

I really like how some indie games have put in a widget for feedback. Press F11 or something, click an emoji face, optionally add a description, and click send. The game takes care of sending a screenshot, game state etc. (It tells you it's doing this in the interface)

Not potentially a customer because I have very few users that I can track if one of them have issues. So take my suggestions a bit lightly

1. I'd rather have/use a npm package then your minified/package script. You are not Google, so I am going to need some trust there and that happens by making this an open source package.

2. If I am going to implement this on my site, I'd not use that little bug. I'd rather have this custom design/integrated with the rest of my app. So provide API/functions/Hooks to use your library.

3. I'd never consider a one time payment (lifetime subscription) SaaS. That screams: I am going to take your money and disappear in a few months. Also, any product that doesn't have clear bandwidth quotas is probably missing in disclosure.

Same with engineers working on the code. Track issues in GitHub? They'll write bug reports. Track issues over in Jira, they no longer care enough.

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.

Testing bugs is your full time job. Why should I spend my time doing it for, at best, free, but more likely pay to do so? And even then, the bug is almost always closed without fixing anyway.

For me the most fatal part of the big report loop is where you report a bug, and get radio silence, or a curt dismissal, and the bug lingers on.

Telegram for MacOS has a bug where it will occasionally crash when you try to delete something. I reported it nearly 2 years ago. It's yet to be fixed

On the flip side, I got some of Fireboard's pulse probes last year, and had an issue where they wouldn't connect to my Yoder smoker. Quick ticket and some easy debugging steps I was able to do more or less asynchronously, and a cause and fix was found: the Bluetooth stack on the smoker would crash after a while, so unplugging the smoker when it wasn't in use was an easy fix. The bug still remains in the firmware, but there is a solution that works for me, and so I'm happy with a functional product, while I wait for the firmware update

I'll report bugs, give details — via multiple cumbersome steps, iff I can clearly track the status, follow up. Otherwise, even a one-click “send report”’popup isn't worth my effort. This is why I no longer bother reporting anything to Apple. Same crashes/errors keep on for years. I’m convinced those reports go to /fruit/null.

JetBrains does a great job with this by actually rewarding users who report bugs with free licenses and such.

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.

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.

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.

Your product is similar to one I own. I checked out your website. It’s good.

Unsolicited advice: you gotta charge more for this product. A lot more.

We charge up to $250/month or $3000/year. Some customers (companies you’ve most likely heard of) pay that, yearly in advance and have done for several years.

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. :)

This is a huge problem in Apple iOS land where the only way to leave feedback and tons of apps is to leave a review on the app store and then watch Apple delete it immediately

I strongly recommend going a lot less heavy on the LLM generated writing on HN, it reads far less genuine than when people here right stuff themselves.

Just in case you think it's the em-dashes that do it, it is isn't; it was clear by the end of the 2nd paragraph.

FYI, there’s a bug with the bug, it doesn’t move on mobile

> Even non-technical users click it just because "the little bug looked fun."

So you want non-bug reports from non-tech people. Why?

From my experience, exactly those reports are the ones that will never be addressed.

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.

The first job I had as a software engineer was at a trucking company that had a desktop Swing application. If an exception happened, the user would get a pop-up with buttons to email support the stack trace or cancel. The email went to all the IT staff and someone would usually reply within an hour, often with a fix.

The engineering work was atrocious looking back. I probably fixed 50 random NullPointerExceptions in my 3 years there this way. But, it was one of the most productive places I've worked at because everything was done simple and there were no barriers between users and developers.

Built in fun mini game: How far can you get the bug to move (only counting after you release your mouse) without the popup appearing. Multiple clicks are allowed.

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 confirm, I do it myself. but 90% of my submissions do not result in any response.

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.

Not a fan of made-up testimonials, but otherwise it looks nice. How do you prevent spam?

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.

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.

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.

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?

Great idea, not working on iOS Safari.

This sounds neat! Do you have a site that describes how it's added to an existing project?

This looks like bugherd.com

I imagine it's been quite difficult to educate users to use this tool?

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?

I love this, and I'm so glad it has resulted in more people filing bugs. That said, there is a larger problem going on here that has yet to be addressed by the software industry as a whole. And that is that "bugs" (and "filing" bugs) is a very complex thing. It's not just one thing, it's many, many things. And until we face that and provide a holistic solution for "it", it will continue to be an existential problem.

Here's a selection of the different kinds of complexity with "bugs":

- Type. Is it a backend or frontend bug? A network bug or an infrastructure bug? An internal or external bug? Is it a "not considered a bug" bug? Is it a bug in documentation, training, intuitiveness, etc? A product- or feature-specific bug? A location-specific bug? A user-specific bug?

- Context. Is the user even capable of giving you enough context and information for this bug report to be usable? If so, is automatic? If not, will the user simply give up reporting when this becomes difficult?

- Communication. How does the user even report a bug? (I regularly try to file bugs with every tech product I use - because they are constantly riddled with end-user bugs - but I spend hours trying to dig up some way to contact the company to report the bug, and when I finally can contact someone, they refuse to even take my bug report, because it's not one of the read-from-the-script-customer-service responses/actions. And if the user does eventually get in contact with the company, is the developer (or anyone else) even capable of communicating with this user to get more information or inform them of a fix?

- Visibility. Quite often, users will experience bugs, and maybe one report comes in about them. This is then captured by customer service or someone else, and maybe they file a ticket. But then for each subsequent request, they just tell the customer they will record it and then.... don't send it to anyone, because they've already sent one such bug and assume it's being fixed. So the developers have no idea how often this bug is actually happening. Often when bugs are reported the devs aren't informed at all.

- Impact. Is it just affecting a single user, once or twice, in a niche setting? Is it affecting the same user all the time? Is it affecting a subset of users? All users? Is it affecting all users, but core functionality still works? Is it significantly affecting core functionality? Is it affecting core functionality but there's bigger issues going on so it's actually less of an impact? Are the developers even capable of understanding the impact? (how many of you know exactly how much each specific function affects the business?)

- Prioritization. We all have ticketing systems full of hundreds of tickets that sit in the backlog never to be fixed. They're annoying, or difficult, or unsexy, or they're not a new feature. Sexy bugs get prioritized, unsexy bugs sit in the trash heap.

- Fixability. Even if all of the rest is provided for... how difficult or easy is it for a developer to fix? Is the developer capable of contextualizing it and making use of the information? Do some of them have difficulty reproducing it, while others don't? Do they have all the training needed on all the systems involved in order to effectively triage/investigate/troubleshoot? Are they given dedicated time each development cycle to fix bugs? Are they even able to track down who is responsible for "fixing" the bug, what with the modern mess of interdependent microservices and siloed development teams? Will they be implementing regression tests to make sure it doesn't come back? Are you rewarding them for this work, in addition to the rewards for "sexy work" (new features implemented, cost saved)?

Yes, getting users to file more bugs is fantastic! But that is quite literally the tip of the iceberg.

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.

This looks an awful lot like all the "contact us" forms that are mostly broken and give you no feedback as to whether the message got through or not. At least it's easy but you can bet half the sites that use it won't even be receiving the reports, let alone acting on them.

In my desktop app, I ask users to email me in a global exception handler. My thinking is that they'll recognize that I don't want to be inundated with reports for the same bug over and over so they're probably the first to find it and it's worth reporting. And I do fix them all otherwise I would be getting spammed by the same reports over and over again.

Okay but what have you built?

> * Maybe sign in or create an account

If you want bug reports, don't do it. Have an email address when one can submit bug reports.

I think it's cool you built and shared it - grats on shipping.

But you (or your users) are about to learn a few truths about bugs and users :)

Foremost: unless your users pay for the product, there's a downside to easy bug reports - the vast majority will be useless, no matter how easy it is. Granted, that's true for paid products too, but at least you can bake the cost for dealing with that into the price of goods.

It's absolutely great while you're building traction. Even the most inane post has usually a kernel of truth. It's becoming a problem as you are clear on where you're heading, and the cost of dealing with them outpaces their value.

At that point, you either start stochastic sampling (annoying your users who write well thought-out reports, and who are your multipliers), or you spend a fortune to slog through everything. That's when you start writing the "feedback suite" backend :)

I agree. Bug trackers should be easy to use. I wish Debian and ffmpeg would have better bug trackers.

Working at google taught me to not bother. An android bug I filed the month that I joined was closed a part of "bug bankruptcy" seven years later, having never been triaged. Why bother? When I was quitting - a year after that, the actual bug still existed.

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.

The worst example I ever experienced was finding an actual flaw within some software with Trac as a version control system - somehow DD-WRT comes to mind - and I submitted a bug report with full reproducibility workflow and everything I could imagine. Essentially, the platinum standard for submitting a bug report in software development.

It was immediately rejected.

The reasoning? “Did not identify the relevant code in which the error occurred”.

Like… WTF????

Edit: confirmed as DD-WRT. I’ve never submitted another bug report to them again. And I’ve submitted hundreds of reports to other projects all over.

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.

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]

[dead]

[flagged]