The title of this post is a wee bit binary, but it's a topic worth discussing. I was just reading a post by Rob Adams, who is working on Adobe's Thermo project, about the value he finds in paper prototypes, and some of the problems.

I'm in the middle of developing a new application with my super-great team, and we're moving from paper prototypes to a clickable, HTML prototype. There's a lot of discussion with the client during this time, and they've now seen four versions of the application on paper. At one point in his post, Adams makes the following salient point:

It's very, very easy when settling in to a routine of back-and-forth and discussion with a client to easily explain away a question they have about the interface (and therefore the workflow) without realizing that this, in all likelihood, is a design problem that needs to be solved. If they're asking you "How will this work?" or "What is this for?" or "Will it do [x]?" when that task is represented on the prototype (or is supposed to be represented or implied in the prototype), then you've got a design issue that you need to handle. If they're asking about how data is stored or background workflows not covered by the prototype at hand, then that's not necessarily a design issue that needs to be addressed.

Sometimes you're so focused on just getting through the key aspects of the prototype in the hour that the client allows you to meet with them that it's easy to quickly explain something they don't understand in regards to how the application will work. Have a second set of hands with you to note all the questions (something else that Adams recommends) so that you can go back later and say "They didn't understand this, and it's supposed to be self-evident. Let's take a look at how we can improve the design."

If someone in the prototyping process has a question about how the app is supposed to work, then you can be sure that there will be lots of people who use the app who have the same question. By listening to the workflow or application operation questions being asked and not quickly explaining them away, you'll find the design flaws and be able to fix them before they become a headache in production.

Many user interface and interaction design experts will tell you that you should not ask users to make choices when they don't have to. Unnecessary choices presented to the user are the sign of laziness on the part of the development team and ultimately work to the detriment of a user's experience in your application. As a result, it's also extremely important to choose good default values for any choices you do ask users to make. This applies to not only things like "Create New..." tasks, but also to things like search. Let me give you two examples from my own development projects.

First up is a wiki tool we built for our online course system. Everyone's used wikis, right? Wrong. A Pew report from 2007 indicated that less than 15% of all surveyed users (and their survey size is around 2000 people, from which they extrapolate the activities of most US citizens) had a blog, or created a Web page, or posted to a blog. I know that a blog is not a wiki, but the reality is that blog usage is generally considered higher than wiki usage from a content contribution perspective. (The percentage of US citizens who have used Wikipedia is probably a whole lot higher than 15%).

Anyway, the point is this: most of our users weren't familiar with what a wiki was or what they could do with the tool. We provided a simple editing interface, thorough help documentation, and even Flash-based demonstrations of how to use the tool — all accessible from within the wiki interface. That wasn't enough. Users still didn't know what to do with the page by just looking at it. Here's what it looked like to them:

A big white space isn't the most inviting of interfaces to get users started creating content. Robert Hokeman, Jr., makes a strong case for this in his excellent book "Designing the Obvious:"

For users just getting to know a Web application, a blank slate can be a barrier in the learning process. Instead of knowing what to do first, users can become stalled when faced with the empty canvas.

By providing a sample of content or automatically selecting a "getting started" template, users can see what they might be able to build with the tool, or can start clicking and editing what's provided. They don't have to do a lot of figuring out how the tool might be used — you're doing that for them, saving them time and confusion in the process. (Of course, you're also proscribing how the tool can/should be used to them, which can be a detriment to creativity. Creative users, however, will find a way to bend the tool to their own ends. They always do.)

So we went back to the wiki tool and addressed the number one question users had: "I'm not sure what I can do with this thing." By displaying a default preview of what a wiki page could look like, rather than presenting them with a blank screen (or a screen with a tiny bit of text that says "Insert text here" on it), we give the users ideas on how to get started and what, specifically, the tool is designed to do. The updated default view of a wiki page now looks like this:

That's a heck of a lot clearer.

The second example starts to cross in to the realm of instructive design: that is, providing tips and context and the right kind of default values so that the user knows what they are supposed to do with the application, registration form, etc.

Everyone's had the very annoying experience of filling out a form and entering something like a phone number, only to have the system come back to you once you've clicked the "Submit" button and say "Phone numbers must be in the (xxx) xxx-xxxx format." or something equally annoying. A well-designed form that wants to be instructive and help the user enter information in the expected way from the start would pre-populate that phone number field with (xxx) xxx-xxxx so that you could click on it, and start typing in the right format.

In building a survey tool, we decided that a Likert scale question (or matrix question) would be one of the supported question types. The tricky part with supporting that question is getting users to enter in the appropriate setup information for the question. A Likert scale question can be represented by a series of columns (which are the evaluative scale, such as "Excellent, Good, Fair, Poor") and a series of rows (which are the items to be evaluated, such as "Checkout time, Cashier friendliness" and so on).

This was our original design:

Most users could figure out how we wanted the information required using this form. However, we'd still get users who would put all choices on a single line, or separate them using commas or tabs. How to make it clearer? Here's a recent revision:

This is better, as it tells the user exactly what to enter and where to enter it. The design is being instructive. We've provided "defaults" which tell the user what they need to know, and save them from guessing, or confusion about what to put in each of the fields.

We could go farther, however, and create a dynamic preview of the question as the user entered both rows and columns to make up the matrix/Likert question. That's something we're looking into. (There's debate on the value of that, as once a user makes a couple of matrix questions, they pretty much get how to do it and don't need to see a whole lot of other stuff cluttering up the interface.)

So the point here is this: choose good defaults, and make them instructive. The more unobtrusive guidance you can give to your users, the faster they'll get up to speed with your application, and the less (wrong) decisions they'll make in the process.

As I mentioned in my last post on Bret Victor's excellent paper, Magic Ink, there was so much food for thought for software and UI developers in his article that I took the rare step of making my staff read the article and discuss it in a group setting. One point which arose during that discussion bears further elaboration here.

Victor spends a good bit of time talking about developer/machine representations of a data model versus how real, actual human beings are able to represent data, and, more specifically to my point, choices. In particular, he takes to task the standard "Preferences" (or, in Microsoft parlance) "Options" screen found in pretty much every desktop application. What we are frequently presented with is something like this:

But this is a machine's (or, better yet, a developer's) representation of a series of choices. It's all binary and fairly decontextualized. Now, the trend in UI design to categorize preferences or choices into a larger context such as "Security" or "Bookmarks" is helpful, but a lot of these preferences are still represented in the machine model, not the cognitive model the user has. Victor points us to a better way:

For presenting abstract, non-comparative information such as this, an excellent graphical element is simply a concise sentence.

Victor's BART schedule widget, which he uses as a case study for many of the ideas in the article, uses just this approach when setting user preferences. For example, here is a preference setting which lets a user decide if they want to announce upcoming trains, and when those announcements should go off:

This is very succinct and tells the user, in plain English, what's going to happen.

But would this pass the Mom test? (AKA "Could your less-than-technology-savvy mother figure it out without any help?")

I'm not sure.

Look at the example. What are the visual indicators that you can actually interact with this? How do I know that I can change the text in this sentence?

Granted, most users, when presented with a new piece of software or a Web application that they can't immediately figure out, just start clicking until something happens. Someone clicking that preference sentence would see, in short order, that you can change quite a few things, as evidenced in additional shots from the BART widget:

But the question, for me, remains: would a user be able to figure this out? Would they get stymied by this and not really know what to do next and instead click on things elsewhere that they had already figured out. I'm inclined to believe that is exactly what most users would do.

Users have become so inured to the checkbox/radio button preferences dialog box that I'm not sure they'd intuit how to manipulate preferences in any other way. Users have been working with that kind of preferences model for over 20 years, and I don't know that it's a "design pattern" that can be broken without a heck of a lot of effort. (Then again, clicking around on the screen until something happens isn't a lot of effort.) What I suspect would happen is that a user would see this and then say "Well what do I do now?" and call the help desk (or a tech-savvy family member or friend). Users who feel they don't have the time to figure things out (and who does?) often just stop their task when the path to accomplishment isn't immediately available. Worse yet, if they've been burned in the past by randomly clicking around on the screen (resulting in an application or system crash), they won't be able to move forward with manipulating the application for fear of wrecking everything.

I know that Victor's article is forward-thinking, and it's great that it is, but in considering how users interact with interfaces right now and the years of "standard" experience that they have, the preference as a sentence to manipulate concept is slightly problematic.

Perhaps stronger default visual indicators, like hyperlink-style underlines under items than can be changed, would alleviate this problem and quickly teach users that those items were changeable. It's a nitpicky point, but important, because without those extra visual indicators, a heck of a lot of people would be calling the help desk.

The good folks over at Vitamin have written another useful and insightful article about Web application design, this one talking about the nightmare that can become the home page.

A couple of key points:

• Less is more. I cannot stress this enough. Their example of the Apple home page is good, but Google is an even better example. Part of the reason Google attained such dominance in the search industry is because their home page is simple: a search box with a minimum of fuss. People like simple. Believe you me, I do understand how clients will want to cram as much information on to the home page as possible (if you ever saw some of my earlier site designs, you'd know I was a perpetrator of this crime). But less is always more — you point out what's truly important by not dumping everything you think is important on to the home page.
• I really like the idea of designing the "interior" pages first. This makes a lot of sense in that it gets the client to think about the application (or site) as a whole, and not spend all their energy on the home page and then not have any time to spend where it really counts: focusing on how people use the internals of the app.
• If you don't believe people enter Web sites via pages other than the home page, I guess you haven't heard of bookmarks.