This blog entry might be controversial. Fair warning.

A few years ago one of my teams was responsible for the design of a set of developer tools. One of the engineering managers delighted me when he emailed me a list of UX deliverables that he wanted to talk about.

That was great: when the engineering manager has a list of UX deliverables, that is a huge win. Many times getting UX deliverables onto an engineering manager’s radar is an uphill battle. The list means that design is important to the manager. I read over the list. It was great. It had designs needed, icons, even a usability test.

I agreed with everything on his list except for the usability test. It was a strange position to be in. More often than not, the design team, myself included, would push for usability tests. This time I didn’t want to do one.

I wandered over to his office, and agreed to the stuff on the list. But when we got to the usability test, I said “I’m not doing that.” He said that it was critical to the success of the project. (Again, under normal circumstances, music to my ears.) I said no. He said “Why?”

“Before coming to this meeting, I looked up the last usability test we did. It was completed a a year ago. Your team participated. They helped design the test, vetted the participants and attended the sessions. The usability test could not have been done better. We filed bugs for each issue, and included fixes. However, none of the bugs have been addressed, some of them haven’t even been read.”

He said: “We must do a usability test.”

I said: “What for? If we do a test, all we’ll find are the same issues we found the last time that haven’t been addressed.”

He still insisted on doing a test. After a bit of back and forth I asked if he had a list of requirements for the release. If there was a requirement for a usability test, I would sign off that a usability test and claim that the test had been done. We would save the company a chunk of money, and a lot of angst for both teams. His team would  not have to spend time helping the Design team set up the test. Would not have to waste its time on a second test that would be ignored. I said that if he could make me believe that the test results would in some way improve the product, I’d do test, but not before. Specifically, if the bugs filed earlier could be fixed, that would be a great start. He would not agree to fix the bugs, so we didn’t do the usability test.

Moral of the story: the activities that a design team does on a project should benefit the product. I refused to do the usability test because it fit into an abstract definition of good product development, but did not include practical action towards improving the product.