My wife doesn't know what I do at work.  I tell her all the time, but her eyes glaze over sometime into the second paragraph like mine do when she discusses her work in the neonatal intensive care unit.  I find my work endlessly fascinating, but I'm in the minority.  What I do is develop user experience designs from which talented developers create world class web applications.

The job is part psychologist, part librarian and part artist.  I have to understand organizational objectives and personal motivations, catalog knowledge and design components, and weave them together into a interface that so closely supports the intended task that it becomes invisible to the user.

Elsbernd's Hierarchy of Needs, described in my blog a few months ago, has been hanging on my wall at work.  I've given it some thought and while there are aspects of it that I really like, such as the concept of satisfiers and delighters (functionality and performance are satisfiers, usability and aesthetics are delighters), I was forced to admit the model doesn't hold true for all applications.

The original idea came from the traditional commercial enterprise software development model, in which at first, relevant functionality was enough for a new application to be successful.  As long as the software accomplished something users were previously unable to do, it didn't matter if the system was slow, difficult to learn or use, or hideously ugly, it accomplished a task.  Eventually, users become complacent and start demanding more functionality, faster or more dependable performance, easier to use and more pleasing to the eyes. Eventually, functionality and performance is taken as a given, and only their absence is noted.  Usability and Aesthetics, on the other hand, are delighters, in that their presence can increase satisfaction with a system.  This is a gross generalization, of course, and doesn't adequately defend against some very legitimate criticisms.

One of the podcasts I listen to - Boagworld by Paul Boag - had an interesting feature this week about context - about how where we are influences what we want from a website. Paul listed five contextual considerations for developing for the web; Environment, Device, Comfort, Mood, Time.  He makes good points about them, especially the lack of traditional input tools on most mobile devices, but doesn't go far enough into motivations.  This tied into many things I've been thinking about with the release of the 3G iPhone.

Like most people, 99% of my browsing is done from a laptop or desktop sitting on a desk.  For these times, traditional websites are fine, and even optimized for the experience.  I have an expectation that I can browse, dig deeper and see layouts on a computer with high-bandwidth, full browsers and plugins and a high-resolution, large screen as they were intended by the designer. From design to implementation to interaction, everything about the web browsing experience has been optimized for my viewing pleasure in a relaxed setting.

When you change things, people will resist.  When you change things for the better, people will still resist.

Often, just being better isn't as important to acceptance of a new design as conformity with the conventions in place.  Take, for example, the control panel in Windows Vista.  Arguably, the configurations and applications are better organized, better labeled and easier to find.  Easier, that is, if you haven't already been trained to find them in different areas and under different labels in earlier versions of Windows.  There are twice as many controls in the Vista control panel, giving the user more granular control over the settings and configurations.  That should be a good thing, right?  Not if you are used to finding configurations buried under other objects and have just accepted the fact and moved on.  Now you are being asked to relearn where things are and will spend time fumbling around, especially if you have some legacy computers running different versions of Windows. While this reconfiguration will benefit new users, experienced users don't see enough marginal benefit to accept the change gracefully.

This concept should be considered in all design projects.  While you might have a better way of doing things, decide if it's enough better to force all of your users to change their mental maps.  It's amazing what people can get used to (imagine some of the legacy systems in use today), but unless you can provide compelling reasons to change, people won't.  Your choices are to follow conventions, thereby further cementing that design in the minds of the users, shift them radically and force the transition, or introduce the changes gradually through evolution.

One thing is certain.  No matter how you make changes, some users will complain. The key is to provide enough benefit that they get over it quickly.

For another perspective, see Gery's Law.