I’m happy to announce that I have a new article up on Vitamin, called Deliverables That Work: Design Description Documents, in which I give away what I hope will become your new favorite design deliverable. It’s a little something that I’ve been using for months now and has proven extremely effective for communicating design work.

Learn more about Design Description Documents here.

I’ll be doing a couple more articles for Vitamin in the coming months as well, so for the time being, I’ll be your resident Guest Advisor (see the Advisory Board on the homepage).

You can now vote on the panels you’d like to see at SxSW Interactive in 2008. This time around, I proposed a couple of “power sessions” on web application design and design processes. Here’s a quick description:

User Centered Design is Broken

User-Centered Design is too slow for agile web processes, and it’s filled with flaws. Robert Hoekman, Jr., shows you how to design for activities instead of audiences, and how the new rules of User-Centered Design will turn your next project into a resounding success.

Vote for this panel >>>

Performing Interface Surgery

Design patterns are one the handiest tools around for interface designers, but too often, they’re built poorly and result in a lousy user experience. Robert Hoekman, Jr., goes over several common design mistakes and how to perform “interface surgery” on them to create great application interfaces.

Vote for this panel >>>

Hope to see you there!

While doing design work and usability reviews and such for a client, I occasionally find myself needing to demonstrate an interaction visually, whether it’s something I’ve designed myself or something I’m reviewing. The written word can go a long way, but sometimes it’s just easier and faster to put the words to images so I can move on to other things. The less time I spend on what should be simple explanations, the more time I can spend doing other important things for my clients.

So recently I started creating what I like to call a protocast. Like a screencast, a protocast is a quick screen recording, but in this case, it serves as a prototype. Instead of doing a bunch of work to create a hi-res animated prototype in Flash or something, I can record a movie and toss that in with my other deliverables in just a few seconds. It’s quick work, and clients appreciate the visual explanations.

Watch an example.

So, how’s it done?

First, you need to prepare a low-res prototype in some way. Either that, or you can simply click through screens in your wireframing tool of choice while narrating your actions. Using OmniGraffle, I create a canvas for each state of an interaction and use the Actions options to set the behaviors (such as clicking a button).

Next, you need the essential ingredient: either Camtasia (or similar) for Windows, or Snapz Pro for Mac. Once you have the software installed, you need to click your heels three times, stand on one foot, pat your head and rub your stomach while reciting the alphabet backwards.

Not really. All you need to do is record a movie. Using Snapz Pro, you simply:

1. Press the keyboard shortcut to bring up the Snap Pro dialog box. As you can see, you can take screenshots of a single object, a selected area, or your whole screen as well. For a protocast, you just click the Movie button.

2. Once the Options screen opens, you adjust the size of the recording area to whatever you need, specify whether or not you want to record an audio track with your video (I almost always narrate protocasts, but you may find it’s unnecessary), and then double-click the recording area. This produces a Save As dialog box.

3. Enter the name you’d like to use to save the file, and click Save. As soon as the dialog box closes, Snapz Pro starts recording.

4. Narrate your actions as you click through your wireframes (or comps, or whatever). When you’re done, press the keyboard shortcut again to stop the movie and save it.

That’s all there is to it.

If you’re perfectionist, you may find yourself wanting to record the movie 17 more times to make sure you say and do everything just right, but this defeats the purpose (protocasts are supposed to be quick), so try to let go of your obsessions and simply go with the first or second take.

Once you have your protocast, be sure to reference it in any relevant design documentation you’ve created. In a usability review document, for example, I add a line of red text at the end of a recommendation to tell the reader where to find the accompanying movie (e.g. “See Rating.mov for an example of this recommendation.”).

If you just want to explain to a client a potential usability issue, you can use a screen recording for this as well. Simply record your actions as you perform the interaction in question, and reference that in the design documentation as well.

Protocasting saves me loads of time and clients appreciate it. This explanation should help you get started with protocasting so you can save time, too!

The publishing world is unfriendly to the environment by design. So I was very glad this morning to learn that Pearson, the parent publishing company for brands like New Riders, Peachpit, Sams, and Que, has enacted a plan to go carbon-neutral by the end of 2009.

I’m also happy to say that we’re currently looking at ways to offset the carbon emissions that will result from the printing of my next book. In an effort to raise awareness, and raise the bar for other publishers, I’m planning to devote a portion of my royalties to neutralizing the effects of each printing run.

We’re also exploring the possibility of using recycled paper.

Kudos to Pearson and anyone else who can create ways for the public to continue enjoying books without damaging the environment.

Oh, and that new book of mine won’t be out for several months, so don’t get too excited yet. I just started Chapter 1 last night. We’re a loooong way from a printed word.

Here’s something you can do right now to improve almost any application:

Stop labeling your assumptions.

Oh, wait. You don’t know what “labeling your assumptions” means. And that’s exactly my point.

There are loads of input fields and checkboxes and radio buttons on the web right now that lack context. They ask users to do things without explaining what those things mean. Like my statement, “stop labeling your assumptions”. Without context, you have no idea what I’m talking about.

What I mean is that we often make assumptions about how much our users will understand about our applications. We assume a user will know what we mean when we write “Enable checking” next to a checkbox, or “Content file:” next to an input field, or “Refresh” on a button that could apply to either the whole page or a single content area. We assume, and then we label our assumptions.

Right there in the interface, we tell our users that in order to use our software, they have to know things only we know about how it is used. They have to read our minds.

Funny that we so often accuse our users of being the faulty part of the equation, isn’t it?

Here’s how you fix it.

Look at each and every label in your application and ask yourself if someone who had never seen the app before will know what it means. Write a list of all the “No” answers and either change those labels so they’re more meaningful or add instructive elements that explain them (text, screenshot, short video, etc).

Keep another list of “Yes” answers. When you’re done writing, show all your Yes’s to 3 people who have never touched your app before.

When you’re done, I suspect you’ll need to change a few more labels.

Don’t feel bad, though. I changed at least three of my own earlier today.