/dev/usability 24 Apr 2007 09:41 am
How to Gather Use Case Priorities: Part Two
User Requests
This is probably the most common form of Use Case Prioritization that ends up affecting the design of a software product. However, its usefulness, like the Dev Team’s input, can be contradictory, confusing, and often inaccurate. Users will say they want one thing, such as “more online features!” when they really didn’t use half of the online features from last year; they want the same online features from last year, only they want them to be better organized. They’ll say “we want Super Hero mode!” when they don’t even know what they could be getting instead. The problem with talking to end users to drive priority is that the loudest end users, the so-called alpha consumers, are going to ask for one thing very loudly. Since this sort of data gathering is usually a one way street (i.e., it is uncommon for a software company to bring all of their users into this discussion; instead “hard-core” users will get asked for feedback, or, even worse, video game reviewers and websites will be consulted to determine the Next Big Feature.
Even anonymous surveys can’t really provide you with much useful feedback; most users will only participate if they get something in return, and even then most people will just do the minimum amount of thinking required to get through the survey and get to their prize.
Wow, it actually sounds like it’s pretty terrible to talk to your users! To be fair, they do have the information you want, it’s just difficult to communicate with them in a way where you can turn their actual desires into feature requests that will help you schedule a more solid product. That’s where some slightly more difficult Use Case Priority Mining comes into play…
