Rails et al

I just started reading “Don’t Make Me Think” by Steve Krug, which I like very much.  I have only completed the first chapter, but I like the central premise, which is as follows:

Don’t design your site in such a way that users have to think about how to move forward on their desired tasks.  If you do this, your site will be perceived as better functioning.

A lot of this has to do with some of the following as examples (there are many more in the book):

• Easily understood labeling so that users don’t have to pause to figure it out.
• Using buttons for actions as opposed plain text or flat graphics (so they don’t have to mouse over to see if clickable)

I remember doing an informal usability assessment of a product where I had struggled with flat graphic buttons that look like labels.  It looked slick, but I had to spend too much time trying to figure out how to work it.  This needs to be balanced with looking old-fashioned, as a good looking application can also cause people to perceive it to be better functioning.

After reading this, I find myself becoming more sensitive not only to the web site I am trying to create, but also one I was using recently:

• I had to go through a series of steps, but I had no feedback on how many steps there were, and how far along I was.  Thus, I had this big unknown on how long I would be stuck in front of this application, distracting me from the task at hand.
• What I was reading was displayed in slow steps; but when all the content was delivered, I was given no indicator on the task being complete or not.  Thus, I had to keep thinking about whether the sub-task was done, instead of being able to fly ahead.
• I had a done button that was used for two different sequential tasks.  When I finished the first task, I spent a lot of time trying to figure out how to move on as this was not clear.

Jared Spool visited us at a previous company and asserted that one of the most important aspects of good usability was having all the engineers striving for good usability, as opposed to blindly working with a usability team.  How much stronger is that than giving a bunch of engineers a usability style guide and hoping to get usability from that?  I definitely buy into his book, and look forward to completing and writing more about it.