My old college buddy asks:

When you are trying out a new development tool, what do you look for to help you learn how to effectively use the tool? Is it help files, tutorials, white papers, samples, case studies, etc? Or do you learn best by participating in classes or through mentoring? Perhaps you only try to learn tools that are easily assimilated, and if so, what makes one tool easier to learn than another?

There’s a saying in the field of User Interface Design (computer and otherwise) that goes “there should only ever be one button: one that does exactly what the user wants.” Of course, this is hyperbole, but it does illustrate the theme of UI design: make the tool as easy to use / simple / natural as possible. A more usable product is the one that the user needs the least amount of thought to use and the least amount of initial training.

Accomplishing this is incredibly difficult, which is part of the reason why most user interfaces are absolutely horrible (the other is that most engineers don’t study usability, especially usability for mass audiences). Fortunately, this is getting better: Apple has made UI a sellable feature, and User Interface Design is now a bona fide field of research that gets attention from the builders (if you’re interested, you can start with Neilsen, Norman, and Tog, the current gurus of usability.

Now, to answer Graham’s question:

what do you look for to help you learn how to effectively use the tool?

Here’s my order of preference:

1. The tool should follow some natural metaphor, if possible. Ideally, the tool should behave as if it is an extension of my body / mind. This way, there’s no learning curve; you already know how to use it. Unfortunately natural metaphors are hard to come by in the decidedly un-natural world of technology, so most of the time this isn’t available. Still, I think it should be said.
2. If tool can’t follow a natural metaphor, then it should follow a familiar one. That is, it should try to duplicate one that already exists. This way there’s zero learning curve for users who already know the preexisting metaphor. There’s two big catches to this approach though:
   1. The old metaphor may not be terribly good to start with. Garbage in usually means garbage out.
   2. The old metaphor may not translate well to the new medium. QuickTime 4.0 is the poster child for this problem.
3. If the tool can’t be familiar then it should be self-describing. The means of accessing the features should be apparent (in fact, blatant). Available features should be displayed (rather than hidden) at the ready. This makes the learning time efficient: you are able to learn while you actually use the tool. A good illustration of this principle is the use of text rather than graphical icons to represent features: text describes the feature far more explicitly and accurately than a (tiny) picture.
4. If the tool can’t be (effectively) self-describing, then it should have description waiting in the wings for the initial learning period. Think of a tutorial, but one that teaches as the user uses the tool. Some modern games are great examples: every time that you encounter a new tool, feature, or technique they give you a brief explanation of how to use it, followed by some time to put it into practice. Play Half-Life or Portal with the commentary on to see the thought process behind this technique.
5. If you can’t do an effective tutorial mode, the next best thing is to have built-in (local) context-sensitive help ready at the touch of a button. There are three important factors to application help: relevance, speed, and connection to other topics (ie: lots of hyperlinks). This will help a user get out of a jam, but it may not do much to get them started in the first place.
6. If local help isn’t available, putting your help on the Internet (say, in the form of a FAQ) is almost as good as local help, although it’s not available if you’re disconnected (ie: on a plane). Internet help also lets you enhance help post-launch and get feedback/usage stats. If you get a good community behind the tool, they can potentially help with the help (with wikis & blog posts).
7. Examples can be useful; lots of people learn better from example than they do from a spec. The major problem with examples though is that they are necessarily of narrow focused and contrived. They may not be answering the questions that are being asked, and they certainly won’t be able to answer every question.
8. White papers and other wordy documentation are not nearly as useful as other forms of instruction; it’s harder to find the solution to a particular problem when it’s floating in a sea of flat text. Always remember that, as a rule, people don’t read.
9. Screencasts are appropriate for dynamic situations, where capturing the actual motion is important. Otherwise, video just becomes a very hard-to-use interface to the information being communicated; think of a book where the pages are turned at a fixed rate. Static text and pictures are better for most applications.

I’ll leave mentoring off my list entirely. I’ve never been a fan of (nor had much experience with) mentoring, because:

• I’ve always had a do-it-myself (and discover-it-myself) attitude.
• I’m often learning at the (b)leading edge of things; mentors with prior experience aren’t always easy to find.
• Likewise, people with more experience are often too busy to spend a lot of time mentoring. They’re adding more value by operating, especially if I’m able to learn effectively without their help (which, in turn, makes me more valuable too).
• I’m more anti-social than most. For work purposes at least, personal interaction is a means to an end, not an end in itself.

These don’t apply to many (most?) other people though, so they’re not a criticism of mentoring itself. Many people appreciate mentoring and find it valuable.

Lastly:

Perhaps you only try to learn tools that are easily assimilated

I certainly prefer easily-assimilated tools. A small learning curve makes the tool more efficient, which is half of the value equation. The other half is effectiveness, and that’s where poor tools can find their niche. If there’s no other tool that can do the work of one with a crappy interface / steep learning curve, then there’s not much choice in the matter; I’ll have to bite the bullet and learn / use it. But I’ll always be looking for a way out.