Pragmatic Marketing has a really good article on how McAfee reduced its support costs by improving usability. The article also contains a list of 23 tips to improve a UI. I’ve summarized the list here, but it doesn’t do the full article justice.

Start the UI design before you build the product.

Understand your software from a user’s standpoint.

Get feedback through task-oriented use.

Segment the process into logical chunks.

Never shut the product down.

Let user demand defend against code creep.

More is nearly always less.

Use your UI to give the user a sense of context.

Don’t offer direction, and never assume.

Resist the urge to make a quick fix.

Treat UI as an ongoing program, not a one-off.

Get a manageable but representative group.

Choose active, willing, and unbiased users.

Reward your early adopters by acknowledging their role.

Get your developers (and yourself) into the right mindset.

Do-it-yourself design is nearly always a bad idea.

Make the designers a part of the development team.

Don’t let technology overpower usability.

Bring the engineers into the UI calls.

Find an internal UI champion.

Contain costs by including the designers early.

For the best UI examples, look to consumer software.

Know how to tell if your UI might need work.

Make sure you check out the complete article for much more detail.

Joel Spolsky recently wrote a post on his blog making a case against disabling menu items. Here is the gist of his argument…

“Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.”

As much as I respect Mr. Spolsky, I completely disagree with his assessment.

In my book, a menu item is a form of navigation. And I believe that all navigation interfaces should always display all of the options, even if some are currently not valid. For instance, look at the back button in FireFox.

Notice that the button is visible yet disabled. That’s because I have gone back as far as I can go. This is a nice little reminder of where I’m at. I’m at the first page. Notice also that the stop button is visible but disabled. The page isn’t loading so clicking it is pointless, but it gives the interface consistency by displaying anyway.

Menus work the same way. Look at this menu from the MS Word 2000.

Again, every option is right there. If the option isn’t currently valid, it’s grayed out but still visible. Every time I look at the menu, everything is in the same place. I get comfortable with the layout. I don’t have to think every time I want to find something.

And that’s how it should be.

Disabling out of context menu or navigation options instead of hiding them does not confuse the user. In fact, it does just the opposite. It keeps the interface consistent. And it offers little reminders of where the user is at.

Ok, first of all, did you realize there was a National Hot Dog & Sausage Council? Well, maybe you did if you were watching American Eats on the History Chanel like I was a few minutes ago.

I just found this Hot Dog Calorie Counter at the National Hot Dog & Sausage Council’s website. I’m not sure how often anyone needs to calculate the calories in their favorite hot dog/condiment/bun combination, but if you’re gonna do it, this tool is pretty dang easy to use.

This is a very cool article. Nika Smith explains just how Gmail chat came to be. Here’s an excerpt.

“Often, the features we launch seem so simple that you might think they’re the result of blatantly obvious design decisions. In fact, every feature is subjected to a healthy dose of scrutiny within the Gmail team, and usually that includes rapidly iterating on designs by collecting user feedback, learning what works and what doesn’t, and improving on our work based on this knowledge.

Gmail chat is a great example of this…
We took each of these ideas into the usability lab where users were asked to try them out and tell us what they thought. From these studies we learned that chatting was one of many multi-tasking activities that users performed, and that chats needed to be quickly available at any time, not just within a single email or on a separate page. So we tried a design reminiscent of a sticky note that stayed up on the page at all times:…”

Nika’s complete article can be found at the Official Gmail Blog.

I have no idea if this is real, but it’s pretty funny either way.

“Let me give you my experience from yesterday.

I decided to download (Moviemaker) and buy the Digital Plus pack … so I went to Microsoft.com. They have a download place so I went there.

The first 5 times I used the site it timed out while trying to bring up the download page. Then after an 8 second delay I got it to come up.

This site is so slow it is unusable.

It wasn’t in the top 5 so I expanded the other 45.

These 45 names are totally confusing. These names make stuff like: C:\Documents and Settings\billg\My Documents\My Pictures seem clear.

They are not filtered by the system … and so many of the things are strange.

I tried scoping to Media stuff. Still no moviemaker. I typed in movie. Nothing. I typed in movie maker. Nothing.

So I gave up and sent mail to Amir saying - where is this Moviemaker download? Does it exist?

So they told me that using the download page to download something was not something they anticipated.”

You can read the full article/email at seattlepi.com

Though I spend an abnormal amount of time looking at other peoples’ design work (especially people like David Airey), I am not a designer. Yet I still design my own logos when there is a need–because–quite frankly–I enjoy it.

Recently it was mentioned to me that the old logo for this site was pretty bad. In fact, as my designer friend pointed out, “it looks like an upside down pair of pants.”

Old logo…

Once my ego stopped reeling from the hateful arrow of a statement it had been pierced with, I realized he was right. And quite frankly, intentional or not, a pair of upside down pants is a dumb logo. So, I created this new logo.

I think it does a much better job at conveying the concept for this blog: a study of usability. I haven’t chosen a color scheme yet, but I wanted to start using it right away, so right now its still in black and white.

New logo…

And since I had a nice new logo, I had to pick a new WordPress theme to compliment it. I think this new theme is far more usable then the old one.

I welcome any comments on the new logo.

Thanks.

Yeah, I know these types of lists are a dime a dozen, but I still find them interesting to read. Here is Business Week’s Top 10 Commandments of Web Design…

Thou shalt not abuse Flash.

Thou shalt not hide content.

Thou shalt not clutter.

Thou shalt not overuse glassy reflections.

Thou shalt not name your Web 2.0 company with an unnecessary surplus or dearth of vowels.

Thou shalt worship at the altar of typography.

Thou shalt create immersive experiences.

Thou shalt be social.

Thou shalt embrace proven technologies.

Thou shalt make content king.

Check out the full Business Week article.

User Interface Resource Center

The User Interface Resource Center (UIRC) provides free articles and White Papers written by industry leaders about user interface design and rich Internet applications (RIAs). From business strategy and implementation to hands-on techniques, this site is packed with valuable content.

Mr. Nielsen does a great job at keeping us honest in his latest Alertbox article for June 23, 2008.

Here’s a sample.

“We often observe users who hesitate before clicking or initially misinterpret information, but then correct themselves before they get into trouble. In such cases, it’s tempting for the design team to simply utter a collective “whew” - we almost had a usability problem, but our design won in the end.

Certainly, if your design ultimately works for your test users, you don’t have high-priority usability issues. But miscues are still symptoms of something you ought to correct (once you’ve fixed the design disasters, of course). Correcting miscues is important for two reasons:

• A miscue wastes time. A hesitation might last only a second, and a misinterpretation might be cleared up in five seconds. But that’s still lost time. For a website, slower user performance translates into less-than-smooth user experience; the site just doesn’t quite feel right and thus reduces customer satisfaction. For an intranet, every wasted second lowers employee productivity. And, because miscues happen hundreds of times per day, they can add up to a full workday over the course of a year.
• Some users are less lucky. Even if all your test users overcome a miscue without getting into real trouble, some users will in fact click the wrong link or act on their misinterpretation. We can’t test millions of users; anything that’s error-prone in a test will, in real life, trigger an actual error in a small percentage of cases. If your design is only slightly error-prone in user testing, you’ll observe miscues as symptoms rather than seeing actual mistakes. Real errors will still happen, just not very frequently.”

Check out the full article…

VKI Studios has an excelent treatment of the question, What makes a design intuitive? Here’s a sample.

“Often when creating or analysing an interface design we are faced with the question of whether or not it is intuitive. The creation of an intuitive interface is something we strive for, but beyond a vague sense of making it “easy to use”, is it always clear what we mean by an intuitive design?

Typically, people will rely on some instinctive gut feeling to determine an answer to this question, summoning on experience, knowledge of user behavior and usability best practice. And as useful as these are, this idea of an intuitive design can still seem a bit of a fuzzy concept.

One of the smartest ways in which I’ve seen this problem addressed was suggested by Jared Spool. He offers a good way of describing this issue, which helps grasp in an informal way, the extent to which a design or interface is intuitive. He suggests, that in order to successfully interact with an interface a user requires a certain amount of understanding or knowledge. They need knowledge of both the interface and the subject area that the tool works within in order to perform tasks…”

Make sure to read the rest.