More bad behavior
Submitted by LauraDeVilbiss on Tue, 23/08/2005 - 01:20.
Thanks for all the great comments! And, do check out the IT Conversations site, there is TONS of great stuff there.
Now, I've been giving this a bit more thought and wanted to come back to the topic. In the original post, and in the following comments, we focused on the wrath, or blessings, users can bestow on a horrible, or wonderful, application…all outside of the application. But, I'd like to think about the possibility of what kind of bad behavior an uncomfortable or annoying application might inspire users to commit inside the application. '
For example, MS applications crash on me so frequently and the consequential “error report” message comes so late, I NEVER "send error report" back to the vendor Why would I? 1. My app has crashed, 2. My PC is probably still processing away to resolve all the binary tangle, and 3. I have NO idea what really gets sent to them and what they'll do with it. This last one I don't bring up from a security standpoint, although that's more than valid, but from the standpoint of: I have no idea what the message is that I am communicating or the data included it. I happen to like to be in control of the communications that I send out, even if from my virtual personality. Furthermore, I seriously doubt they are going to do anything with it. In this case, the functionality is so aggravating to begin with and shrouded in mystery by the end that I try to avoid it entirely.
But…supposing MS actually does get valuable information when users send error reports and uses that information for the betterment of its products, just supposing? My spiteful behavior is a huge disservice. And I speak from the heart here, as a help desk soldier from back in the day. This could be a significant loss of valuable data, even just tracking the sheer volume of errors. But, the reasons above cause me to not send them this data. And, ultimately, at the bottom of everything, is the fact that the application affronted me and I retaliated the only way I could. This may not put me in the softest of lights, but it's a reality that I think occurs far too often, and certainly more often than vendors and development teams want to acknowledge, much less own up to.
So, on to other users who might behave poorly in response or reaction to a badly designed application. How many times have you seen users select or enter the wrong data just to bypass a part of the system that is useless to their business process or simply slows them down. (For example, not answering a question in a way that takes them to a large screen that just doesn't get to the point of the matter. Or, choosing one of the top options in a much too long drop down list because it just takes too long to get to the right, or better, choice.) Now, I'm not saying that this is ok, or that the users should just do this. But, what are their options? Most likely they're stuck without an avenue for escape. The tool is purchased and they have to use it, or the development team already didn't listen to them through the previous iterations or releases. They are what Alan Cooper calls "survivors" and they are simply gritting their teeth and trying to get through it. So what we, well at least I, see here is that in poorly designed software, sometimes bad behavior benefits the user. Aside from creating disgruntled users, the resulting bad behavior can lead to serious application malfunction, loss of data and data integrity as well as intellectual capital that can be invaluable to the business that is trying to capture it. And, of course we test against all of these scenarios. But, wouldn't it be better if the application prevented it in the first place?
Furthermore, it's simply not right to expect the users to be able to articulate all the interface subtleties that would make their accounting, or medical office management, or tax program meet their needs and be a joy to use. Of course you can ask them if they like the application and if they want any changes. Sometimes they do have things they like and don't like and things they would like to see changed, and those changes should be responded to. But, ultimately, asking a user to define the intricacies of the interface of an application is like asking a scuba diver if the XYZ telescope is sufficient to view a particular star out in the cosmos. They are not very likely to know. To most people they're all just twinkle, twinkles out there. But, what we do know is if we can see the star or not. And, imagine if, say, a scuba diver had to tell a telescope maker how to BUILD a telescope that would allow them to see that particular star easily and accurately. Scary!
So, to sum up, my point is that there are tipping points both inside and outside of software applications that can be extraordinarily detrimental or incredibly positive, depending on the quality of the application design and user interface. I for one would be much more likely to send MS those error reports if I saw them only on occasion!!
Please comment with your examples of bad user behavior within applications!
Now, I've been giving this a bit more thought and wanted to come back to the topic. In the original post, and in the following comments, we focused on the wrath, or blessings, users can bestow on a horrible, or wonderful, application…all outside of the application. But, I'd like to think about the possibility of what kind of bad behavior an uncomfortable or annoying application might inspire users to commit inside the application. '
For example, MS applications crash on me so frequently and the consequential “error report” message comes so late, I NEVER "send error report" back to the vendor Why would I? 1. My app has crashed, 2. My PC is probably still processing away to resolve all the binary tangle, and 3. I have NO idea what really gets sent to them and what they'll do with it. This last one I don't bring up from a security standpoint, although that's more than valid, but from the standpoint of: I have no idea what the message is that I am communicating or the data included it. I happen to like to be in control of the communications that I send out, even if from my virtual personality. Furthermore, I seriously doubt they are going to do anything with it. In this case, the functionality is so aggravating to begin with and shrouded in mystery by the end that I try to avoid it entirely.
But…supposing MS actually does get valuable information when users send error reports and uses that information for the betterment of its products, just supposing? My spiteful behavior is a huge disservice. And I speak from the heart here, as a help desk soldier from back in the day. This could be a significant loss of valuable data, even just tracking the sheer volume of errors. But, the reasons above cause me to not send them this data. And, ultimately, at the bottom of everything, is the fact that the application affronted me and I retaliated the only way I could. This may not put me in the softest of lights, but it's a reality that I think occurs far too often, and certainly more often than vendors and development teams want to acknowledge, much less own up to.
So, on to other users who might behave poorly in response or reaction to a badly designed application. How many times have you seen users select or enter the wrong data just to bypass a part of the system that is useless to their business process or simply slows them down. (For example, not answering a question in a way that takes them to a large screen that just doesn't get to the point of the matter. Or, choosing one of the top options in a much too long drop down list because it just takes too long to get to the right, or better, choice.) Now, I'm not saying that this is ok, or that the users should just do this. But, what are their options? Most likely they're stuck without an avenue for escape. The tool is purchased and they have to use it, or the development team already didn't listen to them through the previous iterations or releases. They are what Alan Cooper calls "survivors" and they are simply gritting their teeth and trying to get through it. So what we, well at least I, see here is that in poorly designed software, sometimes bad behavior benefits the user. Aside from creating disgruntled users, the resulting bad behavior can lead to serious application malfunction, loss of data and data integrity as well as intellectual capital that can be invaluable to the business that is trying to capture it. And, of course we test against all of these scenarios. But, wouldn't it be better if the application prevented it in the first place?
Furthermore, it's simply not right to expect the users to be able to articulate all the interface subtleties that would make their accounting, or medical office management, or tax program meet their needs and be a joy to use. Of course you can ask them if they like the application and if they want any changes. Sometimes they do have things they like and don't like and things they would like to see changed, and those changes should be responded to. But, ultimately, asking a user to define the intricacies of the interface of an application is like asking a scuba diver if the XYZ telescope is sufficient to view a particular star out in the cosmos. They are not very likely to know. To most people they're all just twinkle, twinkles out there. But, what we do know is if we can see the star or not. And, imagine if, say, a scuba diver had to tell a telescope maker how to BUILD a telescope that would allow them to see that particular star easily and accurately. Scary!
So, to sum up, my point is that there are tipping points both inside and outside of software applications that can be extraordinarily detrimental or incredibly positive, depending on the quality of the application design and user interface. I for one would be much more likely to send MS those error reports if I saw them only on occasion!!
Please comment with your examples of bad user behavior within applications!