Learners as Users, Users as Learners:  What’s the Difference?

Raven Wallace

January, 1999


Keyword:  Learner-centered Design



Abstract:  A theory is proposed as to why methods of user-centered design result in products which may be inadequate for learning in K-12 classrooms.  Suggestions are offered for methods which take into account the unique characteristics of learners.



Current theories of learning, broadly labeled constructivism, tell us that learning is not about getting content into a student’s head, or imprinting a procedure in a student’s cognitive structure by extensive practice.  Rather, learning is a process of constructing understanding by grappling with problems, seeking solutions, and organizing knowledge for oneself.  The process of learning takes on major significance, because the desired outcome is no longer limited to knowing a set of facts or procedures, but rather encompasses understanding and being able to use a range of content.  Many educators and policy makers argue that computer technology can and should be a major player in this reformed teaching and learning because computers offer unique possibilities for providing individualized interactions with multiple representations of content, and more [1-3].   Students can, at least theoretically, engage with computers in processes which offer the possibility of understanding content and constructing knowledge in ways previously unimaginable.


And yet, much software available for schools fails to live up to the expectations and hopes of educators, reformers, and technologists.  From Web browsers to Math Blaster, software misses the mark of engaging students in throughtful interaction with appropriate content.


Why is this so?  There are, of course, many reasons for these shortcomings, from commercial pressures to rapidly changing technology to school budgets.  But, from the point of view of HCI methods, current design methods may be inadequte for successful design of software for learners [4, 5].  By learners, we mean students who are using software to learn about something other than the software itself.  Our particular interest has been in K-12 learners, and, although some of the ideas presented here may apply more generally to learners of all ages, other aspects of our argument may be unique to young learners in schools settings.


The fundamental problem is easy to state: User-centered design focuses on goals of the user, goals which have to do with getting a task done, or creating something.  This focus misses the most important aspect of software use for learners, the process of using the software.  What a student does during the time she uses a computer becomes the site for and source of constructivist learning.  The focus of the design must be to enable a process through which the learner can confront and grapple with appropriate ideas, content, and procedures.  The process is the thing.


An Expansion of the Problems of User-Centered Design


As conceived by Norman [6, 7], human-computer interaction can be modeled as a process with seven stages which include both physical and mental actions.  The user’s goal is of primary importance, and the problem for designers is to bridge the gaps which exist between the user’s ability to express his goals and intentions through actions and the computers interpretation of those actions - the “gulf of execution”; and the user’s understanding of the system’s response – the “gulf of evaluation.”  User-centered design methods regularly take Norman’s theory as given and suggest strategies for proceeding with actual design – task analysis, iterative design, user involvement and feedback, etc.  These strategies aim to help designers understand user goals and provide user input to decisions about usability.  In these methods, the gulfs of execution and evaluation mark the big leverage points for designers.  All of this is placed in the framework of getting to the end result:  completing a task or creating a product.

To take learners into account, more is needed [4, 8-11]. First, the goals of learners themselves in most cases don’t resemble the goals of users.  For example, software for search and retrieval of information is written with the goal of optimizing returns, getting the best possible results for a user whose goal is to find what he’s looking for.  A student may not have as a goal to find anything in particular, or he may not know enough to know what to look for.  He may have much to learn before he can begin to act like a novice user.  His reasons for searching may be entirely at odds with user goals envisioned by system designers:  he may search because he has to (it’s an assignment), to stay busy-looking during a class, or to get a good grade.  At the same time, the teacher may have students search for information to help them learn about a particular topic, or to teach them the research process, to name two possibilities.  How can these three often divergent sets of goals come together – the goals the software designers impute to users, the actual goals of students, and the goals the teacher has for her students?

Second, a perennial problem in schools is motivation:  students may not want to do what the teacher wants them to do.  Unlike the prototypical user, who, it is assumed, intends to do a task and do it successfully, a student may actually intend not to do any more than she must do to get what she wants from the class (e.g, a passing grade for some, an A for others.)  This isn’t cynicism.  Rather, it is a real and justifiable problem of teaching:  how does a teacher go about keeping students motivated to learn, not just to go through the motions of school?  User-centered design simply does not deal with the affirmative aspects of motivation, with how to capture and retain the user’s interest.  (It does make the assumption that poor usability can cause users motivation to flag, what one might call the negative aspects of motivation, or motivation not to use the software.)

Third, the point of software for learners is for them to learn, and thus change their state of knowledge and understanding.  Yet user-centered design assumes a static target of design, a fixed product or task which does not change over time.  A goal of much design effort is to make it possible for a novice user to effectively use the exact same product an expert would use.  This is not how software for learning should operate: as the student learns, the software should be able to provide ever growing challenges. (This is not to imply here that the software needs to intelligently or automatically provide these challenges, but rather that design take into account a teaching and learning process through which the software can be used at varying stages of student progress.)  The learner must be able to use the software in ever more complex ways as his knowledge and expertise in the domain increase.  Using the example of searching again, a learner new to a given field might benefit from software-provided support for generating keywords, or summaries of documents retrieved or a place to keep notes about what he finds, while a student with knowledge in the domain might shun all those supports and make effective use of his background knowledge, behaving more like the prototypical user.

Finally, design of software for use in schools needs to consider the contexts for and practices of teaching.  In K-12 classrooms, and especially in classrooms which are taking calls for reform seriously, learning is a social activity, intimately connected with teaching.  The image of computer-as-tutor, in a one-on-one dialog with a student doesn’t work in many different ways including its failure to fit with current conceptions of learning as well as the realities of life in classrooms.  Contexts and practices of teaching include grouping students to share limited computer resources; ways in which the teacher can interact with  students working at a computer to help them learn and to assess their learning; ways that the whole class can benefit from the separate actions of individuals or smaller groups of students; and ways that the teacher can manage the disparate activites of small groups of students (or individual students).  User-centered design is undertaken with consideration for only the user-computer dyad, a simplicity not usually realistic or, some would argue, desirable, in a school setting.

How do these issues relate to Norman’ model of User-centered design?  First, user goals seems to be the wrong place to start:  learners have some gaps to bridge before they can even begin to act like users.  These gulfs can really be though of as two major issues:  knowledge and intentions.  The learner lacks knowledge which designers must assume the prototypical user has.  This may include background knowledge of the domain of study, knowledge of strategies for learning in the domain, and knowledge about how to evaluate their own progress.  This “Gulf of Knowledge” is a problem which design for learners – learner-centered design or LCD – needs to address.  Learners also lack the assumed coherent intentions – e.g., accomplishing the goals established for use of the software.  For learners, motivation to work toward an established goal can not be assumed.  This constitutes a “Gulf of Intention” which also should be addressed through LCD methods.  Figure 1 below builds on Norman’s image of the gulfs which designers need to address, to show new gulfs which LCD needs to address.  In this diagram, the line between the physical system and the user is not clearly defined:  in fact, the fuzziness of this line is appropriate since an important job of the designer must be to figure out how and where to draw it, what part of the bridging can be part of the affordances of the physical system and what part left to other aspects of the classroom environment with allowances by the system for these contexts or practices.


Methods of Learner-Centered Design

Briefly, the methods of learner-centered design build on and expand user-centered design [8, 10].  Task analysis is expanded to include three types of analysis: learning analysis which investigates what should be learned through use of the software and what is known about learning those things in the given domain; task analysis of the task(s) as done by a prototypical user; and teaching analysis which investigates contexts and practices of teaching which surround learning with this software.  The big questions are: 

·        What do we want students to learn through the use of this software? 

·        How would an expert engage in the activities or use the knowledge we want students to learn? 

·        How can a teacher teach students to learn these things through use of the software? 

These analyses need to be intertwined and recursive, with decisions about software feeding into the teacher analysis, and that feeding back to design decisions.

 User objects are exanded to include objects for learning and teaching.  Scaffolding, for example, may be included as a learning object and a teaching object.  (For a more detailed discussion of scaffolding, see Jackson, 1998.)

Feedback is obtained in real classroom settings, perhaps in the mode of “design experiments” in which teachers, students, and designers are participants.


Principles and methods of LCD have been used extensively in the hi-ce design group, and many of these principles are evident in projects undertaken at other educational research institutions [12-16].  Commercial success has been elusive for even the very best of the carefully designed, research-based educational software perhaps because of the very ambitious domains in which they have worked.  However, with the remarkable spread of Internet access in schools, possibilities for dissemination and use of software in schools is changing drastically, and it is time for the broader HCI community to recognize the unique problems of designing for K-12 learners. 





1.     Dede, C., Learning with technology. ASCD Yearbook. 1998, Alexandria, VA: ASCD.

2.     Kozma, R.B., Learning with media. Review of Educational Research, 1991. 61(2): p. 179-212.

3.     Perkins, D.N., et al., Software goes to school: Teaching for understanding with new technologies. 1995, New York, NY: Oxford University Press. 288.

4.     Soloway, E., M. Guzdial, and K.E. Hay, Learner-centered design: The challenge for HCI in the 21st century. Interactions, 1994. 1(2): p. 36-48.

5.     Soloway, E., Jackson, S.L., Klein, J., Quintana, C., Reed, J., Spitulnik, J., Stratford, S. J., Studer, S. Jul, S., Eng, J., Scala, N. Learning theory in practice: Case studies of learner-centered design. in CHI96 Human Factors in Computing Systems. 1996. Vancouver, BC: ACM.

6.     Norman, D. and S. Draper, User Centered System Design. 1986, Hillsdale, NJ: Lawrence Erlbaum & Associates.

7.     Norman, D.A., The design  of everyday things. 1986, New York: Doubleday.

8.     Jackson, S.L., J. Krajcik, and E. Soloway. The design of guided learner-adaptable scaffolding in interactive learning environments. in CHI98: Human Factors in Computing Systems. 1998. Los Angeles, CA: ACM.

9.     Soloway, E. and R. Wallace, Does the internet support student inquiry?  Don't ask. Communications of the ACM, 1997. 40(5): p. 11-16.

10.   Wallace, R., et al. ARTEMIS:  Learner-centered design of an information seeking environment for K-12 education. in CHI98:  Human Factors in Computing Systems. 1998. Los Angeles, CA: ACM.

11.   Nicol, A., Interfaces for learning: What do good teachers know that we don't?, in The Art of Human-Computer Interface Design, B. Laurel, Editor. 1990, Addison-Wesley Publishing Co.: Reading, MA. p. 113-122.

12.   Linn, M.C., Key to the information highway. Communications of the ACM, 1996. 39(4): p. 34-35.

13.   Songer, N.B., Exploring learning opportunities in coordinated network-enhanced classrooms:  a case of Kids as Global Scientists. The Journal of Learning Sciences, 1996. 5(4): p. 297-328.

14.   Soloway, E. and A. Prior, The next generation in human-computer interaction. Communications of the ACM, 1996. 39(4): p. 16-18.

15.   Scardamalia, M. and C. Bereiter, Student communities for the advancement of knowledge. Communications of the ACM, 1996. 39(4): p. 36-37.

16.   Edelson, D.C., R.D. Pea, and L.M. Gomez, The collaboratory notebook. Communications of the ACM, 1996. 39(4): p. 32-33.