Last changed 31 Jan 2000 ............... Length about 5,000 words (32,000 bytes).
This is a WWW document maintained by Steve Draper, installed at You may copy it. How to refer to it.

Web site logical path: [] [~steve] [fun] [this page]

Analysing fun as a candidate software requirement

Stephen W. Draper
Department of Psychology
University of Glasgow
Glasgow G12 8QQ U.K.


Written in connection with Monk's Computers and Fun workshop, and published in the associated special issue of Personal Technology 1999 vol.3 pp.117-122.


Analysis of concepts related to "fun" is used to suggest the main areas where fun may be important to software design. The issue is important as many analyses and design methods fail to allow for designs aimed at user enjoyment, even though computer games are now a major industry. The main cases seem to be either where enjoyment is the chief aim (requirement) of the design, or where learning is important. The phenomena of "flow" experiences are also important here, and raise the issue of designing for desirable cognitive modes of interaction, as well as for desired end results. However the relationship of learning and fun, while clearly important, is complicated.


Computers, fun, motivation, flow, design methods.

Contents (click to jump to a section)

1. Introduction

At least if we neglect such hardware possibilities as electric massage attachments or microeletrodes inserted into the brain's pleasure centres, the issue of computers and fun is largely about the cases where fun could be a desirable requirement for software. Since fun is a user response or experience, user related aspects of a design, including the user interface, will be of central importance. This paper offers some analysis of the relationships between fun and software design aims: where fun could and couldn't be a sensible requirement. It will not discuss the methods for implementing such a requirement.

Fun cannot be part of the requirements for all software, despite occasional libertarian claims to the contrary, at least if design is to follow users' needs and wants. If software use were always fun, it could never be a transparent means to an end: it would always be obtruding on the user's attention. This is not always what is wanted. Personal digital assistants, pocket calculators, flight deck safety systems, and so on, like the processor in your microwave oven, should surely be designed to fade into the background. Fun requires conscious attention, and we often do not want to give that when we are trying to achieve something else, any more than we want a difficult user interface to intrude on and distract from a work task.

However there are three different major cases where fun is, or could usefully be, important in user software: where enjoyment is taken to be the main function of the software, where learning is the main function, and where learnability is considered as an important secondary requirement of software with some other main function. This paper offers a conceptual analysis of fun in terms of other concepts such as intrinsic and extrinsic motivation, "flow", and others; and relates the analysis to these three major cases where fun may sensibly be taken as a requirement in designing software.

2. Computer games

Whenever software is designed for leisure use i.e. where the user's main goal or "task" is amusement, and the software is designed to serve that end, then fun is centrally relevant. This in itself is an important point to recognise for HCI and software design in general. Dowell & Long (1989, 1998) conceive of human factors, cognitive engineering, and HCI as inherently about work and work systems. This is not an incidental feature of their analysis: they see the external work domain as the sole locus of benefits for the interaction and the user as the locus of (usability) costs. It is an important feature of their analysis that the purpose and benefits are external and "objective": they do not address the implications of user-centered design suggested by the case of computer games — that the chief requirements for a design could be located in a human response (did the user have fun?), not in some external work product. Their approach is thus clearly inadequate to cover the computer games industry (now said to have a global turnover greater than that of Hollywood), let alone the cases discussed below where human users may enjoy the interaction even though that is not the governing purpose. None of the peer commentaries published with their second paper mentions this point, and equally most task analysis methods cannot cope with "tasks" whose goals are user mental phenomena rather than external states of the world. This suggests that it requires emphasis, theoretical attention, and exploration of the consequences for methodological formulations. Fun is a serious business for computers, whether measured in dollars or in the changes to design methods now clearly required if published methods are to match the needs of actual practice in major industries.

We will assume here that computer games are played for amusement or fun (ignoring the possibility that they might be played professionally, and that that might require a different design) — in other words, for intrinsic motivation. We may distinguish extrinsic from intrinsic motivation, where the former refers to external reasons for action (e.g. working for pay, doing chores for a relative), while the latter refers to a person's inherent enjoyment in the activity for its own sake (e.g. eating, going to a movie). It is important to realise that these are not mutually exclusive alternatives, and some actions may be motivated in both ways. When people say they did something for fun, they are drawing attention to the existence of intrinsic motivation for the action, but that doesn't itself mean there cannot have been extrinsic motivation too. Conversely, when they say they had to go to Hawaii for work, it doesn't prove they didn't enjoy it. This distinction is similar to that of work (extrinsic) vs. leisure (intrinsic) (Rieber et al., 1998) except that leisure tends to get defined as whatever no-one else pays you for which includes things like going to the dentist, while on the other hand many people enjoy at least parts of their job, so leisure vs. work does not reliably correspond to enjoyment vs. unpleasant activity. Intrinsic and extrinsic motivation, while contrasted, are separate attributes that can be present or absent together. We assume that computer games are designed to satisfy intrinsic motivation, and that this is the primary requirement.

Many different kinds of intrinsic motivation are possible (Malone, 1980; Malone & Lepper, 1987; Neal, 1990) including for example "idle" curiosity (who will win the match on TV? what graphics will appear on the next level of this computer game?) and arbitrary learning goals (will I get a higher score than last time? can I learn to score the maximum?). As those authors and others note, a number of different intrinsic motivations can be addressed, often in combination, in computer game design.

Inherent in the notion of fun seems to be that it doesn't matter what the product, the direct result, of the actions is: something is fun to do not done as a means to an end, i.e. it is an activity done for its own sake, the sake of the process. This is what play is, fun being play for pleasure. To see that playing essentially involves a process not an end state, remember that however much you want to win, you have played even when you lose; while if you are declared a winner by default, you have won but cannot be said to have played.

Fun is play for pleasure, but not all the ways a computer game may attempt to give enjoyment (i.e. satisfy various kinds of intrinsic motivation) are by play, and hence fun as it will be defined here: fun is only a subtype of intrinsic motivation. The use of sensory (indeed sensuous) features e.g. colour, video, sound, music all may be attractive and rewarding to game users without being play, and indeed information as in trivia quiz answers and fact based dramas may be of this type too. Fun seems to involve play, and play to involve performing a process for its own sake, while the wider notion of enjoyment or intrinsic motivation may equally only require a product or end state. Computer games, like any entertainment, can aim at providing both kinds of satisfaction: fun is not necessarily the whole story.

An important point to note, however, is that motivation and so fun is not in fact a property of an activity, but a relationship between that activity and the individual's goals at that moment. Most things that you find fun in the middle of a day on holiday you do not find fun when woken in the middle of a night during a work week. Furthermore, the demand level of a game if it is to be fun must be matched to the player's arousal level, which in part varies independently of the game, for instance with the time of day. One should expect to design different games for different arousal levels: for falling asleep over at night versus for being the main activity of a day. High-challenge, high arousal arcade games address one kind of user demand, but TV schedules suggest there is also a great demand for low-challenge material. As noted, it is a mistake to think this is about different user types: it is at least as much about how one individual varies from hour to hour in arousal and in how challenged they wish to be.

Similarly while one use for games is to absorb the players' attention, concentration, and abilities to the maximum extent, another use is to occupy the hands with an unconscious more or less automatic activity, leaving the mind free either to rest if tired or to brood on an unrelated problem: like going for a walk while continuing to think about the day's problems. Obviously the design of a game to require maximum mental consciousness and effort is different from the design of a game of the latter kind, to be soothing and undemanding.

2.2 The concept of flow

In touching on distinctions between intrinsic and extrinsic motivation and process versus product goals we have been considering the aims or goals of activities. However the means, particularly the cognitive modes, involved in performing the activities are also important to the experience and to user satisfaction.

The term "u-flow" is introduced here to refer to a smooth but unconsciously managed flow of actions by an individual. Examples might be driving on a familiar route, and arriving without being able to remember anything that happened along the way. The same applies to walking to work while thinking of something else, or performing any other routine action not requiring conscious attention. Note that while performing the activity, a person in u-flow may well be fully occupied in thinking about something quite unrelated.

"C-flow" is introduced to refer to a smooth flow of actions that, in contrast to u-flow, is managed by and fills the consciousness of the actor. Examples might be driving a car sufficiently fast and dangerously to require the driver's total attention; debugging a computer program by reacting to error messages and test output; playing an absorbing computer game; being completely absorbed by watching a movie or reading a novel. (Thus c-flow may not involve physical actions at all, but always involves complete mental attention.) At each step, the next action suggests itself unproblematically: the person is not at a loss to think of anything to do, nor worried about how to select between more than one possible next move, nor worried about whether they have forgotten to do something important. C-flow also corresponds to an optimum balance between boredom (when neither this nor any other available action seems important) and anxiety (when too many goals and actions seem important, urgent, and uncertain to be satisfied).

The term "flow" originates from Csikszentmihalyi's work (1988, 1990) in another area, where he in turn attributes it to one of his interviewees, and is adopted because it felicitously alludes to the connected and effortless properties of these modes of action, but the initial letters "U" and "C" are added to distinguish two different modes of this kind. His work is directed towards a theory of "optimal experience" or happiness. This work mainly relies on questionnaire and interview instruments, and has tackled subject groups such as painters and sculptors. It attempts to describe and investigate periods of positively valued total involvement they achieve or experience, referred to as "flow" or "autotelic experience". Referring to this work, Jones (1998) listed these as components of the experience:

  1. Task that we can complete
  2. Ability to concentrate on task
  3. Task has clear goals
  4. Task provides immediate feedback
  5. Deep but effortless involvement (losing awareness of worry and frustration of everyday)
  6. Exercising a sense of control over their actions
  7. Concern for self disappears during flow, but sense of self is stronger after flow activity.
  8. Sense of duration of time is altered.

Clearly this analysis could be of interest to games designers, as it seems to offer an account of how players may become absorbed by successful computer games. However, though missing from Jones' list, it is clear that an account of optimal (most greatly valued) experience for Csikszentmihalyi's subjects requires not just c-flow, but "engagement" — connection to the person's deepest values and goals.

One problem with Csikszentmihalyi's approach is that it fails to distinguish between separate properties of experience: u-flow, c-flow, and engagement. Another is that an alert person may flick in and out of c-flow from moment to moment e.g. think for a moment of other concerns without it breaking the mood. Questionnaires and retrospective interviews are hopelessly blunt instruments for investigating moment to moment consciousness (Hedden, 1998a, 1998b). A full account of these phenomena may still be some way off. Nevertheless concepts of flow seem likely to be important for understanding fun and computer games by introducing an account of the quality of the cognitive processing as well as of the end results and motivation, just as Hutchins et al. (1986) did in their account of Direct Manipulation.

3. Learning at work and school

The second major area where fun could be important to computer applications is wherever learning is an important part of the work domain, and computers are at the centre of that work. In skilled jobs, particularly "professional" ones, where each project is different, the worker learns more about the work domain in finding the solution to the current project, and so becomes more experienced and more valuable to clients. In jobs where software is at the centre of work (not as a low level tool, but as the main means to major work goals), then in principle it should be designed to promote this domain learning. Furthermore, there are educational applications, where learning is the whole purpose of the software. There are arguments that play and fun could be inherently involved in such learning.

As noted above, play is about performing a process, and in particular to discover what the outcome will be (e.g. will I win? can I build this chair? and if so, how?). Play thus necessarily leads to learning of the "learning by exploration" kind, where the means are determined in advance and the effect is learned. (This is in contrast to problem-based learning, where the result, e.g. baking bread, is specified in advance, and the means are to be discovered.)

Since play is about discovering the outcome of the process (the consequences of some rules), learning will always result. All learning except the most alienated rote memorisation of isolated and meaningless facts is in an important sense the learning of rules. This is true not only (obviously) of learning procedures, but also of learning concepts: a general concept can be seen as a rule relating members of a class to each other and to an abstract description defining the class. To learn what "force" is in physics it is not enough, in fact is of hardly any use at all, to learn the words "a force is a push or a pull": you have to relate this phrase to the force between your hands and a supermarket trolley (stops as soon as contact is lost), the invisible reaction force that a table applies to support a mug resting on it, and so on. We may, then, sensibly regard learning as centrally concerned with discovering and exercising the relationships between rules (including generalisations) and their consequences. Langer (1997) argues that even learning normally conceived of as about rote learning of basic skills must be seen like this, at least if learning is it be effective.

All play thus causes and supports learning (although it may not be done for that reason). But it is not true that all learning is play. Exercises (whether gymnastic exercises, maths problems, or French translations) are process goals from a pedagogical viewpoint (i.e. the teacher believes the benefit is in doing the process, not in producing an answer useful for something else). But so often they are not play because they are not done by the learner to explore the outcome. Instead they are typically set and understood by the learner as product goals ("get the right answer") even if any surviving learning benefit comes from the process i.e. is the same as if it were done as a play activity.

However there are many educational arguments — although not consensus — that all learning should be play. Such arguments are closely related to Langer's (1997), to constructivism (Watzlawick, 1984) and its central tenet that learning depends upon learners building links from their own experience, activity, and discoveries to what is learned, and to the work on deep and shallow learning (Marton et al., 1984). It is coming to be recognised that this applies to programming as well. In old official stories of software engineering, you start with requirements, and programming means creating software that exactly matches them. In reality, in Human Computer Interaction, and in newer accounts of software engineering, it is only by creating software (often called "prototypes") that the real requirements are discovered. In this case the process is about discovering what the product is, and so is a form of play in which software engineers learn what the requirements are through exploration (i.e. play).

Nevertheless, despite those arguments for organising learning as play, there are also other important educational ideas that centre on organising learning around product goals and so seem to imply that neither fun nor play have much place in learning. Problem-based learning (Boud & Feletti, 1991) is increasingly being adopted in medical schools and elsewhere. The feature of this approach is the organisation of learning around real world tasks: the opposite of taking a set of rules (or concepts) and playing with them to explore their range, implications, and uses. The "situativity" ideas about learning developed by Jean Lave and others are even more oriented to specific outcomes and real world settings. The essential model here is that of apprenticeship, and scaffolding learners as they acquire skills that contribute to a product outcome. These ideas also are associated with strong motivational benefits for the learners, but in a way diametrically opposed to fun: learners find them motivating exactly because they see a strong and direct connection between their learning and the real world situation they are being empowered to contribute to. This is the opposite of both friviolous enjoyment and learning for its own sake.

Another indication comes from examining the obvious idea that has been pursued by some educational software designs of adding enjoyment as a rewarding extra ingredient e.g. by attractive sounds and pictures, and by game structures superposed on top of the pedagogical aims. However Langer (1997, especially ch.3) argues that to make learning enjoyable it is best NOT to add "fun" because that sends the message that it is work that needs such extrinsic rewards added to it. In other words, adding a sugar coating sends the message that this learning is inherently unpleasant, when without that they might well be brought to experience it as intrinsically enjoyable. It seems probable that learning activities are, or perfectly well could be for most learners, intrinsically enjoyable and satisfying. But that is not their main motive; nor is it useful to make pleasure the main, overt goal for adult learners (preschool children are different matter). Focussing on the pleasure does not maximise or aid the learning. Rather we may hope for the main goal to be learning; for the means to be sometimes a set of play activities, sometimes a set of task-oriented problem-solving activities; and for enjoyment to be a frequent side-effect. In fact enjoyment in learning may be like pain for bodily injuries: a useful signal worth paying attention to, but not the main point or something that cannot be ignored once duly considered.

This suggests that if play has a role, it can at most be one component or approach; and if learning can be enjoyable, fun is not the only, and perhaps not the best, way in which that can be so. If you ask adult learners whether their educational learning is fun, they often hesitate, and hesitate more than if you ask whether they are enjoying it. This is because it involves more effort than most things described as "fun", but also can be more deeply satisfying because it can engage much deeper goals. It is this deeper engagement we should be aiming for where possible. We may perhaps conclude that fun raises issues that are important to designing software that supports learning, but that while related, it is not at the root of the matter. (But for a somewhat different view see Rieber, 1996.)

4. Learning as a subgoal

Most software involves the user in some new learning of the interface. As hardware and operating systems change regularly, most users are involved in regular retraining whether they like it or not. Could fun be relevant to this learning as a means to end?

In principle we might expect fun to make a contribution, applying the issues about learning discussed above to the case of learning a user interface. However this seems to be a most difficult area. Humour wears thin instantly, and "rewards" such as little animations are very often resented if they take any time or attention during a work goal. So often such "features" seem to be much more amusing and motivating to the programmer who created them than they do to the end user. The key almost certainly is the user's goals at the time: fun is not a property of software, but a relationship between the software and the user's goals at that moment. If the user is trying to get work done, then any feature which obstructs that will be as unwelcome as a phone call in the middle of the night to invite you to a party. We might therefore expect that when learning is the main goal, fun may be appropriate: this will be case in tutorials and training course material, where the user has devoted time specifically to learning the software. On the other hand in on-line help and "wizards", where the user is probably trying to get work done, then fun will probably not be appropriate but would be perceived as obstructive by the user. Thus the distinction between the user goals of learning and doing (wanting to learn versus wanting only to get a job done), that is problematic for the design of documentation (Draper, 1998; Draper & Oatley, 1992), is likely also to correspond to the cases where fun may and may not play a role in supporting learning with computers.

5. Conclusion

The view taken in this paper is that fun is play for pleasure: that is, to satisfy some intrinsic motivation. Since intrinsic and extrinsic motivation are independent, fun may often co-exist with additional "work" motivations. Play is activity defined by a process, undertaken to discover what the result will be. It will result in learning, but is often undertaken for other reasons; just as much learning does not involve play. Enjoyment (intrinsic motivation) is the main aim of computer games; but fun is only one kind of enjoyment, so game design may consider other kinds as well.

The issues raised by and involved in understanding fun are important in many ways to designing computer software, and should be taken seriously. However the relationship is not simple: for instance it is not true to say that all software should involve fun. The main connections seem to involve two things. Firstly, learning has an important connection with play, and so with fun, and almost all computer use involves human learning. Secondly, providing enjoyment is now a defining requirement of an important class of software, and this has not been sufficiently recognised in our analyses and design methods. Furthermore there seem to be several ways in which this can be important: as an end in itself, or as a property of the mental processing accompanying interactions aimed at something else. These "flow" experiences relate to the deepest absorbtion seen in software users, and are clearly a design aim for both computer games and educational software, even when users would not choose the word "fun".


This paper was inspired by Andrew Monk's decision to create a workshop on "computers and fun", and the questions that implied.

It also owes a debt to discussions on ITFORUM, and particularly to interactions with Joe Beckmann, Lloyd Rieber, and Clark Quinn.

6. References

Boud, D., & Feletti, G. (1991) The Challenge of Problem Based Learning (London: Kogan Page Ltd.)

Csikszentmihalyi,M. & Csikszentmihalyi,I.S. (eds.) (1988) Optimal experience: Psychological studies of flow in consciousness (Cambridge, UK.: Cambridge University Press).

Csikszentmihalyi,M. (1990) Flow: the psychology of optimal experience (New York: Harper & Row)

Dowell,J. & Long,J. (1989) "Towards a conception for an engineering discipline of human factors" Ergonomics vol.32 no.11 pp.1513-1535

Dowell,J. & Long,J. (1998) "A conception of the Cognitive Engineering design problem" Ergonomics vol.41 no.2 pp.126-139

Draper, S.W. (1998) "Practical problems and proposed solutions in designing action-centered documentation" Minimalism beyond the Nurnberg funnel (ed.) J.M.Carroll ch.13 pp.349-374 (MIT Press: Cambridge, Mass.)

Draper S.W. & Oatley K. (1992) "Action Centered Manuals or Minimalist Instruction? Alternative theories for Carroll's minimal manuals" in P.O.Holt & N.Williams (eds.) Computers and Writing: state of the art ch.15 pp.222-243 (Intellect Books: Oxford; and Kluwer Academic Publishers: Norwell, MA).

Hedden,C. (1998a) A guided exploration model of problem-solving discovery learning (Ph.D. Dissertation; University of Washington). Also [WWW document] URL (abstract visited 2 May 1999).

Hedden,C. (1998b) "Re: ITFORUM paper #30 (Jones)" (Email message to ITForum 6 Dec 1998). Also [WWW document] URL

Hutchins, E.L., Hollan, J.D., & Norman D.A. (1986) "Direct manipulation interfaces" in D.A.Norman & S.W.Draper (eds.) ch.5 pp.87-124 User Centered System Design (Erlbaum: London).

Jones,M.G. (1998) "Creating engagement in computer-based learning environments" ITForum (email list: invited paper posted 7 Dec. 1998) and [WWW document] URL:

Langer,E.J. (1997) The power of Mindful learning (Addison-Wesley: New York)

Malone,T.W. (1980) "What makes things fun to learn? A study of intrinsically motviating computer games" Technical Report CIS-7 Xerox PARC: Palo Alto, CA.

Malone,T.W. & Lepper,M.R. (1987) "Making learning fun: a taxonomy of intrinsic motivations for learning" in Snow,R.E. & Farr,J.J. (eds.) Aptitude learning and instruction: III Conative and affective process analysis pp.223-253 (Erlbaum: London).

Marton,F., D.Hounsell & N.Entwistle (1984) (eds.) The experience of learning (Edinburgh: Scottish academic press)

Neal,L. (1990) "Implications of computer games for system design" in Human Computer Interaction: INTERACT '90 (eds.) D. Diaper, D. Gilmore, G. Cockton, B. Shackel (North-Holland: Oxford) pp.93-99

Rieber,L.P. (1996) "Seriously considering play: designing interactive learning environments based on the blending of microworlds, simulations, and games" Educational technology research and development vol.44 no.2 pp.43-58

Rieber, L. P., Smith, L., & Noah, D. (1998) "The value of serious play" Educational Technology vol.38 no.6 pp.29-37 [URL: (visited 13 March 1998)]

Watzlawick, P. (1984) The invented reality: How do we know what we believe we know? Contributions to constructivism (ed.) (W.W.Norton: New York)

Web site logical path: [] [~steve] [fun] [this page]
[Top of this page]