Well, that didn't take long, did it? My second post after a lengthy hiatus, and I end up on the front page of Daring Fireball. Clearly my talent for stirring the pot hasn't waned in the least over the past couple of years.

I'm also amused at a number of the comments on that post. It's a product of my age. Not only do I remember a time when floppy disks really were floppy, my experience with them dates back to high-school when I had the, um, pleasure of doing accounting on an old IBM work station connected to a computer housed in a semi trailer that seemed to use up half the back parking lot. Those were 12" floppy disks, and they didn't hold very much data.

But neither my age nor floppy disks address the overall point I was trying to make; a point that commenter Michael McWatters, stated very succinctly:

As in most things UX-related, there can be no immutable laws, only best practices and context-sensitive design solutions.

"UX" stands for User eXperience. It goes beyond just usability, and involves a systematic effort to understand how users feel when they use something. It's applicable outside the world of software, but it's becoming increasingly important in the software industry. In my previous post, I linked to this Wikipedia entry, which gives the ISO definition of user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service."  You'll also see the word "affective," in the psychological sense, used to describe these feelings.

User experience is inherently subjective. Indeed, it's about as far to the subjective end of the objective-subjective spectrum as you can get. We can't measure it directly, but we can take a look at the factors that determine a user's perceptions and responses. The user's past experience, for example, is one of these factors. Another factor is what the user wants to achieve--the user's goals. Yet another factor is the user's aesthetics.

We use the word "context" to refer to the collective set of factors that determine a user's perceptions and responses to using a system, hence Michael's use of the phrase "context-sensitive design solutions."

And it's the user's context that matters, not mine or John Gruber's, or yours unless you're a user. Even then, as an individual user, your context only matters to the extent that your context shares elements of the contexts of other users. That last statement is important, because users aren't homogeneous. The "average" user is as much of a statistical fiction as is the "average" household that, at one point, had 2.5 children and 1.5 cars.

Users don't all have the same shared context. A couple of comments on my previous post help to illustrate this point.

One commenter pointed out that, for Mac users, the use of a floppy-disk icon seems to be unique to Office. Let's take that as true. However, we've already had to limit our user population to Mac users. Furthermore, given the history of Mac Office, the use of a floppy-disk icon is part of the context for existing Mac Office users--the people most likely to use newer versions of Mac Office.

Another commenter suggested doing away with the save operation altogether. We actually did that once, not with Mac Office, but with another app. We were quite surprised to see the number of users who were disturbed by their inability to figure out how to save their work. It never occurred to them that the app was saving their work as they went along.

Since applications inherently target different users, the archetypical context for one app won't be the same as that for another app. Hence, a particular design decision that makes sense in one app, e.g. using a floppy disk as the icon for a save button, wouldn't make sense in another app.

As an exercise, go back and read Apple's HIG in light of this idea of "context." Do those guidelines favor certain user contexts over others? Might there be some users for whom the target context inherent in Apple's HIG wouldn't be appropriate?  Why, indeed, are they called "guidelines," and not "rules"?

I'll leave you with that thought for now. In an upcoming post, I'll talk a bit about how we break down user contexts into relatively homogeneous groups, and how that helps us prioritize the work we've done on Mac Office.

Oh, and John, if you're still paying attention, the next time someone asks you what icon they should use on a "save" button, tell them to use a piggy bank.

 

Rick

Currently playing in iTunes: I'd Rather Be Blind, Crippled and Crazy by The Derek Trucks Band