Monthly archives for September, 2011

I once worked for an organization that created server software that had very little interested in creating a usable interface. Following a few acquisitions, I was tasked with trying to unify the web-based administration consoles for the various aspects of the server.

I tried for months to convince the engineering management that they need to spend some additional effort on enhancing the UI of their product line. I made all kinds of appeals, mostly on ROI, but never seemed to get through. Finally I decided that I would move up the management chain and talk to the vice president of engineering for the division. He was a very knowledgeable person and seem very interested in letting me help the engineering team to understand usability and to enhance the interface—at least on the surface. He told me that as an initial project that I should identify and file bugs for the “Low Hanging Fruit,” and they will be able to at least get this fixed in the next release. I never filed bugs into a bug tracking system before, so I thought that this would be an interesting experiment.

The user interface screens for the server administration consoles had never really had a interface Q/A. There were so many spelling errors, button order inconsistencies; there was no naming or style convention. I decided to file a single bug for each occurrence of one of the many types of bugs. I probably still have the record for the number of single bugs files within a single day – 300, and the most filed in a single week, over 1500. They wanted a list of “Low Hanging Fruit” and I gave them enough fruit to run their own fruit stand.

I thought that filing so many bugs would get the attention of the development manager, and that they would have no choice but to address my concerns about the interface quality-or lack thereof. Well that strategy totally failed. But I did learn that in order to get anything fixed, you do have to have it filed as a bug (or enhancement) in a bug tracking system and that the bug has to be clearly understandable, and be actionable.

Here are some of the elements that I have found make a good bug:

· Provide a catchy title (Like the “Mexican jumping bean” bug) so that your bug is discussed — at least in jest — during the bug triage meeting.
· Write a very clear description section — Make sure that your description explains the bug in simple terms. Make sure to also provide an indication about how pervasive this bug is
. Identify which UX principle the bug violates. — I often use Jakob Nielsen’s well-known heuristics. ( http://goo.gl/3fYx )
. Explain how the bug can confuse/cause the user to make a mistake.
· Provide very specific instructions on how to replicate the bug. – This is probably the most important, because if someone cannot see the bug on “their” computer, this bug will be ignored.
· Provide a recommended solution to the bug – You don’t want to get trapped into an interface Q/A role, so make sure that you are always provide easy ways to solve the issue.

You have to keep in mind that most development teams have a daily or weekly triage meeting where they examine the current bug stack, and then rank and hopefully assign resources to work on them. If your bugs do not stand out as important, they will be assigned to the next release, or worse get assigned the dreaded “will not fix” tag and be completely ignored.

Sites that you should visit

The Usability People
The Usability People are a consortium of Usability and User Experience (UX) professionals that provide User Experience (UX) consultation and testing services to clients across the globe.

Healthcare Usability
Healthcare usability is the fastest growing sub-set of the User Experience field. If you are interested in HIT, and EHR usbility, this site is for you

UX Books on Amazon
If you are serious about learning more about User Experience (UX), we recommend these books.