I think I see the problem here.
Perhaps if your users stopped using the “stupid end” ???
I just can’t defend “It’s not a bug, it’s a feature!”
There are things that are obviously bugs like crashes, there are un- or poorly implemented features, and then there are UI issues that are so irrational that they’re really bugs - like having a very counter-inutitive tab order for controls on a form, or sticking “Help” anywhere on a Windows menu bar than the right-most option.
Dijkstra wrote something like “don’t call them bugs, call them what they are: mistakes.”
Those are NOT bugs. They are design flaws.
They should be given no less priority in being fixed than a bug, IMHO, but nevertheless they are not bugs.
“Needs to be changed” != bug
I see what you’re saying, although it is a bit of a nitpick. On the other hand, if a user interface is built in such away that the design intended for the user to save an item, but the net effect is that 20% of users are losing all their work, it crosses into a grey area for me. If someone went and classified that as a bug I wouldn’t get too upset with them.
In some industries clients will be tempted to try and get away with classifying as much as possible as bugs, since they may be paying for new functionality and bug fixing is maintenance that the software company is responsible for.
You’re right, of course, but you’re swimming against the tide.
“Bug”, as you well know, is a software development term with a specific meaning. Unfortunately, the word has gotten out into the world amongst the non-developers, to whom it has come to mean any software problem. I used to find this very aggravating, until I realized that it was a lost cause.
Still, this is fairly typical for technical terms that escape into the mainstream. For example, I’m sure lawyers go nuts over “normal” usage of lawyer-ese by us non-lawyer types. I’m still convinced “tort” is the root form for “tortilla”. 
The severity of the issue is NOT what defines it as a bug. If 100% of the users lost all their work because of the shitty UI, but this was the result of a design flaw and not a programming error, it still ain’t a bug.
In every place I worked, it doesn’t matter how awful the issue is, if it was designed that way to begin with, it ain’t a bug. It may be a priority-one problem that needs to be fixed, and the worst problem the system has, and have upper management breathing down our neck to fix it ASAP, but it still isn’t a bug.
Again, “needs to be changed” != “bug”.
But what if 1% of users are losing their work. That might be a case of “PEBKAC”
(problem exists between keyboard and chair).
Even if 20% of users lose their data, it is still not a bug. I worked one summer for a retail store. We got a fancy new system to look up products. You would do a search, and the rsults would come back, sometimes on several pages. To get to the next page, you would go to the bottom and click “next”. Often you would do this several times. Until you got to the last page. In the same spot, instead of “next”, you got “log out” WTF? PISS-POOR design. But still NOT A BUG.
At my company, you go to the webpage and have 2 options
-
Click here to report AWESOMEPRODUCT errors and incidents
-
Click here to report AWESOMEPRODUCT feature requests
Freakin multiple choice. Not that hard. But no. Even when we avoid the word “bug” people still don’t think about what is going on.
Forget this bug vs. feature stuff. Where are y’all working that developers get to design the UI?
Actually, a small company with two programmers. Usually the most design guidance they’ll get is “make it look good”
Well, in that case, I certainly wouldn’t be surprised with all the complaints and feedback your getting. And if you expect a user of your software to be able to distinguish feature request from bug, then your clearly out of your mind. The average user neither knows nor cares about this sort of stuff and they shouldn’t have to. That’s your problem and if you want to make a successful product, then you’re going to have to deal with it.
I never said we were. That statement is an insult to our programmers, thankyouverymuch - We’re not making DOOM 3 or Half-Life 2 here - these are just some basic niche-specific data-processing applications we’re talking about - a 15-man team of designers, marketers, programmers and editors isn’t really needed. We’re lucky to have a boss who knows the technology industry, but isn’t a programmer, wouldn’t want to be a programmer, and isn’t shy letting us know this :). He also has a good eye for hiring talented programmers. He doesn’t NEED to give them much direction beyond the bare minimum. Just because we have a very small company doesn’t mean right off the bat that we have a poorly-designed product
In addition, I am not making a blanket statement about all end users - again I probably should have made that clearer up front. It just drives me up a wall when people don’t take the time or make the effort to READ forum descriptions and just post wherever they please. See example below.
Why am I out of my mind to have/want some basic expectations of the users? Especially when I’m talking about BETA software. Keep that in mind - BETA software - you generally won’t get the “Average” user using BETA software (unless you’re Micro$oft or Google). Your statement implies that I should assume from the get-go that the average user is dumb and lazy. No, I’m sorry, I do have higher expectations of our users and I’ll never apologize for that. I believe that people in general are capable, intelligent beings that can use a little common sense and figure out, based on the descriptions in the example below, where their question/input needs to be posted…
example: you don’t like the mauve and cosmic-orange color scheme for the application and want to give some input during the beta test. You go to the company’s website and click the link for the Beta support forums and saw the following in the forum list:
WidgetMaker ver. 2.56 beta 1
Bug Reports - Please report any error messages, crashes, glitches or other technical issues for WM2.56 beta in this forum
Feature Request - Like something, don’t like something, want to see something changed? This is the place for your input about what you’d like to see (or not see!) in this beta. Technical issues go into Bug Reports, above.
I’m sorry, but I do NOT think it’s too much to ask for people to actually think for themselves and put the request to change the color scheme in the Feature Request forum. I respect users’ intelligence about this, and, as I said earlier, I won’t apologize for that.
Software developers are much less likely to be end users of their applications than car manufacturers.
I happen to be a software developer and I find this attitude (that the developer knows best) among developers abhorrent (and yes, it is common). I explain to my developers that I don’t care if we make six figures and are writing applications for people who barely make a reasonable living. We still work for them. Our job is to make their jobs more efficient, improving both productivity and accuracy. That person who is using the software I write knows a hell of a lot more about their job than I do.
That’s not to say that developers can’t bring their own ideas to the party, as even the best end users sometimes have a problem with imagining all possibilities when attempting to determine how to make the software perform well for them. In this situation, it’s an iterative process, where you prototype ideas and let the end users try it out and let it sink in a bit, then making the decision as a team, repeating the process after refinement as necessary. The best software projects I’ve been a part of have had end users involved from the beginning, long before the first spec was written. The worst have consistently been developed in a vacuum, then placed on the user’s desktops.
I did not say they are likely to be end users of their own applications. I meant they are likely to be end-users of computers, in general.
Except developers don’t use software in the way normal people use them. At the very start of any decent UI Design class, it gets hammered into you straight away that developers are about the worst group you could choose to test your software. Especially developers who played an active role in developing it. Developers by virtue of their long experience use and learn software so radically different from ordinary users that taking developer feedback into account can actually harm your software by making it harder to use.
One of the reasons why linux is having such a hard time cracking the desktop market is that, overwhelmingly, the software written for it is written by developers for developers and tested with developers.
Well, I certainly didn’t mean it that way. But what did you expect when you got into the software industry? Did you seriously not expect to be inundated by stupid end users? It’s part and parcel of the whole software business and it’s a very valuable part too if you know how to use it right. It’s sort of like a person wanting to be a concert pianist and then complaining about all these boring scales that they have to do. If you want to make software where you just sit around and bang out cool pieces of code and then get lots of emails telling you how cool you are, then open source it. If you want people to pay $30 for it, then expect lots of people complaining about how it isn’t perfect for them.
It’s not that they aren’t intelligent or capable, it’s just that the average user doesn’t think in the way a software developer thinks. To a software developer, a lot of that behaviour seems “dumb or lazy”, but getting into the minds of a user is one of the highly valued traits of a good UI designer and it’s not a very intuitive process. It takes training and years of practise to really get it right and even then, occasionally you make huge boneheaded mistakes.
Users never read. Users NEVER read. That’s one of the first things that gets hammered into you when you learn about UI design. It’s not that they’re stupid or lazy or incompetant. It’s just that people will go to extraordinary lengths not to read any text. It’s part of human psychology.
And everything about your software process should make it so that the user has to read the minimum amount of information in order to use your product. If that means collapsing feature requests and bug reports into one form and seperating them out manually later, then so be it.
Look, I’m not disagreeing with you - this is the whole reason for the Pitting, that they DON’T or WON’T expend the amount of brainpower necessary to make common-sense decisions.
It won’t matter how the workflow is designed, it doesn’t matter how big a neon sign we put up showing them where to post, they WON’T DO IT - THAT is what I’m pitting.
Personally, if you hear me say, “it’s not a bug that the save button is to the left of the close button” I mean it’s not a bug, as in, “we did user studies that concluded that the save button should be to the left of the close button, and the fact that you disagree IS NOT A BUG. It is by design.”
So when someone says that, don’t automatically assume that it’s because they don’t know what a bug is.