ben is on the inter.net

I mentioned a few days ago that prioritizing Use Cases is an important part of figuring out which features your product should have. But how do you determine which Use Cases are high priority and which ones won’t affect most users? Why, you ask them of course! Actually, there are 5 main ways to gather the data for your Use Case priorities. I’ll go through them from cheapest (available to all development teams) to most expensive (available to development teams with a budget).

Development Team Verification

This is by far the cheapest way to gather Use Case data: ask the members of the development team to try and priroritize the current feature set from “all users will do this” to “no users will do this.” Experienced members of the team may provide extremely valuable feedback…

However, if the development team is comprised mostly of people who will not be using this product, most of the feedback gathered here should be taken with a grain of salt. For instance, and this may come as a bit of a shock (unless, well, you had ever met me before), I’m not a huge sports fan, and only rarely would I pick up a sports game. My feedback on whether or not users would hit a feature would probably be wildly inaccurate. Granted, I do know video games, and I can usually tell when a given use case would be low priority if it is clunky for the user or if it violates any usability or design expectations. (Also, I’m a cheater and I would do research before responding to any of this, but we’ll get into that later)

In short, the dev team is not the only source of feedback that the design team should consult when deciding the priority of a feature. More soon!

Trackback This Post | Subscribe to the comments through RSS Feed