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.
A constant among psychology and instructional design classes is Maslow's hierarchy of needs. Whether you agree with the criticisms of Wahba and Bridgewell or not, Maslow's theory still provides a valuable framework for describing and evaluating individual motivations. The notions of hierarchical needs wherein one set of needs must be satisfied before the next set can be prioritized can be applied to system design as well, and is described by the blatant ripoff, er, homage, Elsbernd's Hierarchy of System Needs.
What do you want in a system? The answer depends on what you need to do and how you are accomplishing that goal currently. In the early days functionality was enough as long as the system allowed you to do something you couldn't do before, users would suffer through horribly obscure and arcane coding to complete their tasks. Witness the costs, time and effort involved in old punchcard computers, yet because it allowed them to do something new, companies endured it.
For a time, functionality is added, but functionality eventually loses it's glow. When users are forced to wait while systems are down or slow, system developers are tasked with making it faster and more powerful. The need for performance comes to the top of the priority list.
At some point in the system's evolution, a sufficient level of functionality and performance is reached, and the next competitive advantage becomes usability. The ability for users to complete tasks with a minimum of training and in various contexts becomes a selling point when all functionality sets are comparable. Ease of learning and ease of use allows less skilled workers to complete tasks, or skilled workers to focus less on the system and more on their work.
Aesthetics is the final enhancement, in that if the system is usable, it can also be enjoyable or pleasant to use. Aesthetic features, such as enhanced graphics, animations, sound, layout and balance on the page all impact the user experience.
Of course, all of these features exist to some extent in every system. The balance between these four factors is what can make or break system success, based on the hierarchy of system needs.
Maslow's Hierarchy of Needs
Maslow's hierarchy of needs is often depicted as a pyramid consisting of five levels: the four lower levels are grouped together as being associated with physiological needs, while the top level is termed growth needs associated with psychological needs. Deficiency needs must be met first. Once these are met, seeking to satisfy growth needs drives personal growth. The higher needs in this hierarchy only come into focus when the lower needs in the pyramid are satisfied. Once an individual has moved upwards to the next level, needs in the lower level will no longer be prioritized. If a lower set of needs is no longer being met, the individual will temporarily re-prioritize those needs by focusing attention on the unfulfilled needs, but will not permanently regress to the lower level. For instance, a businessman (at the esteem level) who is diagnosed with cancer will spend a great deal of time concentrating on his health (physiological needs), but will continue to value his work performance (esteem needs) and will likely return to work during periods of remission.
Elsbernd's Hierarchy of System Needs
A similar model is proposed for the evolution of software development.
Deficiency needs - These needs are required for success, but as soon as the needs are met, they are taken for granted. Their absence causes dissatisfaction, but otherwise they are invisible to the common user.
- Functionality - features and capabilities relevant to the task at hand, are the fundamental need for systems. If the system doesn't do anything you need to do, it has no value.
- Performance - the system must respond in a reasonable time, provide secure access and access when expected.
Growth Needs - These needs are not strictly required for task completion, but they improve the user experience to build loyalty and positive perceptions of the system and tasks. This delight can improve satisfaction, retention and morale among users.
Usability - Usability makes the system accessible to a wider group of users. Whereas early word processing and desktop publishing tools were only used by trained users in specialized departments, now everyone has one of these tools on their desks due to improved user models built into the systems and integration with their other tasks. The systems are more intuitive through the use of common ui conventions and affordances (the design of the system controls suggests their use).
Aesthetics - People like well-designed systems. Attractive systems are perceived as faster, better performing and more effective than unattractive systems.
Just as in Maslow's Hierarchy, systems develop from the bottom of the hierarchy up. The higher needs in this hierarchy only come into focus when the lower needs in the pyramid are satisfied. If a change in process or product causes one of the lower needs to become unfulfilled because the current system can no longer meet the needs, the functionality or performance needs will be reprioritized over usability or aesthetics until functionality and performance are restored.
The final factor not represented in the current document is cost. Cost is a limiting factor of how much time and effort is expended getting to higher levels, to achieve and maintain the level of satisfaction or delight demanded by the users. Organizations must determine the cost of achieving the next level and the competitive advantage it will bring.
There are many possible reasons for poor performance. In the past, documentation or training was the only solution to these problems, as phrases like, "It's a training problem," or "We'll put it in the manual" were catch-all solutions to poor processes. Thomas Gilbert's Model analyzes performance deficits from six standpoints. The interventions to overcome performance barriers have the highest leverage (cheapest to implement for highest return) from box 1 to 6. In other words, if the problem can be solved through better communication of expectations, it is more effective, easier and cheaper to the organization than a training program to teach performers a task they don't understand.
|
Information |
Instrumentation |
Motivation |
|
|
Environment (organizational factors) |
1. Data, information Do performers know what is expected? Interventions: Communication, clear statements of purpose and expectations |
2. Resources, tools, environmental support Do performers have what they need to perform? Interventions: Open supervisor support, appropriate tools, applications |
3. Consequences, rewards, incentives Do performers get appropriate feedback? Interventions: Consistent and immediate feedback of results, consequences must be linked to performance |
|
Performer characteristics (personal factors) |
4. Knowledge, skills Do performers have the knowledge or skills to perform? Interventions: Training, Job Aids |
5. Capacity Are performers capable of performing? Interventions: Selection process |
6. Motivation Do the performers care about the job or their performance? Interventions: Selection process |
In analyzing the root causes for a performance issue, we often will identify issues and solutions that have nothing to do with documentation or training. Because of this, we are no longer limited to those solutions, but can design performance centered systems leveraging all of the tools at our disposal.
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.
"If the person responsible for using the system does not benefit, the system is doomed to failure." - Grudin's Law, Jonathan Grudin
We need to recognize that pushing our pain, that is, our needs, on someone else to implement will at best give us grudging and resentful compliance. If we can ensure that the person receiving the benefit is the one doing the work, we will get a more motivated group of performers.For example, the marketing group for a retailer decides they want zip codes from all of their customers. It involves more work for the cashier, and is resisted by customers. If there is no clear incentive for the cashier, or consequences of failure, the cashiers will enter false data in an attempt to make their lives easier.What we need to do in cases like this is to show the clear benefits of the task to the user and get them "on our side". The other option is to monitor and correct issues, but the carrot is preferable to the stick.
