No. But I think you might be taking your work a little too personally.

If one in 1,000 people give you a suggestion that actually helps to improve your software, or reports a bug that would be nearly impossible to find otherwise, or perhaps corrects a translation issue .. or any of the constructive things that users tend to do from time to time, putting up with the other 999 was worth it.

Do not ever, under any circumstances continue to deal with someone once they become belligerent, threatening or completely unreasonable. No good can come from a conversation that has deteriorated to that level. Hang up the phone, close the ticket, bury the e-mail, or whatever else you have to do to remove that piece of noise from your life.

Finally, a simple phrase like "We'll take it into consideration for the next release" goes a long way, even if they suggested that the threads sewing the seats together should be a slightly darker shade. You never know when that user might tickle an interesting bug .. and those type of people tend to be quite meticulous when filing bug reports.

Additionally, have you seen the feature requests at meta.stackoverflow.com ^[1] ? Good grief, many of them come from programmers.

I hate the users. Am I a sinner ?

Technically, yes. But that's not your fault. It's in the nature of the things, in human psychology to have a strong emotional response towards those who take you out of your comfort zone. Many passionate programmers have a strong emotional binding to their developments. It's because programming is not just a job for them but also the center point of their personal interests (and life - but you didn't hear me saying that). Here comes professional pride which is very easy to hurt by not providing enough admiration or by issuing a small bit of criticism.

You need to get past that. If I were the Lieutenant Tuvak (from Start Trek Voyager) I would advice you to learn to control your emotions, to perform emotional detachment otherwise the emotions will consume you.

when I get a #1, #2 or #3, I get very angry

You should take #1, #2 as an opportunity to improve things. Your users' opinion lets you see things in a different light.

Here's the thing. You're developing software for users. They are going to be using it, so you need to apply some efforts to make them satisfied and happy. Software should solve their problems, be easy to use and don't build any additional obstacles by being incomprehensible. If you don't accept that then you should ask yourself: "What's the point of me writing software? Who's going to be using it?". Answer those for yourself and you'll see how your attitude will change.

The problem is that programmers often do not have a clue about UI design, usability or the customer business processes. Programmers are persuaded they know it all. The practice destroys that illusion in the most painful way which reaches them personally. It's hard when it happens for the first time. But it gets easier with time. You'll just need to revert the implications.

You think that you don't want to hear user complaints and criticism. That's fine. Understandable.

Try this instead. You want to hear the users' complaints, criticism and "unsolicited advice" because it will help you understand how to make the software better. In a storm of complaints there are always some drops of wine. Recognize them, filter them out and make good use of them.

There is a strategy called user-centric design. You go to the customer site, you talk to the future users (not managers) of your software, you watch them going about their day, what they do, which problems they stumble upon and how they solve them. You write it all down, sometimes record it with audio and video. Then you go home and analyze what you've seen and what you've learned. You set up your development process around continuous input from your users. You need it to make a product that will fit in harmonically and will be accepted by people not rejected by them.

It may be too much in your case but still, take whatever your users say, analyze it critically. Maybe there are useful ideas.

A successful programming product is much more than great code. Code is just a part of it. Other parts are just as important and may be defining in the product success or fiasco.

Having said that I feel the need to make it clear that all people are different. Some are great programmers but lack any design skills. Some are good technical architects but lack management skills. And some are just not born to be dealing with customers. With time you understand your place. If you learn you can't work it out just let your manager know he should cut you off from communication with customers, otherwise it's no use if you keep getting angry and that disrupts your productivity.

No you're not a bad person, but I think you're suffering from a classic case of developer/user disconnect.

Do you work work closely with your users daily when developing new projects/functionality? A cornerstone of the Agile movement is to bring everyone closer together much earlier in the piece. It's amazing how many frustrations are removed by working together and understanding each other's points of view as early in the process as possible.

Nice, understanding bit: No, you are human. I frequently want to sma^W re-educate my user base. However I find my attitude change quite a bit when I force my self to work with the users. Shadow the user to find out what they do.

Alas I'm an evil git bit:
criticizes for something that actually works - Works and works well are very different beasts.

whining about small stuff that should be changed - Are you sure your idea of small and his/her idea of small are the same. Maybe that small change will save them a few minutes a day? That is quite some time over a year.

his judgement is much heavier than mine - Really? I end up using this product day in, day out. My judgement means a lot. Even more so if it is an in-house type app with a small user base.

You are a narcissist that programs. you are evil.

I don't know about your #2. I'm currently driving a rental car, and I was looking at the dashboard this morning, and I realized the speedometer is weird. It has really big numbers (0, 20, 40, 80, etc.) but because they're so big, the tick marks for the ones with numbers are much smaller than for the speeds between them (so 10, 30, 50, 70, etc.). This is just so backwards to what any other speedometer in my life has ever been like (major tick marks are biggest, and the ones in between are smaller, and the minor ones in between those are the smallest). It seems like a tiny thing, and it is, but when you have to keep glancing at it all the time, it's distracting. You start thinking, "why the heck did the designers feel the need to change that?" "Didn't they focus test this?"

So yeah, some little things in your eyes are big things in their eyes. In your example, if you didn't use a standard configuration for the OK and Cancel buttons in the bottom right of your forms (for instance, sometimes cancel was on the left, sometimes the right), then I could see someone being frustrated by that. If you have a lot of little issues, it's like death by a thousand papercuts.

Though I do sympathize. I think we all get frustrated with the requests, but you have to learn to embrace the feedback, and not take it personally.

You are either Sark or the MCP from Tron ^[1]

Consider yourself lucky.

What's really awful is when

1. The business you work for hasn't completely thought through their own business model and they've never really systematized their business processes before computers have even been brought into the equation. Them: Let us delete the order. You: Okay, but what are you going to do with the rest of the stuff you still owe the customer? Them: ummm...I dunno.

2. The users in the business you work for are complaining about the consequences of the features that they themselves mandated you add. For example, you're asked to add five additional text fields to a user's screen to give them the additional detail they want, and they feel being forced to drill down to another screen is unacceptable, but then they complain that all the stuff that you're required to jam into the screen makes it "too busy" and cluttered.

3. Give you contradictory requirements. "Give the user the flexibility to do whatever they want no matter how bad it is but prevent them from doing anything bad."

I came from a usability background where understanding and tolerating user requests is considered of the utmost importance, and even I got frustrated at times.

It is only natural to hate them, with their constant gripes, their complaining and endlessly just insisting on using the product you work on. What right do they have to tell you how to do your damn job?

But wait, what is this? Why do you have to use that convoluted series of steps to update the project references in your IDE? What right do those damn IDE developers have to make your life so difficult? You've reported it as a bug, or at least a big flaw in their design, but have they done anything about it? And that thing where it gets in a spin when you do some simple document parsing! Why it drives you up the wall... but could that be... is it possible? Surely not! And yet it seems that maybe you are a user too!

I hang out with a lot of people who play various roleplaying games - table top ones, D&D or whatever - and one of the things you find if you play these games run by other people and as you act as games master to your own games - is that the moment someone becomes a player it is as though their IQ drops by 50%. Normally smart people become instant idiots the moment they are playing a character in a game and do the most outlandish and ridiculous things.

I mention this because I think it's something that happens to us as users too. You are a genius at developing software, working with the interface, knowing all the shortcuts, it all just works. But the moment you are a user of someone else's, especially if it's not something you use the whole time, you become a fumbling incompetent - not because the software is bad but because you have become a user.

I think of it as user syndrome and it happens to all of us. The only way to know how your software will stand up to it is using significant testing performed by the type of people you expect to be using it ( and a few you don't ) prior to release. It won't prevent the user syndrome from striking, it will just mean you know a bunch of the things those crazy guys will do when they try to work with your product ahead of time and you can try to mitigate them...

I see this same reaction to software feedback often. I think you need to learn to separate two very different parts of the user's feedback:

1. The problem part. This is the interaction, the behavior, or the requirement that left the user confused or caused them to do something wrong and upset them.

2. The suggestion part. Most users can't help themselves, when they encounter #1, from thinking that they know what should be done to fix it.

Often the developer's response to a user's 1-2 punch is going to be a little personal at first, and then they begin focusing on the #2. "Well, that is a ridiculous suggestion, it wouldn't work for the 1000 other people who use this software. So, this user is just dumb."

The good news for the developer is they art most likely partly right — #2 is probably a dumb idea (OK, I'm exaggerating, I mean it's probably not the right solution).

The bad news for the developer is their conclusion is wrong. #2 being wrong doesn't invalidate the problem part. A good user experience designer will consider any friction encountered by any user. If after investigation, the user really is an anomaly, it's fine to be discarded. But more likely, this user was just vocal about something that many users experienced, and probably blamed themselves or hoped they will just learn next time.

Any time you can reduce the friction your user's experience, you will help make your software more successful in accomplishing the users' goals. They will be more likely to use the software more extensively, more likely to recommend it, more likely to trust you, the developer.

If you think of it this way, you will see that the observation of friction or a problem is an opportunity, not an attack.

I think you're describing a lot of us at one time or another, that is, in serious need of an attitude transplant.

Take a Dale Carnegie course. Seriously. You need it. I did.

You aren't a bad person. But consider that such nitpicking may just be angry venting on their part due to some other part of their job. So take a breath and try not to reciprocate it.

To quote from the Programmer's Bible:

Thou shalt love thy users as thyself

Repent!

[just kidding; some users are jerks, most are just clueless]

One note: users that were not involved in the design of the software that they have to use are more likely to resent it, no matter how awesome it is.

1) just show how to use it and ask to repeat it (her/himself), then ask the question in polite form "do you understand?" any way it would not be your problem in the future.

Solution: maybe some additional popup text, tooltip at the first using of this feature will help

2) people are creatures of habit. some used MAC, otherone Windows and buttons are placed on the wrong place. just take a deep breath.

Solution: maybe some option, settings can resolve this: put OK button on left and Cancel on right or reversed.

3) oops. it is a bad day...stress...really it is not your problem.

Solution: visit him/her tomorrow or when this person really understood that (s)he should to do something and (s)he really need your help. (be 2-3 minute psychologist, no more)

"take a deep breath..."

You're a programmer. You like the code you write. It's only natural that you get irritated by people who criticize code for no obviously valid reason.

You have to learn, however, how to handle critique. First of all, rejoice that there is any feedback at all. The majority of your users will notice something's awkward, or wrong, and never say anything, because they're too used to poorly written software and GUIs, or because they don't think that mentioning it will change anything.

Second, not all feedback - whether positive or negative - is useful. Most often, you get useless feedback because the users do not know how to express themselves correctly. For example, they may say "this button should be blue, not red". WTF, right? However, the question is: Why would they want the button to be green? Maybe red meant "important" to them instead of "danger", so they clicked on the "kill all"-button accidentially. Maybe they're red/green colorblind and couldn't find the button that should stand out etc. In short, it is important to learn to find out what the users mean, as opposed to take to heart what they are saying.

Thirdly, feedback often says at least as much about the person giving feedback as about your program. For example, it reveals their complete lack of knowledge about how the program works - which tells you that the layout of the program is not intuitive to all, and/or that the documentation is not accessible enough. Or, it reveals that the other person is having a really bad day - in which case you just nod politely, offer some words of comfort, and forget everything they just said.

Ahhh... the users who are automatically consider themselves as design gurus...

Enjoy: http://theoatmeal.com/comics/design_hell

The #1 user is pointing out a place where the UI is at least a teensy bit confusing. If you've got external customers, that's valuable. Lots of people will try your product and give up, or at least buy nothing further from you, and not bother to complain.

The #2 user is pointing out another small area where things might be improvable. Take a look at what they say. It may be that button X is to the right of button Y in most places, or that putting button X on the right adheres more to the platform conventions. They might be wrong, of course.

Both of these sorts of users are providing potentially useful information about the user interface, and many programmers are really lousy interface designers. The wording in your question suggests that you might be at least slightly blind to UI deficiencies, and improving the UI might lead to a lot more sales.

The #3 user is being absolutely useless. Make at most one effort to get useful information about that user, then say you'll be happy to listen when that user can be coherent, and hang up or whatever. It may be possible to get information out of such a user, but it almost certainly isn't worth the effort and stress.

I'm not going to excuse rudeness because you can always spot a low-class person by how they treat people trying to help them. As for those people who 'should' know how to do something and pick and choose what is important in a UI - they're paying your salary. Getting mad is not an option. You can train yourself to be and act like a professional.

Yes, you're a very bad person, sometimes sh** happens or there are misunderstandings but YOU as a developer MUST understand the users(which sometimes doesn't even know how to write an e-mail) that they CAN ASK DUMP QUESTIONS or suggestions -- you must be reasonable and take it professionally either by trying to explain that they are irrational or by avoiding any conflict whatsoever by agreeing with them -- after all remember who pays for your stuff.

P.S. I'm NOT suggesting in any way that you need to ignore them or accept all BS, but you must take it with diplomacy!!

What you are asking for, seemingly without knowing it, is submission. You want the users to submit to your perceived superiority, and you have a problem when they do not. I feel your pain. Seriously. I used to do phone tech support, although I never hated the users who phoned in, since:

It is your job to make it simple for them.

Otherwise you are worthless, because people don't buy code, they buy products. Ugly truth but in this context it must be said. I'm glad we can speak freely. As a programmer you are not the master, you are a tool. I hated the first time that truly hit me, and I hate it now.

This does little to change reality, as I found and you may find out. It takes an extreme amount of hate to change things even a little bit.

You have a couple of choices:

Force them to submit.

Or accept that they will not and design and write better software.

Alas, to force them to submit, you'll need a different set of skills: pyschology, politcs, anthropology and related. Be assured that being smart , or rather , facile at logic, which is a thing only invented in the last 1% of human existence is not enough to enforce submission, which is as old as the alpha male. Older in fact. That's why the smartest guy in the room tends to help the guy everyone gets along with.

Kirk, Spock. Who was the better captain?

Fictional show sure, but fiction made for popular consumption. You are Spock. They are Kirk. Sorry.

Might be easier to design and build better software. If you can't , then try prozac. It'll get you through the day, for yes, you are a sinner.

Take it on the light side.. and hold the following as a golden rule: :)

demotivational: customer service ^[1]

A lot of the source of the whining and complaining from users is derived from their lack of power. That is, they simply cannot do anything to alter the software and thats very frustrating (whether they are justified or not). They arent programmers. To a lot of users, programming might as well be black magic. or voodoo. Seriously. And a lot of users just arent very diplomatic about such things due to a lack of interpersonal skills. People complain about programmers not having them, but truth be told, its just as big a problem among non-programmers. Plus nowadays, it seems lots of people just arent able to write coherently. So when those people complain, you get what you are talking about.

You need to learn to live with it, and not take things personally. You cant have a thin skin. Especially if your software is heading out 'into the wild' into conditions where you dont control the environment. Problems arise, and yes, stupid people get a hold of your software. If someone complains, or leaves a bad review... well, ignore it and move on. The best you can do is try to decode their underlying problems and improve your application.