Adventures in Usability
One of the fun things about moving across the world is that you get to play with a lot of new and different pieces of technology. From new notebooks and mobiles, through to cars and washing machines, almost every day there are new buttons to press and lights that blink in new and exciting colours. But after the excitement wears off, it's time to figure out how the hell to use these things.
Let me give you a couple of real life examples from the last few days. On Friday I picked up my new car - a Subaru Impreza (no, not the WRX :-). After handing over the keys, the guy at the dealership took me through all of the controls. Of course, having driven a number of cars over the years, I felt entirely capable of figuring out the controls by myself. And while I let him go through the motions of showing me which stick had the indicators and which had the wipers, everything was immediately obvious, despite being a brand new car (and my first Subaru).
Only a couple of days earlier we moved into a new apartment. On the first night we called up for pizza (which turned out to be entirely dodgy), but the next night it was my turn to cook in our new kitchen. Of course, having cooked on a number of stoves over the years, I felt entirely capable of figuring out the controls on the new stove. However I couldn't even turn it on, or decipher the symbols on most of the buttons, without reading the manual - and even that wasn't much of a help. Before you question my manhood or technical abilities, this is one of those stoves with an entirely glass surface with no knobs of any kind. Instead it has a number of flat buttons, most of which have icons resembling nothing i've ever seen before. It seems to cook fairly well, but when it takes 8 button presses to turn the lower right hotplate to medium high, something is very wrong.
Usability is one of those things which is completely invisible, until it's done badly - and then it shows itself as the most critical feature you can have. Usability problems are painful no matter where they strike, but with software they seem to be both more common and more painful, possibly due to the complexity and flexibility of most software systems, but also possibly because most software projects don't involve any usability experts or testing. While user interfaces are the most obvious offender, even UI-less systems such as components and frameworks can sink or swim based on usability. The first release of Enterprise Library was almost entirely about usability, since most of the functionality had been previously shipped in standalone blocks. However since it was so hard to get some of the original blocks working, most people didn't get the chance to appreciate the functionality. I'm sure there is more that the team can (and should) do to further improve usability of EntLib in the future, but I hope the investments we've made so far have made a difference.
The "real" product groups at Microsoft have dedicated funding and facilities for usability testing, where engineers watch real users struggle with tasks through a two-way mirror or video recording. (I'd have hoped that stove makers do the same thing, but I guess the lot that made my stove skipped this step). In p&p we needed more creative ways to get usability data, such as providing labs for beta deliverables and forms to capture feedback. In the world of internal enterprise projects, many go through "user acceptance testing" phases to capture usability feedback (although whether the feedback can be effectively acted upon depends on the agility of the project team). However other teams I've seen haven't used any processes to measure or improve usability, and the projects tend to suffer as a result. I'd be interested to hear what you have done in your teams to improve usability of your projects, particularly if you've had to deal with this on a shoestring budget.
Anyway, time to start cooking tonight's dinner. Even though I still don't know what two of the buttons do, at least I know enough to make a meal now. Tomorrow's task is to master the toaster. Alas, I'm not kidding :-)
Comments
Anonymous
June 11, 2007
Myself and a couple colleagues preach Alan Cooper's 'The Inmates are Running the Asylum' book...though we can't seem to make the horse drink from the water. Usability is a type of requirement (at least in the FURPS+ model), and it often over-looked. An example is the how many ERD driven UI's that are out there. It doesn't help that several frameworks encourage a ERD driven design with this whole ORM mentallity; and in and of itself ORM is a nice thing - a nice thing - not a necessary thing, but it often results in a ERD driven GUI because the typical developer can't seperate technical requirements from business requirements.Anonymous
June 16, 2007
The other day a customer asked me to give them some advice on building or acquiring a development framework.Anonymous
June 17, 2007
The comment has been removed