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

[lakshikag]

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.

[AngryData]

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.

[handsclean]

It depends on the company. I’d never dream of reporting a bug to Apple, they don’t care. I think your turnip truck analogy applies there. On the other hand, iA Writer consistently replies thoughtfully and usually fixes the bug.

It’s so important to treat companies individually instead of just according to some blanket impression of the world. Individual treatment means good companies benefit and grow, while blanket treatment actually actively rewards bad behavior: a company that invests in quality will bear the cost while you share the benefit with the competition, while a company that treats you worse will reap the savings while you take out your frustration on the competition, too.

[selcuka]

> 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

Yep. That has always been the general industry sentiment [1]:

> Here’s another bug that’s not worth fixing: if you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn’t even use large files. Well, don’t fix it. Worse things have happened at sea. Similarly I’ve generally given up caring about people with 16 color screens or people running off-the-shelf Windows 95 with no upgrades in 7 years. People like that don’t spend much money on packaged software products.

[1] https://www.joelonsoftware.com/2001/07/31/hard-assed-bug-fix...

[pavel_lishin]

I've reported bugs in a few projects. In my experience, the smaller the team behind the software, the more likely your bug will be fixed.

I think I've reported bugs to Bloomz (the awful communication app my school uses), jpmonette/feed (the node/typescript RSS feed generation library), and I think at one point I reported one to Newsblur, and they all got fixed.

[_345]

Yeah... unfortunately this is how it is at my company which is a startup, I reported so many bugs that just got ignored and it can be demotivating to see the same bugs still in our app months later that could've been fixed in 15 minutes

[vonunov]

I've had the opposite experience reporting a bug on Telegram. But it was a particularly thorough report (windbg and all) and if that's what makes the difference, it seems like an unrealistic thing to expect of most users.

[D13Fd]

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.

[PaulHoule]

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.

[unclad5968]

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.

[neilv]

Yes, disappointing handling of the bug reports, discouraging that person from doing bug reports again for anyone.

As a submitter, you can decide to invest in someone's detailed bug report form, including attaching screenshots, etc., maybe taking an hour or more, and derailing the work mental mode you were in.

After that work, what you learn most likely happens next is one of the following:

* Silence.

* "Yes, that's a problem." Then silence.

* 6 months later, automated email saying that this bug is automatically closed, due to inactivity.

* 2 years later, automated email that they've done a new release, so they've decided to throw away all open bug reports. But if you still find the bug in the new version, you can file a new bug report, they graciously offer.

* "We know about that bug, but we aren't going to fix it." For reasons you don't understand. And if there's a cultural mismatch, the tone can come across as hostile or disingenuous, besides.

* "This is a duplicate of bug X." It is not.

* Closes the bug report suspiciously, perhaps for optics or metrics.

* (Silence FAANG Special Edition: A high-profile bug report, on which tens or hundreds of knowledgeable people are adding on, for years, all saying this bug is a huge problem, and many asking in the bug report comments why is nobody from the FAANG even acknowledging this bug report in their own bug system.)

Suggested practice: If you ask others to invest in reporting bugs (by having that bug report form there), then follow through in good faith on the bug reports you receive. (At least on the bug reports that seemed reasonable, and that invested effort in your process.)

[esafak]

Transparency in the form of a public ticket tracker would solve that.

[al_borland]

I ran into a bug at work where an app would crash and I’d get prompted to submit a report. It would happen several times per day. I often question how many bug reports I should submit for the same issue, and how detailed I need to be with each one, if the information has already been sent. I probably sent at least 40, hoping they’d fix it just so they wouldn’t have to hear from me anymore. Some were professional and helpful, others were mostly empty other than the log they generated, and others were a bit unhinged where I simply vented my frustration over all the crashes. I don’t think it was ever fixed, I just eventually didn’t need that software anymore.

[charlieyu1]

Same experience. Not even a tech person but I have reported obvious typos a few times. I think I got a thank you letter once and it was two months after I reported, that’s it.

[amelius]

This is like how I stopped reporting stolen bicycles.

[mmsc]

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.

[airza]

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.

[freehorse]

I think a lot of people here seem to totally fail to understand the user's perspective. Reporting on bugs is hard, because adding actual, helpful context to a bug is actual (free) labour. Yes, filtering out useless reports is hard for you, but that's the price you are gonna have to pay for having people do free labour (you get some unhelpful reports). You want to increase signal-to-noise ratio by focusing on decreasing the noise, whereas you should actually focus on increasing the signal.

Making simple, useless bug reports is easy and it will always be the easiest. Also the "my neighbour spies for the government" types will anyway always be the most motivated ones. There is no way to make it hard for "bad" reports without making it harder also for useful reports (barring some obvious cases of bots, ip filters etc, which are not what is discussed here and are a general problem not just for bug feedback). By trying to reduce the noise, you also reduce the signal thus get a worse SNR.

The specific tool is smart in trying to increase the signal. If you make it easier for users to add some useful context, MAYBE you get more users actually giving you sth useful, maybe even users who otherwise would not bother to add anything more useful than "it does not work".

I use software that recently made much simpler to make bug reports and add context, and they say they actually receive much better bug reports after. And most importantly, the users actually see that the bugs get fixed, which motivate them to make more, and more detailed, bug reports. Imo getting bugs fixed (and maybe even recognise the users' contribution in reporting them) is the best way to get good bug reports. Honestly, from my user's perspective having my feedback taken seriously is the best motivation for me to continue submitting reports. Because, honestly, sometimes bugs come up in complex situations that may be tricky to understand/reproduce, and it is hard to understand what context is relevant. I am not usually motivated as a user to spend like 20 minutes figuring out exactly how to reproduce a bug, but if I see that the company/engineers actually care and try to make it easy to me to report to them, I may actually do it.

Yes you are gonna have bad interactions also (and remember people have their own jobs/lives/not enough time to always engage with you the way you may want them to in providing feedback), but the point is to increase the good/useful interactions (compared to them), not decrease interactions in general. Unless you do not care much about bug reports anyway, that's also fine.

[Sohcahtoa82]

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

[graypegg]

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.

[TeMPOraL]

> "page doesn't work" with no further explanation reports

It cuts both ways. Guess what's one of the most popular format for apps and webpages to report failures to the user?

"Oops. Something went wrong."

Not exactly overflowing with useful information, either.

Sure, the system is probably logging the fault internally, and is always collecting metrics that help with contextualization later. But the system and its owner aren't usually the ones most affected by any given bug - it's the user who is. The user who's now worrying whether it means they're about to lose the time and work they put in the current session, or whether the app just ate their money (failures half-way through payment processes are the cutest, aren't they?). They don't know - maybe the "Oops!" was just benign, or irrelevant. Then again, maybe they've already lost it all 10 minutes ago - back when the previous "Oops!" briefly flashed to gently inform them that the service's back-end tripped over itself and died - but they won't discover that until later, at which point they'll be neither able nor willing to make a proper bug report.

Point being, if one sees their users as being 5 years old (but with parents' credit card in hands), one shouldn't be surprised to only ever get a kindergarten-level error reports like the ones you mentioned[0].

This is not just me complaining on a tangential issue - I believe showing specific and accurate error messages improves the ratio of useful error reports. It's not a full solution, but it's a step in the right direction. Treating them as partners, instead of a bunch of brats you have to put up with until they complete the payment, makes them more willing to reciprocate; giving users means to contextualize their experience allows some of them[1] to understand what's going on, and gives them something useful to put in the report too.

That, or I guess nowadays you can also keep the "Oops."-es, double-down on telemetry, and feed the metrics to a SOTA LLM to identify and interpret failures for your engineering/operations team, which we all know has neither time nor patience to do it.

--

[0] - "Page doesn't work" is the adult version of a kid suddenly starting to cry for unclear and possibly non-specific reason.

[1] - Obviously, not all, or even most. Software is complex, most users still behave as if half-drunk and unable to read, etc. Still, even 5 year olds can comprehend basic words and identify patterns. Figuring out that "could not connect to payment gateway" is serious, that "failed to write [blah blah tech terms]" that happens at random is probably not, etc. is within the cognitive reach of most users.

[drob518]

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.

[account42]

Goodhart's Law in effect.

[supermatt]

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

[carefulfungi]

Having run engineering teams for some reasonably popular open source products, my experience is that community reported issues can easily out-pace engineering capacity.

For every user who reports a clear, reproducible defect, there 10 others who report non-reproducible issues, who conflate features with bugs, who ghost, who use issues for support or questions, who are just angry about something and think you're an idiot, who report (since fixed) defects against old versions, or who report duplicates to existing issues. It's a very noisy channel.

It can lead to a crappy outcome for both the reporter who earnestly tried to help and for the developer who wishes they had the time to carefully address every reported issue but just don't.

Sometimes, all that's feasible is making time to triage/acknowledge each issue in a reasonable timeframe and to be forthright about its prioritization.

As an aside, I find your opinion that "if I give you my time in the form of a bug report, the least you can do is give me your time" to be common. We rarely have the right to demand another person's attention, though. Especially with respect to non-commercial open source hobbyist maintainers.

[tonyedgecombe]

The only exception I’ve found to this in recent years is JetBrains. Every bug I’ve logged with them has been fixed.

[cwillu]

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.

[Havoc]

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.

[tim1994]

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.

[SunlitCat]

The opposite would be something like the bug reporting system in Second Life by Linden Labs (an online world where you can be with a virtual avatar, doing stuff) (at least way back, i dunno if they still have that open).

They had a public facing jira open, where people could file bugs and what not about the viewer (the client) and the world (the server).

You didn't need some special account or something like that, just your normal Second Life account was enough to get access to that one.

Drawback was, you were able to see what happens when filing bugs is easy. Of course, many people used it to file real bugs but also complained about stuff not working like they expected (or how it should work according to them, which brought other people up against them and so on...in the end you were able to read the latest drama here and there, right in the jira entries).

Although, to be honest, i thought it was an awesome idea, but you when you open up an easy way for people to report bugs, you need an easy way to explain what bugs are and what not. :)

[wittjeff]

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.

[SoftTalker]

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

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

[cosmotic]

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.

[lupusreal]

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.

[0cf8612b2e1e]

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.

[ryao]

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

[account42]

As a user the best thing you can do to make me report bugs is to show that you are actually going to fix reported bugs. Taking my time to gather information that will effectively end up in /dev/null is the opposite of fun.

Also important is to let me make sure I don't waste time reporting something that is already a known issue.

The best way to do this is to have a public bug tracker.

Given these preconditions acceptable effort only depends on how invested I am in the product.

[briandoyle81]

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)

[_wire_]

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.

[TheAceOfHearts]

I think reporting problems is just part of being a good citizen that participates in a shared culture. If I visit a park or shop and something is broken, it's worth putting in a bit of effort to report it. If everyone chips in a little bit of effort it makes the overall experience of everyone much better. Are you the type of person to also not return the shopping cart to the corral?

The number of hardware and software combinations are impossibly large, so you're unlikely to be handling everything perfectly if the application is doing anything complicated.

[foobarchu]

> What other industry relies on its customers as implicit developers?

I would say most of them. To list a few:

- restaurants (almost all of them will send you feedback surveys these days, they also rely on you to tell them if they, for example, cooked your steak to the wrong temp)

- property maintenance (again, feedback surveys)

- auto mechanics (if the thing they fixed is still broken, a good mechanic wants to know)

- doctors (they rely heavily on YOU to tell you what wrong with your body)

- democratic political systems (when working correctly)

- road infrastructure (the city won't fix potholes nobody is reporting, and they won't do anything about badly tuned traffic lights nobody complains about)

- vaccines and medicine (the testing phase may not uncover every possible single side effect, they need recipients/users to report those if they happen)

(Please nobody come back with cynical takes on how these aren't helpful in their specific case/location, that's clearly not the point)

[rikroots]

> 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

[Leo-thorne]

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.

[solarkraft]

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.

[ChrisMarshallNY]

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.

[nailer]

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.

[lakshikag]

Thank you, Nailer. I'll definitely be doing some tweaking around that part.