Soldier Ant 

From observation (and my own early experiences), I've seen designer after designer shy away from understanding this critical part of the software development process. And I've worked with some designers who are not 'shrinking violets' when it comes to articulating their designs, or defending them in hotly-contested discussions.

It's just that... when it's time to put the rubber to the road, and speak in the lingua franca of most product development teams, they... vanish. Their names are absent from bug-lists. Their seats are empty in 'bug scrub' meetings. Sometimes, embarrassingly, they cry foul loudly against some poorly implemented product feature only to have 3 or 4 immediate replies from team members... showing them the bug that's been open against that very feature for more than a month.

There seems to be something intrinsic to the bug-tracking process that repels 'the creatives' (ick, I hate that term) in most organizations. And I don't mean to imply that this problem is endemic to design, either -- I've seen product managers, sales and marketing folks who are interested in bugs at the 'weekly rollup' level (as in “is it ready to ship yet?”) but wouldn't dream of filing a bug, or -- gasp -- rolling up their sleeves and actually fixing one.

Yes, mere mortals can fix bugs, too -- not everything in the bug queue needs to fall into the lap of some poor harried developer who's still awake at 4am, 2 nights before launch. As you'll see from the points below, writing good bugs and fully owning the ones that are assigned to you will do more to buy you credibility in the eyes of your product team than any amount of 'kiss my ring' design attitude ever will. (I keed, I keed!)

Okay, enough intro. Here's my advice to you, aspiring UI designer (or arrived designer who's looking to sharpen your bug-tracking acumen):

Find an Ally

This is simple. First, find a kind soul who will explain 'the lay of the land' to you. This may vary from team to team, but here are some suggestions for great allies:

• The QA Lead: I guarantee that noone will have more familiarity with the bug-tracking system than your Quality Assurance engineer. She spends the greater part of her day looking at bugs (either confirming ones that someone else has reported, or filing her own, or validating that one's been fixed.) It's in her best interest to have you onboard as a fully-invested author and owner of bugs.
• The Project Manager: should also know the bug system inside and out. They will have bug counts, severities, estimated fix dates and the like in their heads at all times -- because, believe me, when an Executive VP asks, in the boardroom, “When can we expect to see this feature go live?”, the project manager wants to be armed with more than a shrug and a guesstimate.
• A Junior Developer: Don't bother the Sr. Architect with these nagging questions: she's got better things to do than show you the bug system. And, honestly, she's likely to be past the point in her career where she's dealing with bugs on a daily basis. You can bet she knows how to read 'em, and she can write a great one when the mood strikes. But you want to talk to a friendly and enthusiastic junior member of the team. You'll get more attention and you'll get it straight from the horse's mouth. This is the person that will (often, not always) be: reading your bugs; trying to understand them; and responding to you in the bug for clarification. (Oh yeah, and ultimately fixing them - with some exceptions.) In the world of bugs, this is your customer.

For extra credit, go talk to each of these people! (And, do yourself a favor.. take off your 'user-centered practitioner' hat and don't ask them to schedule a meeting to do some 'ethnographic research' into 'corporate bug practices and policies.' Try walking into their cubes and asking.. “Hey, can you walk me through filing a bug? I have a couple questions...” Take them a coffee, too.

Understand Your Team's Bug-Tracking Processes & Tools

• Where do I file a bug? This sounds like a dumb question (and hopefully you know the answer before you even ask it) but it's not really as trivial as it sounds. Some organizations standardize on one single bug-tracking system. Others don't. Some have no system and handle it all through email. (Run from these organizations.) Just make sure that you know exactly how other team members are reporting and tracking bugs. Bugzilla? Trac? FogBugs? (If the system your team uses is a popular one, it might be nice to research it on the Web later, too: bookmark any documentation you find, user forums, etc. These'll be very helpful if you have recurring questions or problems.)
• How do I categorize a bug? At a minimum, you should always be able to find the correct project for a bug before filing it. Ideally, you'll know enough to identify the proper sub-project or component to file it against. (Below, I'll discuss some design-specific categories that I recommend you create.) Some teams have specialized workflows (where, for instance, all bugs are entered into a generic, catch-all category, then moderators categorize and file them appropriately.) Just try to understand what everyone else is doing.
• How should I assign a bug? Or, more specifically, to whom should I assign a bug? Sometimes, there will be specific developers assigned to specific components of the product. It helps things along if you learn how to route bugs quickly and efficiently (it certainly helps maintain your credibility.) Often, it's fine to just enter a bug and leave the assignee blank. Someone (often the development manager, or a designated gatekeeper) will come along and correctly assign all unassigned bugs. Ideally, there will be designated assignees for each component of your product: so if you categorize the bug correctly, it will at least be seen by someone with the knowledge to accept it or pass it on to the right person. Again, your goal is to learn the accepted norm.
• How should I set the severity of a bug? Bugs are typically assigned a Severity rating, from P0 (Must be fixed before the product can ship) on down to P5 (Will not fix, basically.) In practice, most teams rarely assign bugs below a P3 (Well, they rarely fix them.) There are two thing to be aware of here: as a designer, you'll probably be filing primarily design bugs, which are often under-prioritized by development teams; and you yourself are probably the person on the team who is best-suited to help prioritize design bugs. So don't accept a situation where a development manager wants to institute a policy like 'all design bugs are P3 or lower. On the surface, that even sounds unreasonable. But remember... your team may be used to prioritizing P0 bugs as Bugs that bring down the system, which design bugs rarely do. And that leaves P1 to catch all of the Bugs that seriously impede system performance (which, again, design bugs rarely do, at least in a strictly technical sense.) So, to a technically-minded development manager, P3 often feels “just about right” for the type of design bugs that will drive you up a wall. At this point, the best thing to do is just understand how the team determines severity. There will be time to advocate for your bugs' severity later. (And more on this below.)
• How should I write a bug? This encompasses both general, good bug-writing practice, as well as any project-specific style points or standard information that your team expects to be included. I won't be too specific here, because bug fields will vary according to the system that your team uses, but generally you should ask your ally: “What fields are absolutely necessary for a good, actionable bug?” Ask them to show you some examples of well-written bugs for your project. Ask them to show you some bugs with a long history and a lot of activity. Ask to see an example of a crappy bug. (And then avoid writing ones like that.)
• Finally, how can I accurately Search for bugs? This is critical for two reasons: you should always search for a problem before entering a bug. It might be a known problem, and already have a bug entered. Secondly, most Search interfaces for bug-tracking systems are horrible. Like.. eyebleed painful. So take advantage of your ally's help to learn the ropes. Perhaps have them build some decent complex searches and bookmark them for you to use later. But get used to searching for bugs. (Here are some useful tips for Bugzilla searching.)

Be Respectful of those Processes

Now that you know something about how your team is using the bug-tracking system, try to fit comfortably within that process. Start slow, and take each of the following tips in order. Don't, for instance, file a dozen bugs overnight, all ranked P0, attempting to browbeat the team into addressing a bunch of lingering design-implementation issues that have been bothering you.

Read Bugs

Try taking one or more components of your product, and read each and every bug for that component. (Okay.. skim each one.) Although tedious, this is a good way to understand the current state of development for that component and it might give you a sense for the problems that the development team is wrestling with. (Which can also help explain why noone's still gotten around to making those “simple CSS tweaks” that you asked about days ago..)

Reading bugs is also helpful, because it teaches you alot about the conversational structure of a bug report. Note how your team interacts with each other in the bug: are they curt-but-cordial? polite? informal? flippant? Keep this in mind when it comes time to...

Start Filing Bugs

Okay, all of this is useless unless you actually start using the bug tracking system. Remember, the simple goal here is to join the common conversation of your product team, and do it using the tools and techniques that every one else is using. If you've followed the above advice, then it's probably time to dive in and start contributing well-crafted and carefully-written bugs.

You, of course, are a designer, so most (if not all) of your bugs will be design-related. “This feature doesn't work the way it was designed to.” Or, “that widget isn't aligning properly.” Be prepared to write complete, descriptive and prescriptive bug reports. Don't just say “this doesn't look the way it was designed.” Instead, describe (again, perhaps) exactly how it is supposed to look (or behave) and include a link to any design documentation. Attach screenshots (or URLs to screenshots that you've hosted somewhere on your company's intranet.)

Your prescription for solving the problem will be useful throughout the life of that bug: the developer will know how to fix the problem; all other team members will know exactly what your desired outcome is; and ultimately QA will be able to check the actual fixes against what you asked for. So, obviously, it's worth putting a little time into this part of the bug.

Depending on the experiences of your team in working with designers, it may come as a surprise to them when they start to see design related bugs appearing in weekly bug reports and team bug-scrubs. Be prepared to listen for folks' feedback. The team may, for instance, want you to combine a bunch of niggling little alignment fixes into one long bug. Or they may want you to do the opposite: break a too-long bug up into smaller individual ones. (Again, it all depends on the workflow and customs of your team.)

Try filing a decent handful of bugs, and then sit back for a day or 10 to monitor them: make sure that email notifications are turned on, so you get updates whenever there's activity on your bugs. Note how quickly they're assigned out to someone (or, if you set an assignee when you created them, are they quickly reassigned by the project manager or dev manager?) Did you set the right severity level? Does someone change the level? If so, who changed it? (This may be a good person to have a conversation with, to better-understand how bugs get routed.)

And start to respond to bugs. If someone asks for clarification on a point, be sure to respond (in the bug itself -- don't take the conversation to email, unless there's a compelling reason to do so.) Once you've proven yourself a reliable and responsible member of the bug-concerned community, you will no doubt begin to be CC'ed on other bugs. (Hopefully just the ones with design implications.) Be responsive to these as well.

Assign Bugs to Yourself

If you're already keeping a list of things that you intend to address for the product, consider filing them as bugs instead. If they're truly broken behaviors or layouts, then .. hey, they are bugs, right? They can also be usability bugs, where you know that a better option exists (or intend to do research to suggest some better alternatives.) If need be, ask your ally for advice on how to categorize and prioritize these.

Filing your design to-do list as bugs has a couple advantages: first and foremost, it makes your design plan tangible and visible (and helps keep you accountable to ensure that steady progress is made on them); secondly, it increases your standing with the development team -- you're a fully-committed team member, with bugs just like everyone else. (It sounds elementary to say it, but I've seen this dynamic in action time and again: owning bugs gives you a vote at the table. Shared burden has this wonderful democratizing effect.)

You should also get into the habit of filing bugs against your own designs and specifications. This is an important distinction to make: if something is spec'ed correctly but not implemented to spec, then you should file a bug and assign it to whomever has the ability to fix it. But, if something is built correctly, but your documentation or specification is wrong, then consider filing a bug against your design docs, until they can be updated and noted in the system.

This will help everyone on the team: for instance, your QA engineer who is checking... oh, say the checkout process of your new online store. She has probably built a QA plan based, in part, on your design deliverables (a process-flow, or a written specification, perhaps some wireframes or screen mocks.) If any of these documents are old and out-of-date (perhaps some approved design tweaks were made during front-end development and you never had a chance to go back and revise the spec) then .. you guessed it. Your poor harried QA person is looking at an incorrect spec, and comparing it to a correct implementation. Unless she's psychic, or unless you've entered a bug against your incorrect and outdated documentation, then odds are good that she'll do what she's supposed to do: file a bug for incorrect behavior against the correctly-working build. This is bad.

Of course, the ideal course of action would be to always keep all design specs up-to-date but, failing that, having a good list of all the known places where the spec is wrong is important too. Especially if you can get your team into the habit of filing bugs against your specs, too. Then, when you have some spare cycles to revisit your design specs, you'll have a nice prioritized, sortable list of all the problems that need to be fixed. One more benefit to embracing your bugs!

Take on More Responsibilities

At a certain point, you may be tempted to let your bugs languish. You've been filing some against yourself, some against others and people have started filing them against you. Your bug queue is long and getting longer. Can't you just go back to the good old days, when your Project Manager would come find you in the Design pit when an issue really needed your attention, and everything else just kinda... quietly worked itself out?

No. No, you can't go back to those days.

Because those days were bad. You were basically putting off your own responsibilities at the cost of other people's misery. So, tempting tho' it may be, now is no time to return to your bug-ignorant past! In fact, now it's time to escalate your bug-squashing activities! Consider taking on more responsibilities for design-related bugs. Remember those 'bug council' meetings that you were always so anxious to avoid? Or.. remember that time the entire development team stayed on-campus for 2 days and had meals brought in to do a massive 'bug scrub?' Yep, I'm asking you to jump right in and take a seat at those tables.

Bug councils? It turns out that that's where decisions about the severity of bugs take place. And discussions about how to classify bugs. Heck, that's where decisions such as 'we're not going to fix any UI bugs for this release, in order to focus on performance' can happen (unless you, the user advocate, are there to counter with some simple questions like.. “Well, why?”)

And bug scrubs? It turns out that those are where developers are being asked to close out an enormous number of bugs as quickly as they can diagnose and fix them. And some of those bugs have design implications. And.. you guessed it.. if the developers have stayed late into the night to scrub, they'll likely start 'inventing' solutions to those problems, rather than wait for you to roll in the next morning.

If you're serious in your desire to make real gains in your products user experience (and get real respect with your product team) then the droll drudgery of dealing with bugs may be exactly the place you need to start.

I'm leaving comments open, and I'd love to hear from some working designers on this issue: have you fully embraced your bugs? Has it been worth it?