SteveX Compiled

I just finished reading Steve Krug’s book Don’t Make Me Think!: A Common Sense Approach to Web Usability on Safari.  The first edition was written in 2000, but it’s amazing how much of it still applies.  And not just to web usability.

The book is about web design, and how to create sites that users can use without thinking about them.  Kind of like how you walk into a room and reach for the lightswitch without first looking for it, because it’s usually in the same spot, there are strong conventions that, if followed, will enable users to use your site instinctively.  If a box looks like a search box, users will assume it’s a search box and type stuff into it.  Get it wrong and they’ll have to think about it, and web users aren’t good at that.

How much of this is true in software?

Users are usually much more invested in the software they’re using than in most of the websites they encounter, but that doesn’t mean as UI designers we shouldn’t try to learn some of the same lessons.  Both Microsoft and Apple published UI guidelines that helped define conventions that software developers have been using for the last 20 or so years to create applications that most users can find their way around with the lights out.

I have two comments on this.  The first is that from this perspective, the current trend away from standard user interfaces is disturbing.  IE7 takes away the menu bar in favour of a collection of toolbar buttons that each drop down a selection of menu items.  Office 2007 provides the ribbon bar.  iTunes has a lot of quirky UI behavour.  Plain old applications are passé. 

In some ways this is like trying to find new places to put the light switch. 

My other comment, and the one I’m really more interested in (since I don’t think I’m about to stop the swing from consistent UI design to style driven UI design on my own) is that the ways Steve does usability testing can be applied to software as well.

Good UI should also be something you don’t have to think about.  Unless you’re doing something completely new (and you probably aren’t), a dialog should fit the pattern of other similar dialogs well enough that the user already knows how to use it.  And the best way to determine whether or not you’re hitting this mark is usability testing.

A phenomenon that Steve talks about is one where companies try to do higher quality usability testing and end up going overboard.  By spending money on testers and studies and finding the right sample of users to test with, and coming up with extensive scripts and processes, the process becomes onerous.  Not something you can do on a whim.  So they end up not doing it very often.  That’s typical of every company I’ve worked for.

But that’s how you should be doing it.  Mock up a dialog, find a few users, and show it to them.  Ask them to use it, and see how it goes.  Do this often, and in a more or less ad-hoc manner.  If you have questions about how new UI should work, prototype it, and then put it in front of some users with roughly the amount of computer skill you expect your target users to have, and see how they use it.  Lather, rinse, repeat.

If you don’t approach it this way, you won’t do as much testing, and imperfect usability testing is still way better than none.

This entry was posted on Thursday, February 28th, 2008 at 10:43 pm and is filed under Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.