The whiteboard: Tracking usability issues: to bug or not to bug?

What does your group do to record and track usability problems? How do you determine their severity and communicate them to the rest of the project team? If you've ever been stymied by this challenge, read on! Chauncey Wilson and Kara Pernice Coyne have developed two approaches, somewhat different in implementation but highly compatible in concept. Although the difference may seem non-trivial, it strikes me that the two methods apply to different kinds of organizations. Chauncey's may work better when the usability group is small, new, or struggling to gain credibility; Kara's, when it is larger and well established. See what you think. Most development organizations track software bugs and their severity in a corporate database, which is shared with product development and tech support teams. We find, however, that these same organizations seldom have a standard method, if any, of tracking usability issues. Usability practitioners communicate usability problems through reports, highlight tapes, and formal briefings, but are these methods adequate for tracking usability problems through successive cycles of product development? We diverge in our specific approaches to tracking. Chauncey believes that it is essential to track usability issues in the official corporate bug database. Bugs that don't get into the bug database will not be considered " official " bugs or be visible to the product development community. Although Kara agrees that it is possible to track usability issues in a bug database, she believes that usability problems are better tracked in a different