As long as it is somewhat honest or qualified negative feedback this is true.
As someone who studied film, trusteothy sources of negative feedback can be extremely valuable and hard to come by. Many people will just tell you how well you did, while you might just need a honest judgment.
Taste however is different. You can e.g. make the best cli app in the world, you will find a ton of people who give you negative feedback just for it not having a GUI. This is why it is useful if you know your critics at least so much that you can judge where their feedback really comes from.
So the honest opinion of someone using CLI software for the past decade is more valuable if you're working on such a thing, than the honest opinion of somebody who dislikes CLI software altogether or has no idea at all. That doesn't mean these people cannot provide valuable criticism — only that it should be taken with a grain of salt.
People criticizing a good console application for lacking a GUI indicate need for such a GUI, this is not criticism per se. It is useful information too. But many developers just don't have necessary time or will to code it and this needs to be conveyed. Proper communication is the best thing humans ever developed.
Well it might be more than just a feature request.
Think along the lines of wireshark, you can separate out the underlying code to do the work in a library, then use that in a cli and gui. If you're working on a cli app yourself, that "feature request" might hit things you just don't have the will to do. I know me making any sort of gui is going to end up a tire fire, and the work to cleanly separate out the code from the cli to a library usable by both is also a bunch of work for what appears to be a at best nice to have "feature".
Sure, will to do, is one thing. Consider I request the curl dev to make a gui for it. would you find it unreasonable because everyone is okay with cli ?
I just cannot justify any reason apart from the convenience of using gui to develop that.
> separate out the code from the cli to a library usable by both is also a bunch of work
The time and amount of work is in my opinion not just about the amount of work, because if that was the case why develop even the cli and opensource it ?
Make a GUI is just a different beast compared to CLI.
> Consider I request the curl dev to make a gui for it. would you find it unreasonable because everyone is okay with cli ?
Yes, as libcurl exists and gui's can be done by someone else more knowledgeable with them. Plus gui's for what exactly? The web? macos? windows? X? playstation? even asking for a gui is a bit vague and an incomplete request I would reject outright without at least going: i want this.
I'd solve this by going, sounds good, you're the best person for it so far and now have write access to create a branch and get us there with the itch to scratch it.
> Make a GUI is just a different beast compared to CLI.
Agreed, but the effort can be disproportionate to the gains the submitter might get. And if this is something i'm doing for myself, to be blunt, I don't got time for that kind of effort. And more bluntness, nobody could make me do it, my time is my own and I have to balance that against other things. If you ask for it you better believe I'm going to say its now on you to do as I have neither the skills nor desire to invest my own time on this. I'll gladly help you out getting there but that is about as far as I'm willing to go.
Pretty much yep! I think we both agree asking for gui support is likely to get shot down by most maintainers. And not for any reason than its a big ask.
> GUI is a huge separate feature request and not "criticism" per say.
I've seen a lot of people even on HN complain about cli only things. I'm not sure everyone would agree its a feature request.
It can be useful criticism or an indicator where you could move towards in the future, but for the current project it won't help you.
This kind of criticism is even less useful if you are doing e.g. music. Let's say you are part of a Death Metal band and ask for criticism on your music because you want to get better as a band.
The most useful (negative) critic will be a friend who has been listening to Death Metal for years, plays it themselves, has a open mind about different genres, knows what you're after and still will give you the straight hard truth.
The least useful negative critics will be the ones who say they don't like metal and think your music is too aggressive or the metalhead who wants you to do another subgenre of metal because they like that more.
Music of course is more based on taste and subjectivity than software development should be, but one can transfer at least some of this idea: people will often argue from the perspective of their preferences, completely ignoring the scope and goals you publicly stated. And if your goals as a software developer don't align with your critics preferences, their criticism can lead you astray without you noticing it.
It can still be calid in terms of redefining your scope or expanding your goals, but it doesn't help you to get better within them.
Good negative criticism takes seriously what you wanted to do (if it makes sense!) and jelps you to get better at that.
I heard a quote many years ago. I don’t remember where from. But it was basically:
“Negative feedback is the best feedback because it helps you improve the things that annoy your customers that no one else is telling you about.”
A lot of companies hate negative feedback though and get upset. But if I ever tweet something saying it’s shitty or doesn’t make sense. If they reach out I always try to give them more info and clear reasons why.
Most recently I complained about a survey tool because it asked a question but the design of the form didn’t show an input field and I didn’t know where to enter data. So I pressed enter wanting an error message or something. And instead I got taken to the next question.
Turns out it was a display issue in any browser other than chrome. But they reached out and I explained and they thanked me and said they will look into it.
It must be hard for people to filter through the negative stuff for valid criticism though.
"Negative feedback" is not positive when it's merely an insult.
Let me clarify:
"Your app is so slow it's proof you have absolutely no business writing software and evidence of the moral decay of the entire field of computing, if not humanity as a whole. Give up. You deserve a six-foot nap." is not merely an insult. It contains an actionable point.
"You have absolutely no business writing software. You're a monster. You do not qualify as human. I would like to see you in an immense amount of pain." is most definitely negative feedback, but it does not contain anything actionable. It has no positive aspect to it.
The fact unquestionably sane people can generate feedback of the second kind is one of the things to consider when accepting feedback.
> The fact unquestionably sane people can generate feedback of the second kind is one of the things to consider when accepting feedback.
It's easy to drive people to (temporary) insanity, too.
A recent anecdote: PayPal sucks (as usual) and doesn't let me log in. They've been requiring me to change my password before because of some strange Californian paranoia, so I hope that'll help and reset my password successfully. I still can't log in. I'm looking for ways to contact customer service. It says "log in, then use the contact options to send us an email". It has a "can't log in? call us!" option, I call them, sit through an annoying 60 second phone menu, only to be told that they're not working right now and to call back on monday. I notice that their "password was changed" info wasn't sent from a no-reply-address, but some service-email, so I just reply, annoyed. I get an auto-reply, saying "to send us an email, please log in ...". Needless to say that I never heard back from anyone.
It's such a broken process by a global corporation and it was so annoying, that I was pretty close to just responding with insults, but I'm trying to control my emotions, and also I still need my PayPal account.
AliBaba/AliExpress is another example, they use (used? haven't tried in a while) chatbots pretending to be human support agents, and they're so bad at it that it's a) absolutely not helpful for most cases where you need support b) easy to spot. The insulting part is that the (clearly labeled) first response chatbot says "let me get you a human agent that can handle this", only to put you into contact with another copy of itself that asks the same questions. The part that really makes me want to scream at them: their bots have artificial "thinking time". They'll say "one moment please", have typing indicators, only to say "you're asking about '$keyword', right?".
Very strong negative feedback could just mean that you're really messing up, or the way you collect feedback is broken. Have a form that only accepts 200 characters in the message field but only says so when you submit and resets the form? You won't get a lot of friendly messages from people that had just written long bug reports or messages.
It can be actually positive anyway. You just need to understand that strong emotions often stem from unfulfilled or broken expectations. It is not about you, it is about them. Some people just don't vocalize those expectations in the initial response because the emotion is too overwhelming.
But it is also true that there are crazy and inadequate people out there that either respond randomly or have unrealistic expectations. Their replies can be considered somewhat positive too - they indicate that people use your product. If your product doesn't attract crazies by design and is not a totally unusable, deceptive and buggy garbage they usually represent only tail of your userbase distribution.
Feedback is the process of finding problems and initiating a change to solve it. If you get feedback but can't find any problems or there is no need to change anything then you can just ignore it.
If you have a blue website and constantly get feedback from people saying they love blue then you didn't need the feedback.
From experience doing a startup and seeking feedback on a new product, I think this is absolutely true. Some people here are saying the feedback needs to have substance or not just be insults, but even those are meaningful. Your job is to read between the lines. The real question you need answered isn’t the same as the question they answer, so you always need to think about how to translate their answer into priorities.
Even no feedback is positive feedback, because it’s telling you that people aren’t in love with your creation the way you are, and you then need to find out why. When I created a web app, I solved the problems that I strongly felt needed solving, and then I found out that maybe 5% of my audience agreed with my choice of priorities, and 95% of them cared deeply about things I hadn’t considered carefully.
There’s a corollary for startups that negative feedback from investors is also positive. The second best thing an investor can do is say no (where the best is yes & a check). They hardly ever say no. They usually say come back with such and such improved metrics, and we’ll talk again. When they say no, it gives you valuable information, and it releases you from chasing something that’s unlikely to work out. When I was pitching, I was so thankful to the couple of investors who said no and gave direct feedback about why. That was some of the best feedback I ever got.
As a game developer I don't really listen to feedback. Gamers' feedback tends to be very short-sighted and even harmful. If something sticks around as a common complaint I may consider it but even then it may not be a good idea (e.g. a feature that may seem obvious can mess with another planned feature in the roadmap or be automatically fixed due to reworked mechanics).
I've found that feedback from playtesting is always worth listening to, especially if it highlights issues (e.g. with game mechanics or balance) that weren't obvious to me as the game dev. This is an instance of the more general process of getting users who aren't the dev to help test a system, e.g. because they will take unexpected paths through.
Now someone please explain to my boss that "you don't listen" and "can you just do your job properly", when he doesn't lay out the correct requirements and expect us to read his mind is not proper "negative feedback".
If that helps, I usually draw a big picture, fill in all the details and show where inconsistencies, gaps and future landmines are. Then come up with few detailed suggestions, workarounds and/or hypothesis on these, all easy to answer with yes/no. Usually that discovers an entire layer of problems in the original problem statement and the cycle repeats.
Sometimes though they fail to even yes/no and just repeat what was said before. A little patience and time is required to bring that in their mind clearly.
I think an advice could be, don’t bring emotions to the table and try to solve this bigger task of getting shit done in machine+human environment rather than locking yourself in a strict requirements bunker. Connecting ideas to reality can already be incredibly hard and more so impossible without your help.
The goal is to disarm people so they're able to criticize something without worrying about saving anyone's face. Separate people from ideas... as much as inhumanely possible to get honest feedback.
I must always remember also: don't fall in love with or lionize any particular idea, creation or plan because they're not my children and are ultimately stuff and/or configurations of concepts. In the bigger view, ego death and detachment are important because if someone lies to themselves, for whatever reason/motivation, they're going to lie to everyone else too. Single founder tend to have more "grand big idea" insanity that needs to be tempered with other founders, family, friends and/or users who aren't dripping negativity but who don't applaud them if they can't sing like those people who go to open mic nights and screech. Don't be that guy or that founder with a Jump to Conclusions mat.
Any thoughts about the norm of "constructive criticism"? I think it's partly a good idea, because the feedback-giver can take a little trouble (propose improvements along with criticism) that will save a lot more trouble for the feedback-receiver. But also partly a bad idea, because I've seen people defend pointless bureaucratic procedures that shouldn't even exist, by saying "don't say our procedure is bad, say how we can improve it". So it seems that "constructive criticism" is partly a good idea and partly a kind of groupthink practice, but I'm not sure where to draw the line.
While I feel I only partially managed to capture how I think about it, because I surely have thought about it a lot, as I've seen places where critique flows like water - easily and without much strife to anyone - and places where any critique is/becomes either a disaster - or completely ignored!
---
Constructive criticism as such might be a sensible ideal when giving unsolicited criticism, but it also terribly destructive as an expectation, or norm.
In many cases the call for constructive criticism is nothing else but a very effective form of censoring as t makes any criticism from anyone that hasn't got the necessary knowledge, or time that be able to find and elucidate the solution to be completely dismissible without consideration.
Not at all what one wants, unless you want to suppress "dissent".
Requiring only constructive criticism could perhaps acceptable as a very temporary intervention when all else have failed. In any other case it almost certainly devolves into some kind of censure.
This does not imply that the one critiquing is free to do or say whatever they want, not at all!
Honesty, a constructive intent, avoidance of ad hominems, engaging without prestige or appeal to authority, and a substantial amount of intellectual integrity is always going to have to be required of anyone giving or accepting critique - if it is to be truly useful.
Moreover, I would claim that sustainable and effective criticism in a professional setting must also be accompanied by an almost complete lack of subterfuge. Especially any kind of hidden attempt to cast yourself in a better light, or someone else in a worse.
Getting to be able to sustain effective criticism can lead to a higher ratio of constructive criticism, but I haven't seen anything suggesting the reverse to be true unless the basic values of honesty and integrity are given equal consideration and prominence.
Critique must be expected to sometimes be painful in some - often obscure - way, so what we can do improve how we handle it is most easily explained from the perspective of taking away what makes us fear this particular form of pain.
Sometimes fostering a good climate for criticism seem to be about almost everything but the critique itself.
I would say "negative feedback is usually good news". Positive feedback is bad news. The vast majority of control systems in the real world are usually based on negative feedback, not positive feedback.
You only really need to provide "positive" feedback as part of stabilizing an unstable system - like countersteering when driving a car. And then if you do it properly it kinda turns into its "negative" anyway.
A personal pet peeve of mine is that people sometimes ask rhetorical questions - rather than simply state what the problem is. Drives me nuts. For example: "Why doesn't this button submit the form?" vs "I don't think this button works". I see this all the time and still scratch my head.
There are downsides to saying “this button doesn’t work” — there’s a follow up question in some cases, which is “what makes you say it doesn’t work?” Asking the question acknowledges that there may be a lack of understanding of the intent of the button. Maybe to you it doesn’t work, but to the person who designed it, it is working as intended, and your mental model is the incorrect part. Asking the question as framed directly in the way you experience the world (action not leading to an expected reaction) makes the problem statement more clear.
What do you think is more reasonable? Asking hundreds of thousands of users to learn to give better feedback, or for hundreds of developers to learn better listening?
The problem here is a meeting of minds: The user can't possibly know what is expected behaviour, especially with the modern lack of GUI standards. A tester might be able to read a user manual, but the manual might be wrong. As dev, you're the vendor. Some maturity is expected and that you're able to figure it out.
What helps is reaching out to users earlier and agree on behaviour together. You know, using agility.
It’s a pretty sophisticated skill to hear aggression in others and be able to hear what is causing them pain instead of just “I wanna fight.” But aren’t we problem solvers by trade?
Problems make people upset. If you can only treat polite customers you’d make a terrible health care professional or even plumber. Someone once gave me the advice that part of why developer salaries are so high is because they include hazard pay.
I suspect the same is true for plumbers. $300 to get my plumbing unplugged on a Saturday night can probably smooth a lot of feathers with his family. And that was a slight discount, probably because I was pleasant, instead of railing at his whole profession for a problem he didn’t create.
It’s hard to remember this sometimes, but I do think it provides some perspective.
I actually think the tendency is to ask questions since they are simpler. It’s an extra leap to say “this button doesn’t work” because you have to make a judgment. On that note, sure, you can’t expect most of your customers to give great feedback, but that’s why finding those few customers who do is so rare and valuable.
I prefer the question. Saves me having to ask what they think it should do. "X doesn't work" often isn't very useful feedback in my experience unless accompanied by more detail.
You're highlighting that good bug reporting is also a learned skill. It is not sufficient to say button X isn't working. An experienced bug reporter will also include information on what the expected behaviour was, and often also explain what is needed to reproduce the problem.
It helps to explicitly ask about this from end users when you have a bug reporting form.
Except it's never learned. Most devs and testers absolutely suck at it, no matter how much training or long experience. Otherwise great people, but you need to put yourself in the role of the person receiving the bugreport. Most people don't know the tech too well, can't do that or forgets to do it very quickly. In the heat of the moment of deadlines, this is expected human behaviour, ie. optimizing locally.
I find, when there's no common context, I have to reach out and spend some time with the person anyway. Usually you gain new insights, relationships and improved common understanding. Feels almost humanizing and well worth the time spent.
If people say either of those the problem is with your product UX design in the first place.
There should be distinct progress indication for long operations and human-readable feedback for every failure mode, even if simplified, to avoid overwhelming users with difficult terminology.
Very often the simplified human-readable feedback is "Oops, that didn't work". And it is so simplified that there is no useful information to send to an expert for help. It is better when the error message is unique and can be googled (or your intranet equivalent)
It is perfectly fine to have "Oops it did not work, try again later".
Loads of error scenarios come up once in blue moon, details for those you should have in application logs that should be analyzed by technical support. Usually user cannot do much about those, like some service is down. Information about some specific service not working for users means your application is down, so it does not matter.
Then you have failure modes that happen often, like users getting data from outside system where your business rules do not allow for that data. In that case user has to be provided with information what he can fix, "Operation is not permitted because we operate only on yellow cars, buy a yellow car please".
In the end technical support should triage issues and invest time on specifying error messages that can help users skip technical support. It is a waste of time to come up with all errors explaining some details.
Personally I found no situations where oversimplified indication of failure is fine in such contexts.
If service is down users should know it is down and it is not a failure of their device or network connection. It is normal to skip specifics that developer need for debugging but simply indicating a failure will just annoy users because they won't know what they could do. And contacting support each and every time is tiring and counterproductive for everyone involved.
It can be error code or somewhat generalized textual description but it gives users feeling of control which most people like to have.
In my opinion that is perfectly good reaction.
If someone asks it shows willingness to solve the issue or understand the problem.
How do you know that this button does not work?
Maybe the form has some field that does not show validation message.
Usually when users say with confidence that something does not work, it turns out that something else does not work and that button they mention is perfectly fine. In most of cases users just expect something else because they don't understand the system.
Because pretty often there is a reasonable answer to that question - especially when you are seeing system first time and know that there is a lot you dont know about it.
In systems engineering, negative feedback is viewed as one form of 'unexpressed system requirement' for that stakeholder. Surprise negative feedback can be even better, as it may be a sign that your system has a stakeholder you weren't even aware of but which you now are.
I've known this for ages it goes without saying that in real design when you show your work to another designer they're meant to find the one thing that sticks out and the more brutally honest the better
People will rarely tell you to your face that your “baby” is ugly. For actual babies this is a good thing, but in business this can lead to much wasted effort.
Very good quote. However, I'm not sure that he practiced that enough, given for example his repeated online bullying of the diver (which should have been corrected after negative feedback).
Here's what I've found as effective ways to give (and receive) negative feedback.
1. TRUST - I'm part of a tight-knit group of bootstrapper/indie devs and a real aspect of how we're able to offer real feedback is that we have the backdrop of knowing each other in other ways.
If someone who I consider a fantastic developer and sent me a Christmas card last year tells me: "Mike, this makes no sense." take that a lot more seriously.
2. DATA - as a human I've found that I'm often wrong, so I try to evaluate my own opinions against data. In the context of apps/sites this is often A/B tests or other quantifiable things.
3. FEEDBACK NOT ACTION - People tend to offer feedback along with a kneejerk suggestion on what action to take to resolve it.
Example: I had a service that required users to OAuth (with a bunch of legitimately scary permission scopes) and also make DNS changes to enable it and was told repeatedly as feedback that it was "too much" and "people would never use it".
Their recommendation: shut it down.
The direction I took: go crazy building trust in the process.
The result: my most successful project to date with thousands of paying customers.
3. SCOPE - feedback is often scoped improperly. Is someone asking for feedback about a startup idea: "Will this connect with people?" it's not useful to critique the fonts used on their homepage or something else. (both HN and I are too often guilty of this).
4. BELIEVE FEEDBACK - one of the most important exercises I do for all my projects now is a "UX walk through" where I sit someone down and just try and let them sign up and work through the process of signing up for the service with as little intervention from myself as possible.
I find it incredibly painful.
Even interfaces that I think are incredibly polished and straightforward suddenly become opaque nightmares when presented to people that haven't seen them before. This is the "curse of knowledge" - I'm too close to the process and can't see the issues clearly.
In these situations, it's incredibly easy to argue with people about it and say: "how can you not have seen that button?" or "You're not really paying attention" or something else dumb.
But if I'm able to make myself believe the feedback, not take it personally and really address the issues at hand I find I get fantastic results. Last time I did this I ended up scrapping months of works (painful), migrating to a new auth system (painful) and rebuilding the entire onboarding from scratch (incredibly painful), but the end result was a move from 30% successful user onboarding to over 70%.
As someone who studied film, trusteothy sources of negative feedback can be extremely valuable and hard to come by. Many people will just tell you how well you did, while you might just need a honest judgment.
Taste however is different. You can e.g. make the best cli app in the world, you will find a ton of people who give you negative feedback just for it not having a GUI. This is why it is useful if you know your critics at least so much that you can judge where their feedback really comes from.
So the honest opinion of someone using CLI software for the past decade is more valuable if you're working on such a thing, than the honest opinion of somebody who dislikes CLI software altogether or has no idea at all. That doesn't mean these people cannot provide valuable criticism — only that it should be taken with a grain of salt.