The user testing rope-a-dope

It's important to distinguish between situations when a development team is not implementing your design because they don't have the resources to do it and when they are not implementing your design because they disagree with it (or, perhaps, think that design doesn't matter). Obviously the correct response to these situations is different. The trouble is that sometimes it's hard to tell the difference between them, because developers sometimes use resources as an excuse to not do designs that they really don't believe in.

I was talking to a colleague yesterday who was having an issue with her development team. The developers on the project had created a design that (I'm not making this up) utilized multiple levels of tabs, as well as an bizarrely-placed "action button" that served as essentially a menu item. She provided an alternative design that fixed these problems. The response? The developers want her to run a series of usability sessions to verify with users that their original design is actually a problem, because they are short of resource and don't want to fix this if it isn't necessary. I call this the user testing rope-a-dope. Amazingly, this meeting happened after I wrote yesterday's blog entry about most design issues not requiring user input... using tabs-within-tabs as an example! We don't need to talk to users to know this is bad design. Heck, if the users told us they liked the tabs-within-tabs, we'd ignore them as statistical anomalies. The developers are trying to use user testing as a way to delay the decision long enough to make changing the design impossible.

It's amazing to me that a team would request UX support and then not listen to the UXer's guidance on design.