A few weeks ago, I was at a customer with my buddy, Suman, and I whipped up a muddled OneNote notebook full of notes on usability best practices I've assembled from seminars, books, and personal experience. Since then, he's been bugging me to get my blog started and put the stuff up for one and all. (Anybody else old enough to remember Cameron in Ferris Bueller's Day Off? "He'll keep calling me, he'll keep calling me ... He'll make me feel guilty...")

So, here's the first installment, Shoe. Most of this is from notes over the years, so I apologize in advance for any credit omissions. I do nod with great respect to the Nielsen Norman Group, Bruce Tognazzini, and Steve Krug, although I've added numerous bits of me.

Principles for Effective Design

  • Anticipation: Bring to the user all the information and tools needed for each step of the process.
  • Autonomy: Give users some breathing room - let them make decisions, but do your best to lead them to the right ones.
  • Consistency: Be predictable - users want to know what to expect. Surprises are bad, except in games.
  • Defaults: Make them clear and logical.
  • Efficiency: Look at the user's productivity, not the computer's or the application's. Computers are vastly more powerful than they used to be, but our neurons still chug away at the same speed. Slower, for many of us...
  • Exploration: Make user actions reversible. Always leave them an escape route, but make it easier to stay in.
  • Fitt’s Law: The time to acquire a target is a function of the distance to and size of the target. Big targets, close at hand, are easiest to hit.
  • Metaphors: "Real world" objects have familiar modes of interaction. Virtual features based on them should have similarly comfortable resulting behaviors. Human-interface objects should be understandable, self-consistent, and stable.
  • Illusions: Reflect the illusion of the interface, not the “realities” of the underlying system.

General Notes on Usability...

  • A site's homepage is the most visited individual page in the site. However, the site's interior pages are actually more important, when viewed collectively.
  • Few people scroll. Avoid the illusion of completeness (give indication that there is stuff "below the fold").
  • As long as navigation is well-designed, it can be in either the left-hand, right-hand column, or along the top of the page. Keep critical navigation out of the body content, and make sure it stays in the same spot from page to page.
  • Avoid overly fancy or complex features. This conserves development resources and allows more focus on the refinement of critical features.
  • Cutesy, trendy, and vague = BAD.
  • Persistent navigation = GOOD.
    • Hide-and-seek is fun, but not on the web or in your app.
    • Same thing with tag. Don't make people chase key functionality.
  • Avoid redundant navigation. In applications, redundancy increases complexity, contrary to what we learned in Communication Theory class...
  • User annoyance effects are cumulative. Several small gaffs can lose your audience as readily as one or two large blunders.
  • Like text content, all images and graphics should be concise and value-added. Save fluff for pillows.
  • Your most relevant info MUST receive top billing (above the fold, on the first page, etc.).
  • Aim for the lowest common denominator – that person is more common that you may think.
  • User Interface has become User Experience - make it a good one.

... And on User Testing

  • Observe your users. Know them. User testing is not a luxury, it's a necessity. Every app you build will be tested by users. Do you want it tested before or after you ship? Your choice.
  • We as developers tend to internalize the user experience, rather than observing the actual experience of real customers.
  • Our usual (but flawed) approach to "fixing" a flawed interface is to fix the user instead (via training, etc.)
  • Users don't make errors because they're stupid, but because the app makes it easy for them to make errors.
  • People don’t want to think – they want to be guided through processes. More numerous clicks are OK, and often better, IF:
    • Users know what to expect from each click,
    • They don’t have to think very much about each click, and
    • Each click is perceived as bringing them closer to a goal.
  • The details on the previous point can be overdone. Be careful.

That's it for now. I'm working up some notes for future posts on taxonomy and information architecture, as well as some checklist-style docs that may be of use in various phases of design and development. When that future comes, you'll know.