garann means > totes profesh

a defunct web development blog

triumphs of bad design

Wed, 11 Feb 2009 21:23:26 +0000
Earlier today, another UI engineer here at work sent around a link over Yammer (which I totally feel is underused in our organization, by the way) to a post on the difficulty of creating a decent UI. I enjoyed reading it. I always enjoy reading those things. I store these tiny little patterns about the size of buttons and the position of sidewalks away, just in case they ever come in handy in my own work. In a perfect world, it would be true that every UI Don't had a negative impact on someone's bottom line, be it in lost profits or the cost of hiring more customer support reps. But that's not always the case and I think the flipside frequently goes unacknowledged in circles where we like to talk up good design as though it would rain puppies and cure cancer. What do you call it when a UI is successfully and maliciously bad? Is it really bad design anymore? My first example of this is the ATM in the lobby of my building. It has developed a neat trick recently, where it asks you to enter your PIN and then waits long enough to make you wonder whether you actually pressed the Enter button to submit it (these buttons being the flat, unsatisfying kind that give little more indication they've been clicked than a solid metal plate would). It doesn't give any indication that it's working or loading or whatever it is, in fact, doing. If you try to click again, the click is saved and applied to the next screen, where it takes you into the process of making a quick cash withdrawal of $40. This probably isn't a big deal for most, but I'm guessing there are other people like me out there who, anxious to finish up with the ATM and go home for the day, feel too invested at that point to risk hitting Cancel, digging their debit cards back out of their purses, entering and waiting for recognition of their PINs, etc., and so continue to go through the quick cash process without being entirely sure which option they've selected. In my case, I was hoping it was the regular withdrawal and that I wouldn't have to start over. This ended up costing me $6, instead of the usual $3, because I needed more than $40. The bank could improve their machine for me by giving a clearer indication that I'd pressed the button to enter my PIN, but why would they want to? They just made $3 extra off me. Score a point for bad design, the bank, and the Concord fallacy. I've got another one, this one specific to front-end development. One of the many reasons sane developers have moved away from the use of tables for layout is that tables slow down loading. The browser will draw cells in the order in which they're defined, meaning large images or content that takes a long time to serve keeps the rest of the page from appearing until that cell is completely loaded. I had an experience with a shifty "free trial" offer where the fine print informing me that they'd continue charging my credit card and sending me their impotent and overpriced product was in the very last table cell on a long page laid out with lots of nested tables. Since the page was just a verification, I clicked the Order button without noticing that the page was still loading, meaning the fine print hadn't even shown up yet. In hindsight, I was kind of impressed at the way they'd used ancient coding techniques to prevent their customers getting information that might make them click Back, while still staying within the letter of the law. Anyway, so what do you do in those situations if you're the front-end developer (or the ATM-button-solderer) tasked with doing something you know is wrong from a usability perspective? What if you tell the boss and he refuses to let you fix the problem? I've had clients say to me, "Well, we don't want to make it too easy to find..." referring to discount codes or contact addresses or refund request buttons. Is there such a thing as black-hat usability? Is it as valid, academically, as the sort that makes users' lives easier?