Epic Failures: Ignoring User Feedback
I have been becoming something of the usability expert on my current project at ANVIL which has easily been one of the most interesting and enlightening experiences of my Computer Science career. I have worked on all sorts of projects where I gathered requirements, produced prototypes. and presented the ideas to the project stakeholders who are on staff. On these projects, due to work terms ending or companies collapsing, this is as far as it gets.
This definitely is a decent way to start developing a project. If you really wanted to, you could continue to drive the project this way, but I’m betting that most would believe that course to be unwise. The difference with the project I have at ANVIL is how the team has reached the milestone where we are actually getting real feedback from an actual user.
What do you mean actual user?
What I mean is someone is using our software that isn’t on the same payroll as the rest of the team. That isn’t to say that we didn’t get honest feedback from our fellow co-workers. The thing is, since we are all on the same team it would make sense to overlook some of the minor nuances of the software to make things easier on us.
With an actual user, you are going to get the honest truth whether they tell you directly or not. For example, let’s sayif the user runs your software, plays with it for 10 minutes, closes it and never looks at it again. Presuming that you have selected a user that is part of your targeted audience for your software, you know that your application does not really interest them. This means you know one of the following:
- Your software does not meet the expectations of the user.
- Your software is too difficult for the user to use.
These might seem vague, but it is definitely a start. Obviously this isn’t the reaction you were looking for, but you can now discuss the problems and work with the user to make your software what they actually want. It is for this reason that the actual user should be put into the mix of your software development process as soon as it feasible in your project.
My Own Epic Failure
Going back to the title, we have the words “epic failure”. I figured I would include those words