Information Technology Reference
In-Depth Information
6.3.3.5 Breakout Box: Need for Cognition
Many users do not want to do problem solving. They would prefer to perform the
task directly. However, some users like to do problem solving; they like to think.
These are people who do crosswords, solve Sudoku puzzles in meetings, like to
build things, or debug systems. Cacioppo and Petty ( 1982 ), as well as previous
researchers, describe this difference as a difference in the ''need for cognition.''
Users with a great need for cognition agree with statements like:
I really enjoy a task that involves coming up with new solutions to problems.
I would prefer a task that is intellectual, difficult, and important to one that is somewhat
important but does not require much thought.
I would prefer complex to simple problems.
Thus, users with a higher need for cognition will more likely find poor inter-
faces a challenge rather than impossible. As you develop your system, you might
consider how interested your users are in problem solving with it. While the
literature on individual differences suggest that the need for cognition varies by
individuals, it might also vary by task: for games, you can encourage more
problem solving; for entertainment and informal use, there may be some problem
solving involved; for high stake interfaces, such as health, transportation, or
financial systems, most users will not want to solve problems.
The need for cognition has also been used to study how people are persuaded
and form opinions. Those with a high need for cognition focus on the arguments
put forward. Those with a low need for cognition focus more on peripheral cues,
such as body language, social status of the speaker, and fluency of the speaker.
Your users may also be the judges of your system in the same way; and you may
wish to make sure your system appeals to both types of users.
6.3.4 Ill-Structured Problems
Some problems appear harder than others. An important group of problems are
more difficult because they are ill-structured. That is, they are not clearly defined.
Writing, for example, is ill-structured. When you are writing the goal state is not
clear—it is not clear when you are done. It is also less clear when writing what all
the operators are (unless you examine everything on a character by character
basis—then the problem is completely intractable!). Many aspects of design can
also be seen as ill-structured problems. For example, when is the new phone or
new interface finished being designed? These problems are also called ill-defined
or messy problems. They often occur in the real world, and a major step forward is
to make them more defined.
Ill-structured problems can be ill-structured in several ways. They can have
poorly defined operators or the operators can be unknown to the problem solver.
Search WWH ::




Custom Search