Is it a bad sign if users submit bug reports for things that are by design?
Does it typically mean that the application is confusing or unclear, or should I just chalk it up to a one-off user mistake unless specifically stated?
(I don't actually have any such reports. This is a purely hypothetical question about whether or not the existence of by-design "bugs" is a bad thing.)
Is it a bad sign? I think it's a warning that's worth looking into, but I also think it's bound to happen.
When people submit any kind of feedback to me, I try to filter it into three buckets:
Bugs are when something obviously doesn't work the way you would expect, nor the way the user would expect. Like, it asked me for my name, I entered "Scott", hit enter, and it said, "Hi Joe!"
This is like "I know we never talked about this, but can the program infer from my mouse gestures that I'm left-handed and move the OK button to the left side of the screen?" This is when the current behaviour matches both your and the user's expectations, but they want to change the expectation.
This is when you would expect one outcome from a scenario, but the user expects a different outcome. Sometimes this becomes a feature request, if they just haven't communicated their expectations, but they thought they did. Sometimes this becomes a bug if your expectation is proven to be wrong.
However, many times you have knowledge that the user doesn't have. What if they said, "On this screen, I can add a record for myself twice with the same first and last name! That's obviously a bug!" Your response might be, "There are lots of people in the world with the same first and last name, so we don't require that combination to be unique. We have a cleanup task that runs at night and emails a Possible Duplicates Report to customer service when it thinks it detects a duplicate with a similar name and address, and asks them to check it manually."
So you should read every bug report, but most complex systems are going to have bug reports that are really just feature requests, or possibly a mis-communication of the requirements. Not understanding the underlying complexity of the real world is probably the biggest source of these issues.
This wasn't touched on in previous answers thus far so I will add that it could also be a sign of an ignorant user base. I don't use the word "ignorant" in a derogatory or condescending way, merely as a way to express that they are without proper knowledge or education in their domain or of the complexities of the software itself.
Most users are not aware of just how complicated software has to be to meet certain requirements. Something to the effect of 80% of effort goes into only 20% of functionality (fringe and exception cases).
They sometimes don't understand why the software inherently needs to behave in a certain way, many times to prevent a multitude of defects or corruption of data, etc...
This isn't worrying as this becomes better with clear and concise documentation and communication.
If you have a user that is an expert in their field, you could have a major problem. Imagine an accountant that finds your software, by design, isn't following general accounting procedures or an engineer who discovers you have an incorrect formula. This shouldn't be too hard to research to see if they are correct. Redesign and fix it if needed-quick.
One opinion on a particular UI feature or a field they think should have a currency symbol or some other formating, should be considered, at least until you get more feedback. Researching this could be a little more difficult.
By-design bugs in my experience means that your use cases don't fit your real users. Try reading about using real users for your use cases ( just giving them names and a thumbnail description does wonders for the quality of use cases.)
When prominent OS vendors say "this behaviour is by design" they generally had ease of implementation or commercial advantage in mind. If that's not you, try to find out your users real skill-set and relationship to your software. Do they use it all day ? For fun ? Once a week because it replaced the TPS forms ?
The UI should follow The Principle of Least Astonishment - repeated bug reports on a feature that works as designed are an indication that this principle has not been adhered to correctly.
Not necessarily. It could be that the reported bug is in a use of the software which is just outside of its originally defined scope. Consider software which was designed to do A, B, and C (for a trivial example, draw lines, triangles, and rectangles). If D is a logical next step (e.g. pentagons), the user may assume it should do that as well, and that not doing so is a bug. But if this is outside of the original scope, it's not a bug. It could instead be an oversight (bug) in design, or a gray area in the specifications, or a different set of assumptions made by the developer and the user.
(Edit - added my comment to the answer per @Marjan Venema's suggestion.
There are two kinds of bugs: the functionality doesn't match the programmer's intentions, or the functionality doesn't match the requirements. Programmers have a tendency to focus on the former to the detriment of the latter. To put it simply, if your users are reporting a lot of "by-design bugs," your requirements aren't what you think they are.
I believe its a bad sign mainly due to the fact that the design is not generic and users requirement is not fully understood/analyzed.
I see two catogories of design, - Design by accident. - Design by intention.
Design by accident leads to such issues frequently and cannot sustain.
I'd like to add to maple_shaft's answer about users' "ignorance". You also have to keep in mind that 90% of the users will only care about their own experience and way to use the system. They don't care about other users, why should they? It's our job as designers/developers to take in input from all the different kinds of users and make something that fits everyone as good as possible. Most of the times you can't make a solution optimal for everyone.
But of course you need to read and evaluate feedback from your users! They are, after all, those who use your creation!
The users submitting the bug requests were generally not consulted on the design so it is not surprising that they see things as bugs that were deliberate design decisions. To a user anything that doesn't work as expected is a bug.
I have found the problem is often a sign that the BA or PM only got requirements from managers not actual users. What managers expect of the system is often vastly different from what the people entering the data actually need. I was taught to collect data directly from the actual users, but most BAs I have run into lately only talk to managers (and generally relatively senior managers at that).
