This post originally created for Seattle 2.0: Major bug or vocal minority? How to Use Feedback from Product Users for the Deploy 2010 conference, but it looks like the post has been taken down since. Here is the original post:
Congratulations if you’ve got a product that has a large user base! Double congratulations if that user base is willing to give you feedback on your product!! Regardless of whether the feedback is positive or negative you have successfully established a community of users who are willing to voice their concerns to you. Now its time to respond, which is the tricky part. While its important to address the needs of users, a software product’s complexity is directly proportionatal to how many bells and whistles you are willing to incorporate to appease users. The more complex the product becomes the more design, implementation, and testing time it requires.
Before you spend anytime coming up with a solution to resolve user issues there are a few questions that should be answered?
- How widespread is this feature limitation or bug?
- Is it a show stopper and is there an interim workaround?
- What other features or user workflows is it impacting?
- What is the cost associated with fixing a bug or implementing an enhancement (time, money, introducing additional bugs)?
- What are the short and long term benefits to fixing a bug or implementing an enhancement (cleans up a slew of tangential bugs, save on customer support time)?
To answer #1 you need hard data as in how many users are actually using this feature, or experiencing this bug. Its easy for user to file tickets and be vocal on forums. To get hard data grep the logs for error and exception counts over the span of the days or weeks in which the issue was reported. Next, perform some database queries to figure out how many users are actually using the feature, that will tell you what percent of your active user base is affected.
When answering #2 realize that every user has influence especially the vocal ones! So once you’ve figured the actual percent of users its time to figure out if there is a short-term workaround. For example, is it only affecting people who use IE6? Message the workaround to your customer support staff and user forum.
The point of answering #3 is to put the fire out in one feature before it becomes a conflagration. Think system or product wide rather than just about the isolated feature that is causing the current bug.
Even in times of continuous integration there are hidden costs associated with resolving user issues. Leaving aside the fact that a fix or enhancement can cause additional problems, it also takes away time that would have been spent on other tasks. So its important to understand the business priority of fixing bugs or coming up with enhancements before allocating and spending too many resources (developers and designers).
The corollary is that a resolution might improve product’s quality and business’ relationship with its user base so its worth investigating and resolving now.
1 Comments
Comments are closed.