Elsbernd's Hierarchy of System 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.
Systems aren't built in a hierarchy - all systems have some level of all four attributes. They serve some purpose, have some level of performance, can be used at some level, and have a presentation. It's not accurate to say systems are built one layer of the hierarchy at a time or to imply that the concerns are always approached in the same order.
The dividing line between satisfiers and delighters is not black and white. Some features and functionality are delighters. When a system does something for you that you didn't expect or even know you wanted can be a delighter, and many of the aesthetic choices made are definitely dissatisfiers.
Not all systems will become "self actualized" at the top of the hierarchy. There are reasons systems may never be developed into an attractive, easy to use system. Sometimes the benefits don't justify the cost. If a system is going to be retired, no new development will be funded. The model does not address the downward pressure of cost or limited resources against the desire to climb the hierarchy.
After weighing these criticisms, my thoughts lately have changed. I no longer see the factors in a hierarchy, but as competing priorities for a limited pool of resources.
All systems development teams must prioritize their time and resources among the four factors. To increase the resources for usability, attention is taken away from the others, unless additional budget is found. There is no ideal allocation of resources to each of the factors. Just as no two applications have the same requirements, the needs of the organization or users may be different from one project to the next. Depending on the functionality needed, performance environment, age and training of the users and the visibility of the application in the marketplace, any one of these factors may be weighted more heavily during development.
The allocation of resources may change over time as a system matures. Once the application is established or as competition enters the market, balancing the factors may become a higher priority. The main point is the factors must fight for space within a given budget of resources and energy.
Traditional systems may follow the hierarchy early in their evolution and favor functionality over any other factors. Systems like mainframes and legacy systems may have interfaces considered unusable by modern standards. They may be difficult to learn and use, involve obscure and arcane codes, or even paper punchcards. Younger users may not believe it, but there was a time before graphic user interfaces. Many of these systems still exist in organizations because they work. They do something relevant for the company and they haven't caused enough pain to be retired or upgraded. Because these systems do what they do well, they no longer receive funding, and the resources they do get are focused on maintaining the system, not upgrading functionality or improving the user experience.
On the other end of the spectrum are the trendy novelty applications that take advantage of trends or new developments and are seen as the "gee whiz" stuff for a limited amount of time. Consider new developments such as animated gifs, scrolling marquees or flash intro pages. These toys don't add much functionality to a website, and are mostly eye candy. For the most recent examples, turn to the iPhone applications. Developers saw a rich media device with the novelty hooks of a touch-screen and accelerometer and rushed out the technological equivalent of cotton candy such as the virtual lighter (moves as you move the phone), koi pond, virtual beer and light saber. These applications have next to no functionality other than momentary amusement. The performance of the application is not a focus as it doesn't do that much to start with. Likewise, if it doesn't do much, it won't be hard to use. These applications have a limited shelf life as the novelty dies, but for the brief period of time, they can be successful.
I have to thank several people for challenging my thinking and discussing the concepts with me, including Matt Sanning and Greg Moore. These thought exercises, like the iPhone apps, may not be the most productive things, but they keep me entertained.