One of Jeff Attwood’s posts has got me thinking. It starts by raising the point that whilst “keep it simple, stupid” is a good paradigm for implementing an effective interface, it doesn’t generally reflect what users ask for. Most solutions developers will be familiar with the concept of being landed with a few absurdities in the list of “must have” features at the end of a successful sales process, and it’s usually the sales guy that gets the blame. In reality, it’s often the client themselves that fabricates these requirements, assuming they are a good idea (though of course, there are ways to sell stuff which coax the user into inventing features, and these techniques are perhaps best avoided).

However, this aspect of human nature isn’t confined purely to the sales meeting, and Atwood references an interesting post by Jensen Harris which discusses the use of data collected from real-world users, transparently. It’s a neat idea, though I have my reservations. Mainly, it’s hard to see how effectively it will disclose anything about usability issues caused by the absence of actions: it’s obviously not possible to record what the user doesn’t do.

Let’s take an example. I often want to paste text into Word documents or Outlook emails, but I nearly always want to paste just the text, not the formatting. There is no “paste just the text” action, so I need to use “paste special” and then select “unformatted text.”

Now, where this becomes an issue is that the results will always appear to vindicate the status quo. As it happens, my normal “paste just the text” behaviour looks like this: first, I use “copy” to get the text, then I go to my target and hit “paste” (since it’s such a common operation that it’s almost Pavlovian: all paths from Ctrl-C lead to Ctrl-V), then I realise I’ve pasted the formatting as well, so I “undo,” and at this point (before I go to “paste special”) you’ll notice that I’ve used three of the top five Word actions, but that two of them were wasted. In fact, one counteracts the other. (It’s of considerable interest that the fourth most popular action in Word is the one which is used when the user previously did something that they didn’t want to.) I’ve “voted” for stuff which doesn’t represent what I want to do, and even when I finally register a vote for “paste special,” I’m still voting for a process that requires four clicks to achieve a simple goal (the best I can hope to achieve, by customising the toolbar, is three clicks).

Reading too much into “votes for actions” is like reading too much into votes for politicians: all they tell you is (given the voter’s level of awareness) which of the available options seems the least painful.

Atwood titles his post “Dont Ask — Observe,” which is sound advice, but I suggest not observing their clicks from afar. Instead, observe their swearing. I swear regularly at Visio, yet often it’s the things I swear at which would register most highly on the feature poll. One shining example of infuriating interface in Visio is the behaviour of the “Ctrl” modifier when using the mouse button. Holding Ctrl and dragging creates a copy of the selection: it’s a really useful feature. Unfortunately, the developers also implemented “Ctrl plus left press” to add an item to the selection. The result is that when I try to drag-copy a number of objects in turn, I end up copying the previously selected object as well, having to undo (there it is again), deselect both objects, and start again. The truly tragic part is that shift-clicking already implements the “add to selection” behaviour: Ctrl-clicking to multi-select is redundant. Were my “action votes” to be registered, Microsoft would no doubt think that Ctrl-clicking was a really well-received feature — when in fact it’s one of many that enrage me on a regular basis. Remember: Popularity is not a measure of quality (the number of explanatory analogies for this statement is practically infinite, so choose your own).

Coming back round to the point of not asking users for features, I suggest the key thing to bear in mind is this: no matter how cutting edge your software, the task the user is trying to perform is almost certainly quite mundane. Users rarely need new stuff to do, but they nearly always need to do their existing stuff easily. Give a frustrated Word user the simple interface of a pencil and a piece of paper, and it will take them a couple of minutes to draw the table that they’ve spent an hour trying to build in Word. Developing and evolving the usability of an application should be done with the same approach that promotes robust code: you fix the existing bugs before you add new features.

Don’t ask users for features, but do ask them where the pain is.

As a footnote, it’s amusing to note that “once [the Office developers] recognized the importance of the Paste toolbar button, it was promoted to the first big button on the left side of Word’s first tab.” Uh-oh — it’s moved, why are you moving the buttons that get used most often, the ones whose locations are most familiar to users? By moving ‘paste’ to the first button in the row, not only are you moving the most familiar parts of the interface, you’re also breaking the established logical structure of “cut-copy-paste.” It’s on a par with the adaptive menus which Office provides by default (and which are the first thing I turn off — once I’ve figured out how — after installing it). Anyone who’s been foxed by their local supermarket occasionally moving items to different aisles will be familiar with this: not only are the chocolate bars two rows away from where you expected them to be, they’re also no longer next to the biscuits. Note that supermarkets do this deliberately to disorientate customers and force them to search for what they want. This is, plainly, not a desirable approach to developing a user interface.