This is the beginning of an article outline/proposal I've been mulling over. I will continue developing until it escapes...
“The human mind is exquisitely tailored to make sense of the world.
Give it the slightest clue and off it goes, providing explanation,
rationalization, understanding.”
- Donald Norman
We all think we know how the world works. In fact, in psychology, the terms assimilation and accommodation are used to describe the process of adding a new bit of information to what we already know. In assimilation, we take a new bit of information and add it to our existing mental model of how the world works. In accommodation, we take the new bit of information and change an existing mental model or create a brand new one to explain the new knowledge we have.
Mental Models and how they develop
Mental models are the representations people have of themselves, others, the environment, and the things with which they interact. People form mental models through experience and accretion (when new information fits into an existing schema, and thus is quickly comprehended). A mental model can be developed, added to, or modified any time a person’s behavior and the subsequent results are connected in the person’s mind. In reality, users interpret results and sometimes form an accurate model of what is being experienced, sometimes the results are correlated but without a true cause and effect relationship, and sometimes the results are a coincidence. Regardless of the how’s and why’s, if the actions and outcomes are understood by the person as linked, a mental model can be formed or strengthened.
How do mental models apply to software systems?
Because there is more than one role involved in the design, development, and use of software, more than one mental model is imposed upon the system. Norman identified this and began to label the different models associated with software. Germane to this discussion include:
- The Design Model is the designer’s idea of how the system works and represents the true nature of the tasks.
- The System Model is how the system actually behaves and represents the nature of the tasks.
- The User’s Model is the mental model developed through interaction with the software (which incorporates aspects of both the Design Model and the System Model).
The designer expects the user’s model to be identical to the designer’s model, but if the system model is not clear and consistent, the user will end up with an incorrect mental model.
For example, a user's mental model is that creatures with four legs are dogs. When they come across a cow, they have a quandary.
When the performance model and the user's mental are not synchronized, the user believes "the system is broken" or impossible to use.
Equilibrium, assimilation, accommodation – Piaget
This conflict in models is known as disequilibrium, or a cognitive dissonance between how the user believes the system works and how it is behaving. The user has several options at this point, but assuming the user wants to keep using the system, they have to either assimilate or accommodate.
If the user determines that a cow is another animal with four legs, they can assimilate the new creature into their mental model by expanding their definition of four legged animals. If they saw a dog with an amputated leg, they could assimilate by seeing it as an exception the rule, but not a new kind of creature.
If the user sees a table with four legs, they must create a new mental model of four legged objects. This process is accommodation, in that they now have an entirely new construct to which they can assign instances.
Mental inertia and cognitive dissonance
Users resist both of these processes, especially with examples that are much less concrete than our dog/cow. If the user thinks they know how a system works and it behaves unexpectedly, it is easier to classify the behavior as a system error (another mental construct) than to change the model of how it should behave.
EVOLUTION VS INTELLIGENT DESIGN OF SOFTWARE SYSTEMS - provocative, yet descriptive, controversial?
This evolutionary process can lead to confusion and despair. Imagine if the same approach were applied to other areas – start building the house before you decide how many bedrooms to have – if you change your mind, adjust what you already have to accommodate the new plan. As ridiculous as this seems, complex computer applications are often built the same way.
Sometimes the reason has to do with scope, budget, time, vision. Describe examples of each...
Describe actions, results of each of these examples.
Scope - a new tool is developed with a specific set of functionality. After it rolls out, users see potential and start using it for other tasks. They then influence the developers to expand the system to encompass more and more of that new task (assimilation).
Budget/Time - no money to develop the system with full functionality. Analysis and development are restricted, leading to a incomplete understanding of the performance environment.
Vision - Related to budget/time and scope, if the developers are not looking to a future state roadmap, it is easier to develop a band-aid approach to solve the immediate need. Decisions about architecture, data schema and interaction design are secondary to solving the problem in front of them.
Complex applications and how they develop (software lifecycle)
Developing a new application (capability)
All design begins with a need. Successful software begins as an opportunity to do something users couldn't do before, or couldn't do quickly/easily. This new capability is enough for users, who are so delighted they will overlook long learning curves, cryptic codes and unfriendly error messages.
Upgrades (extended capabilities added without systematic plan)
Once the base need is met, the users start expanding their horizons. They ask for the next step in the process, utilities to handle exception cases and functions for additional user groups who now want their own lives to be easier.
User experience (disequilibrium, functional overload, rework the performance model)
At some point, there is a diminishing return on additonal functionality. At this point, the users become more discriminating and start demanding usability. The learning curve, the error recovery and the aesthetics all become important. By this point, however, the interia leads long-time users to resist any change, saying things like "The system does everything we want, why change it?" They have forgotten the pain of learning the system and would rather maintain their model in favor of making changes that would help future users.
The cure
The cure is to know where you are going before you start. A consistent roadmap, user interface design standards, understanding of performance environment...
- Enterprise architecture
- Roadmaps
- Standards and guidelines