The dangers of default disdain

Those who create do so with an unspoken bias and for good reason. A right-handed can opener, the placement of letters on a QWERTY keyboard. Anything manufactured starts out as a guess about its end user and their motivations, and these motivations are carved into the design. Those who create technology have the awesome power of establishing standards—setting the presets—to steer their systems. The larger the scale of the system, the more assumptions the designer has to make. And, unless these presets can be modified, the system is limited.

Accepting the default rainbow, or a colourmap designed for seismic data, may be unwiseIf you think about it, defaults are an incredibly necessary invention, because they go to work when we do nothing. But doing nothing, relying on some stranger's arbitrary parameterization, is a bad choice. We often blur the concept of the default (where we have choice) with the preset (no choice). Your keyboard is preset. Your desktop wallpaper, your suite of mobile apps, the color scale on your contour map, these are defaults that can be changed. The shame is when they aren’t changed, the triumph is when they are changed to add value. By fully exploiting defaults, we can be more agile in our work, but only if the systems are designed with such flexiblity and freedom in mind.

The visonary Kevin Kelly writes a wonderful essay, describing the default as a vehicle that designers use to drive the habits of the consumers. But he notes,

...defaults are 'sticky'. Many psychological studies have shown that the tiny bit of extra effort needed to alter a default is enough to dissuade most people from bothering, so they stick to the default, despite their untapped freedom. Their camera's clock blinks at the default of 12:00, or their password remains whatever temporary one was issued them.  The hard truth, as any engineer will tell you, is that most defaults are never altered. Pick up any device, and 98 out of 100 options will be the ones preset at the factory.

Is there an altogether better way to design goods and services—or software tools? Can the user community drive the design and utility of intelligent defaults?  

Many geoscience applications (most applications in fact) are designed with a preset architecture ready for optimizing performance and accessibility. However applications, like people, are not neutral. They have biases. Think about the software that you use most often. Does it provide you with flexibility, or is it constrained (thus constraining you) to doing only a few things well? Does it have units that you can’t stand?  Is it an impenetrable black box, or is it a hub for your creative expression? Does it allow you to be as agile as you want to be? 

The January 2011 Interpreter's Corner section of SEG's The Leading Edge, William Hammon examines the computational and psychological factors affecting 'intelligent default' design in geoscience software. He asked people to play with defaults in order to match a given, ideal processing target. Although a variety of interesting observations emerge, there are three take-home conclusions: 1) very few people actually start with the initial default settings (essentially defeating the purpose of intelligent design); 2) fewer parameter choices invoke bolder default excursions; 3) subjects will be more experimental when working with faster processes. 

I really like this paper, but my lasting thought after reading it was one of jealousy. We never actually have an idealised target to converge to. Sure, it's a construct of the experiment that allows for metrics and discussion, but it's just not fair!  It's also more reason to start, be even bolder, and even more experimental with the defaults that are sitting in our inventories.

Comments

[Reid]

This is a subject I've spent a lot of time working with, both from a software point of view and in buildings. "Defaults", or Design Standards, are important from a usability point of view, and can directly affect everything from productivity to safety.

Consider something like the stairs in your building: you expect (whether you are aware of it or not) the treads and risers to be the same size, to such a degree that if one riser is 1/4" too high, you'll catch your toe 9 times out of 10. And if you do trip, you reflexively put your hand out to grab that handrail on the wall. What if it wasn't there? What if it was higher, or lower, than typical? What if is was a star-shaped extrusion instead of a pipe? You'd have a sore nose to go with your stubbed toe.

The same goes for just about any component in your house. Try walking around in total darkness, and see how many things you can find - can you put a glass of water on your countertop? Can you find a light switch? Can you find a door knob? Probably yes to all, because they are where we expect them to be. This would even be true in a stranger home.

Similarly, software interfaces that comply with certain industry standards give new users a leg up on learning how to operate the system. For applications we have been conditioned for that past 2 decades to look for a menu bar across the top of the application window with familiar options such as "File" "Edit" "View" "Help" "Window" etc. When our expectations are met we immediately begin to understand our way in the program, and it starts to make sense for us. Familiarity is our guide through new experiences.

Just look at what happened when Microsoft changed the interface of their Office Suite for the 2007 release. Every familiar command and button was changed, moved, re-designed, leaving long time Office users confounded. Your fundamental way of using the software had changed, and you not only have to learn new software, but you have to first unlearn the software you were used to.

An interesting side question for pondering: lets assume the new office interface is more well designed than the old interface (as in if you were starting from scratch with a new program you'd pick the new one, not the old one). Is it actually a better choice to change an interface that your user base is familiar with, even if it's flawed, or to leave it largely unchanged? Does user comfort and familiarity with a system count for more than pure design?

It's a great exercise to try to redesign the wheel from time to time, but at the end of the day that wheel still needs to roll so my car stays on the road.

[Matteo]

Evan

Thanks for mentioning this post yesterday; I am surprised I missed it before.

As a left-handed person I am sometimes frustrated by defaults, but then you can get creative with can openers, computer mice, scissors...
:-)

I love this quote: "...defaults are 'sticky'. Many psychological studies have shown that the tiny bit of extra effort needed to alter a default is enough todissuade most people from bothering, so they stick to the default, despite their untapped freedom."
It really has it all!

As for color palette default, Borland and Taylor, in their paper "Rainbow Color Map (Still) Considered Harmful" present (Table 1) some surprising statistics about the prevalence of rainbow in IEEE Visualization conference papers. I've uploaded the paper here:
http://mycarta.files.wordpress.com/2012/10/color_07.pdf

I for my part noted that 21 out of the 24 otherwise great geophysical talks I attended in 2011-2012 used the rainbow or spectrum color maps, a solid 88%. So yes, defaults are sticky. And this is not always a trivial matter: Borkin et al. in their paper "Evaluation of Artery Visualizations for Heart Disease Diagnosis argue that using rainbow in artery visualization has a negative impact on task performance, and may cause more heart disease misdiagnoses. Check the paper here:
http://mycarta.files.wordpress.com/2012/10/borkin11-infoviz.pdf