FU N
JOHN NI . CARROL L
JOHN C . THOMA S
We are in many ways just getting started on the proble m
of developing a set of concepts and a vocabulary fo r
describing the quality of software and in particular its
usability. Consider : easy to use, easy to learn, use r
friendly, productive, fun . How do these, and other terms
used to describe software differ ; how do they overlap? In
this paper, we examine the confusion between being fun
and being easy, as these terms are applied to end-use r
software and systems . This confusion is interesting in
that we can ask how such a circumstance might have eve r
occurred . It is challenging in that we need to separately
clarify the concepts of ease and fun, if they are to provid e
us any analytical leverage in understanding softwar e
quality .
THE CONFUSION BETWEEN FUN AND EAS E
When the ascription easy is applied to a system or some
software, for example, in a trade press review, wha t
exactly is being alleged? Invocation of the term easy i s
rarely based on any real measurement of the behavior of
humans actually using the system or software . Peopl e
who call software easy have rarely spent the time makin g
the usability measurements and observations that migh t
seriously sustain this judgment . They don't really kno w
whether the software is easy or not in any technical sense .
But whatever it is that they are basing their judgments o n
is still of interest, for often these judgments express a
consensus view .
An example of what we have in mind can be found in th e
story of the Lisa system . During its lifetime (1983-1985 )
Lisa was widely labeled as a breakthrough in ease—eas e
of use and ease of learning . However, a laboratory stud y
of professionals learning to use Lisa revealed that in fact
SIGCHI Bulletin
the system was probably no easier than other more
conventional systems of that period (Carroll and Mazur ,
1986) . The learning problems were different in som e
respects to be sure, but there were plenty of them .
Nevertheless, judging from the popular and trade pres s
reviews and the impacts on later system interface designs,
people really liked the Lisa-style interface, and that i s
very important . We suggest that the Lisa is in fact a n
example of a system that was relatively more fun ,
although not necessarily more easy to learn and use .
What is the relationship between ease and fun? For us ,
ease fundamentally implies simplicity . Things that are
easy are learned quickly, with few steps and few errors .
They can be communicated to others with few words an d
performed fluently . Fun not only fails to carry thi s
monolithic implication of simplicity, but ofte n
contradicts it (e .g., learning to operate a new foo d
processor or to hit curve balls) . Paradigmatic example s
offun indeed must have sufficient complexity or they fal l
flat (jokes that are too obvious, games that are no t
challenging) . The complexity must appear warranted t o
the person (tacking on ad hoc complications will no t
evoke fun) . It seems that things are fun when we expec t
them to be of moderate complexity (interesting bu t
tractable) and then in fact find them to be so (i .e ., not
too difficult or too easy) .
We admit, however, that there are complications inheren t
in splitting fun from ease . To begin with, it does see m
that there can be tangling attributions involving both .
Thus, if the experience of learning to use a particula r
piece of software is fun (because it has been structure d
into a training game, for example), one might also come
21 January 1988 Volume 19 Number 3

to believe that the learning was easy in the sense that i t
required relatively less discipline, teeth grinding, etc . t o
accomplish . Conversely, if learning to use a piece of
software is easy (i .e ., takes very little time, very fe w
steps), then one might similarly come to believe that th e
learning was fun in the sense that it was relativel y
pleasant compared with other software learning
experiences(!) .
But even aside from tangling attributions, there ar e
plausible causal connections between ease and fun . If a
system is more fun, it stands to reason that it will be used
more, which could have the effect of promoting mor e
thorough learning, which in turn would make it easier t o
use at least in the long term . This scenario makes th e
problem begin to seem like asking whether the chicke n
caused the egg or the reverse . The difficulties in splittin g
ease and fun are complemented by the psychological
mechanism of "cognitive consistency" (Festinger, 1957),
the tendency for people to rationalize all their belief s
into a simple and highly consistent framework . The drive
for cognitive consistency encourages people t o
subjectively smear their impressions into monolithi c
categorizations . Thus, despite the details of whether a
system is seen as fun because it is easy, seen as eas y
because it is fun, or even eventually experienced as eas y
because it was initially fun and therefore got used a lot ,
there is a tendency for people to generalize across detail s
and more simply classify the system as "good"—meanin g
easy, fun, and perhaps more besides . Indeed, the only
way to avoid subjective smearing like this is to place both
systems side by side and force the contrasts out in a
usability experiment .
HOW IMPORTANT IS FUN ?
The potential for confusion between ease and fun is
serious . As we have argued, it is often difficult for peopl e
to split the two in analyzing their own experience, yet it
is necessary to do this if we are to understand software
quality (and improve it) . To the extent that we confus e
the two, we may be doing the wrong things to improv e
software quality . This confusion could lead to the
recommendation that the key to software quality is t o
make software as simple as possible . (Indeed, thi s
conclusion is often voiced now in discussions of
usability .) Yet, as we observed above, fun requires tha t
things not be as simple as possible . Our view is that th e
issues are more subtle, that we do not necessarily want t o
merely make things as simple as possible . We ought t o
make them fun .
Experiences that are fun are more attractive to people of
course, but fun is also likely to have powerful influence s
on what people will even try to do and on how long they
will persist . In a classic experiment, Lepper, Green an d
Nisbett (1973) studied a situation in which childre n
played with colored pencils . Half the children were
simply allowed to play with the pencils, the other hal f
were rewarded for doing so . The effect of this
manipulation was that the unrewarded children played
with the pencils longer than those who had bee n
rewarded . Lepper, Green and Nisbett suggested that the
SIGCHI Bulletin
intrinsic reward of the colored pencils alone was a
stronger incentive than the extrinsic reward offered fo r
playing with them, and that in fact, offering the extrinsic
reward weakened the attractiveness of the pencils .
This work has stimulated some analysis of compute r
environments and the sources of intrinsic reward tha t
may (or may not be) exploited by them . Malone (1981 ,
1984) analyzed the attractiveness of educationa l
computer games for children, stressing the capacity of th e
games to promote an intrinsic motivation toward
learning . Children playing these games are encouraged t o
construe difficulty as challenge, unfamiliarity as fantasy ,
and uncertainty as curiosity . Thus, instead of having t o
rely on an extrinsic incentive, like a teacher's praise, i n
order to overcome difficulty, unfamiliarity, an d
uncertainty, the child decides himself to take on
challenge and fantasy . This intrinsic, self-generate d
motivation is more powerful .
Carroll (1982) analyzed adult navigational games lik e
Adventure . Games are typically divided into episodes o r
phases, and these in turn are clearly subdivided, givin g
the user a sense of place in the game scenario . Within an
episode, games are very responsive : when the user doe s
something, it has a visible consequence . Making progres s
toward situational goals is also made obvious (e .g., by a
score) . These properties of spatiality, interactiveness, an d
feedback are sources of intrinsic motivation and draw th e
user into the game . The object of a game is to succeed ,
but games also typically encourage the attitude that it i s
all right to fail . Moreover, the consequence of failing i s
cushioned : nothing too terrible happens . Both of thes e
properties encourage users to take risks they might, i n
other situations, eschew . Finally, a game always project s
to the user some sense of control ; the person always ha s
substantial influence on the outcome . Clearly, some o f
these techniques are not exploited by current softwar e
and systems . Users often have little sense of where the y
are in a system or task scenario or of whether they are
making progress ; errors can be catastrophic (e .g. ,
accidentally reformatting a hard disk) . But clearly als o
many such techniques could be exploited . For example,
presenting an interface that is initially simple but
increases its complexity over time to challenge the user :
success is within reach at each stage, but becomes mor e
and more demanding. Interfaces that arouse imagery an d
emotions via the use of metaphors (animated mess y
desks) can stimulate fantasy . Providing novel stimulatio n
via the use of media (sound, graphics) or randomnes s
and humor can stimulate curiosity .
These ideas are tantalizing . There are, of course, alread y
commercial systems that have exploited some of them .
The metaphoric icons of the Lisa are manipulated b y
pointing gestures and create a fantasy electronic deskto p
for the user . The high resolution graphic presentatio n
helps create a sense of spatiality in which data an d
operations are there . The simple mouse pointing devic e
enhances the interactiveness of the system and the sens e
of control the user feels. But despite a growing numbe r
of such examples, it is still more striking that there is a
22 January 1988 Volume 19 Number 3