[Thanks to Yaniv Sarig, who translated this post into Hebrew.]
Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?
We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.
We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.
What we found was really interesting. Less than 5% of the users we surveyed had changed any settings at all. More than 95% had kept the settings in the exact configuration that the program installed in.
This was particularly curious because some of the program’s defaults were notable. For example, the program had a feature that would automatically save your work as edited a document, to prevent losing anything in case of a system or program failure. In the default settings for the version we analyzed, this feature was disabled. Users had to explicitly turn it on to make it work.
Of course, this mean that 95% of the users were running with autosave turned off. When we interviewed a sample of them, they all told us the same thing: They assumed Microsoft had delivered it turned off for a reason, therefore who were they to set it otherwise. “Microsoft must know what they are doing,” several of the participants told us.
We thought about that and wondered what the rationale was for keeping such an important feature turned off. We thought that maybe they were concerned about people running off floppies or those who had slow or small disks. Autosave does have performance implications, so maybe they were optimizing the behavior for the worst case, assuming that users who had the luxury to use the feature would turn it on.
We had friends in the Microsoft Office group, so we asked them about the choice of delivering the feature disabled. We explained our hypothesis about optimizing for performance. They asked around and told us our hypothesis was incorrect.
It turns out the reason the feature was disabled in that release was not because they had thought about the user’s needs. Instead, it was because a programmer had made a decision to initialize the config.ini file with all zeroes. Making a file filled with zeroes is a quick little program, so that’s what he wrote, assuming that, at some point later, someone would tell him what the “real defaults” should be. Nobody ever got around to telling him.
Since zero in binary means off, the autosave setting, along with a lot of other settings, were automatically disabled. The users’ assumption that Microsoft had given this careful consideration turned out not to be the case.
We also asked our participants for background information, like age and occupation, to see if that made a difference. It didn’t, except one category of people who almost always changed their settings: programmers and designers. They often had changed more than 40% (and some had changed as much as 80%) of the options in the program.
It seems programmers and designers like to customize their environment. Who would’ve guessed? Could that be why they chose their profession?
(Big takeaway: If you’re a programmer or designer, then you’re not like most people. Just because you change your settings in apps you use doesn’t mean that your users will, unless they are also programmers and designers.)
We’ve repeated this experiment in various forms over the years. We’ve found it to be consistently true: users rarely change their settings.
If your application has settings, have you looked to see what your users do? How many have changed them? Are the defaults the optimal choice? Does your settings screen explain the implications of each setting and give your users a good reason for mucking with the defaults?
On User Involvement:
I’ve just finished setting up uxurls.com – a user experience aggregator. It’s a really simple popurls clone, intended for people who are too busy to set themselves up with their own RSS reader, or just fancy a quick glance at the sites I’m reading.
There’s about 130 sites on there right now and I’ll be adding progressively more in the next few weeks.
If you want your site added, feel free to drop me a line @uxurls, but I’m not making any promises. This site is really just intended as a way for me to share the sites I’m reading at the moment, and it’s definitely not intended as an exhaustive catalog of all things UX.
I hope you find it useful!
User Experience Design (or UX for short) has exploded on the software scene carrying a blazing torch of freedom and promising to guide us to the holy land. We are now dedicating time and resources specifically to user experience design. This emphasis on actually designing user interactions and the experience of our applications is a fantastic effort and I applaud all those that wave the UX flag and sing its praises. But I have one problem: UX is making me a worse software developer.
An unfortunate byproduct of the UX revolution is the misinformation that developers simply can’t design good experiences. We see article after article explaining what happens when you leave developers in charge of UX design. People laugh at how stupid developers can be, that they just don’t “get it” when it comes to designing things well. These articles should highlight the importance of explicit thought when designing interactions in applications, they should not strip developers of their confidence and creativity. And yet that’s exactly what I’ve noticed happening to me.
Let me relate a brief hypothetical example. On our software project I am the lead clientside developer. We have a UX Specialist (aka UX Guy) that is responsible for the design of wireframes and mockups that explain how the user navigates through the application. During the UX pass, our UX Guy listens to us (developers and business guys) explain what the problem is and what we think we want the software to do. Then UX Guy goes off and comes back with a set of wireframes for how the application will work. We discuss, bring up problems, send back the wireframes for further iteration. Repeat that process until everyone is satisfied with the wireframes, then move on to actual development of features.
But then during development I have found myself getting the following question from my manager: “Hey Doug, how come you can’t do Feature X in the app?” and I have found myself actually saying this (shudder): “Oh, I guess that wasn’t included in UX Guy’s wireframes, you should ask him.” That’s a bullshit response. I’m not a neutered incompetent mindless developer. If something doesn’t work or was forgotten, I can figure out how to fix it. That doesn’t mean throw the code in without thinking about design. That means pausing my code writing, thinking through the problem carefully, designing a solution that will be sleek and elegant, and then continuing on with development.
And yet in my mind I have the unconscious prejudice that I, as a developer, cannot be allowed to make “UX” decisions. Fuck that. We are all responsible for designing the experience of our software. We are all responsible for carefully thinking through every interaction. We are all responsible for making things beautiful, making things simple, making things elegant. And more than that, we are all capable.
Dreamworks films are quite clever the way they have jokes for children and adults occur simultaneously, so everyone laughs out loud together.
Sorry did I say children and adults? I meant children, adults and UI designers…
Using a feedreader and can’t see the video?
This was one of the clips shown in Nathan Shedroff & Chris Noessel’s talk on SciFi and UI design at Dconstruct’09. They’ve published the talk notes here [18MB PDF].
If you haven’t already seen it, you may also want to check out this Pixar short film on alien abductions and bad UI design.
It’s nice to see that Dilbert’s been taking on a UX focus lately…
Step 1: Realisation
Step 2: Confirmation
Step 3: Response
