Sensible Defaults and Anticipating User Needs

I have written before about sensible defaults in various shapes and forms, but I realized I never really wrote about the logical consequence of that in application design.

To recap: For every application, there are usually one or several typical operations and typical workflows that users may have to perform. A programmer needs to determine those workflows, examine them, and split them up into individual work units that the program can perform.

In some cases, that's all you have to do: Come up with menu items, buttons and controls that perform the individual subtasks and merrily go on your way. But a good interaction design has to go beyond just letting the user do the operations with a computer instead of with a hammer. You will want to optimize the workflow.

One of the fundamental rules of interaction design comes from the early days of the graphical user interface, when all we had were command-lines. Back then, one bright mind realized that we shouldn't have the user type in anything the computer already knows. That's how we got menus and radio buttons in the first place. Instead of expecting you to remember terms, the computer will present sensible answers and let you point at one, as if buying cheese at the cheese counter in a remote Swiss village where they still speak that Latin-descended language few others in the world know.

This may seem to no longer be relevant now that everyone is well-versed in the use of what are now standard controls, but it is also relevant to your workflow. Take an FTP program, where you create your web site locally, and then upload it to the server:

The usual workflow would be to have a list of all the files in the user's folder, have the user select the ones they want to upload and then push a button to trigger the upload. That's a good design, right?

Meh.

Look at your workflow. Look at the typical use case. The user has files on disk that are a 1:1 representation of the site the way it should be on the server. Our FTP program knows the folder, it knows the remote directory on the FTP server. The user has changed a few files, and both the local hard disk and the server track change dates. The computer already knows which files the user will want to upload!

So, instead of just being a nice graphical veneer on top of what is essentially the networked version of cp, why not optimize the workflow? If the user does not select any files, why not offer them a list of changed files and ask them: "These 4 files have changed, did you perhaps want to upload them?"

Now, we can't always assume the user will always want to upload all of these files, so you need to ask. But in that panel that asks, you can let the user remove the files to not upload yet. And always keep in mind that we're dealing with heuristics here. Some people have one folder containing lots of files for different servers. You don't want to annoy them by always selecting 50 files for 25 other servers, because she only selected the two for the current server. Not every upload is a full-blown sync.

Unless it looks like something very stupid to do, if the user expressly states an intention, just do that. It's bad to be a boring app that needs the boring old ten steps when you could do it in five, but it's worse to be the app that always gets in the user's way by trying to provide "helpful suggestions". Clippy the psychotic paperclip anyone ... ?

But if the user is vague (like clicking "upload" when nothing is selected), don't just say "Can't upload nothing". If you can, offer to do the most likely thing she was trying to do. And if you have such a feature, maybe it's a good idea to indicate that in your UI. E.g. mark all files in the list that have changed with a little green up-arrow, and change the name of the "Upload" button to "Upload Changed", or so. We may not be able to implement the DWIM-button, but we can inch closer and closer to it.

What workflows could you optimize in your (or your favorite) application? Where does your application know things that can be used to anticipate what the user wants?

PS - I had a particular app in mind when I wrote this article, but I didn't want to point fingers. So I thought long and hard to come up with a different example. Hence, this may seem like a petty, tiny detail, especially in light of the "sync" feature most FTP programs have, but play along. Try to come up with a better example. As long as this article has started you thinking about ways to anticipate user needs, my job is done.

Reader Comments: (RSS Feed)

Rafael Bugajewski writes: Anticipating what the user wants is in the most cases a very bad idea. Empiric test can show that a lot of users have a workflow A and a couple of other users have a workflow B. Still there will be a lot of other user workflows that are different or you haven’t measured / observed / thought of. We should keep graphical user interfaces as simple as possible, so that almost every user understands your application and can adopt his own workflow. We should assist our users adopting their own workflow with technologies like DnD, AppleScript and other useful frameworks that are given by the operating system. Microsoft did a lot of DWIM-Interfaces in the past and it was a horrible experience (I don’t know what the current status is).

Uli Kusterer replies: ★ Rafael, I do warn about doing stuff that gets in the way, and I do mention Clippy. FWIW, Clippy & Co. have apparently been removed from Office. And I haven't seen much DWIMery in the negative sense in XP and Vista during casual use recently.

Comment on this article: Name: E-Mail: (not shown, hashed for Gravatar) Web Site URL: (optional) Comment: (plain text only) Please Enter the following word:

Or E-Mail Uli privately.