Reconstructing Minimalism

from Reconstrucing Minimalism:
Beyond the Nürnberg Funnel

Minimalism: Beyond the Nürnberg Funnel brings to light recent important developments in the minimalist method of instruction. Minimalism is an action- and task-oriented approach based on the belief that students learn more effectively when given realistic tasks. This new collection of essays edited by John M. Carroll is an update to his 1990 book, The Nürnberg Funnel.

edited by John M. Carroll

Seventeen years ago, I was working in a research group of young cognitive psychologists. We were young enough to be astonished by the profound difficulties people routinely experienced in using what appeared to be carefully designed documentation and self-instruction material. These initial observations propelled us down a path of investigation and analysis that we are still pursuing.


Less is more

As the decade of the 1980s began, many people were discovering ease-of-use and ease-of-learning, most of them in fairly unpleasant ways. In the midst of a revolution in technology to support human activity, people were being terrorized by word processors. The user population for computers was increasing and diversifying rapidly, programmers and engineers were being replaced by secretaries and professionals as the "typical" user. But companies did not understand the needs of these new users, and were not prepared technically to support them. The IBM Corporation, where I worked as a research scientist, was enjoying enormous expansion in office products. It was about to transform the industry with its PC. But market success was taken for granted in IBM at that time; what was more salient to technical leaders in the company were the open problems.

In IBM, one approaches uncertainties by commissioning "task forces." I served on a task force created by the Research Division in late 1979. Our job was to survey the leading research and development groups in the world, and to propose a plan for IBM to achieve technical leadership in usability. One of the first projects established within the Research Division under this mandate was directed at characterizing the problems of new users in a way that could provide design direction for user interfaces, training, and documentation. Clayton Lewis, Robert Mack and I undertook this project. Our empirical approach was protocol analysis: we watched learners closely for hours upon hours, periodically asking them what they were thinking, what the things they noticed meant to them, what they wanted to do.

What we found in these protocols - in the thoughts and actions of our test subjects - was not dearth of understanding, failure to notice and interpret; rather we observed incredibly complex attributions, elaborately reasoned abductive inferences, and carefully performed, ritual behaviors. People were not so much being merely stumped by this learning task, as being drawn into a nightmare in which things frequently made a little bit of sense, but generally ended in disaster. This was unpleasant to watch, intriguing to ponder, but what could we do about it?

Our interpretation of our subjects' struggles was that they were actually making rather systematic attempts to think and reason, to engage their prior knowledge and skill, to get something meaningful accomplished. They did not seem to be getting appropriate guidance and feedback from the systems and documentation they were using, even though they were being presented with a huge amount of information through these channels. For example, although they often tried to attempt real tasks, their training materials did not support this. Although they made a great variety and number of errors, their materials did not support error recognition, diagnosis, or recovery, and the systems did not provide general undo functions.

The minimalist design approach we pursued emphasized encouraging and supporting work on realistic tasks from the start and throughout training - learning by doing rather than learning by reading. We wanted to engage the learner, to evoke positive motivation toward meaningful activities. If we could do this, we felt confident it would more than make up for perhaps presenting a smaller volume of information: people able to get started effectively could learn on their own as necessary. We stressed coordinating documentation with system information, and supporting error handling both in the system and in documentation. We insisted, for example, that if people tended to jumble the instructions they read and executed, then instructions should be absolutely modular, they should make sense in any order.

This contrasted with the then-pervasive systems approach which emphasized carefully sequenced, thorough practice on individual steps to support learning and further practice on methods, but ignored learner motivation to rapidly undertake realistic tasks. The systems approach emphasized structural decomposition and completeness of information, but ignored the context of use (e.g., coordination of the system and documentation) and support for error.


Iterative design

In our earliest work on minimalism, we wanted strong and simple principles to drive an initial "ruthless" design analysis and first-pass design (cf. "slash the verbiage"), with subsequent iterative evaluation of both formative and summative sorts. Indeed, I think my understanding and practice of minimalism over the years has been linked strongly to my more general views on design. When I first joined IBM's research division in the late 1970s, John Thomas, Ashok Malhotra and I formed a project to study the software design process. The context for the project was a then-current schism in the basic understanding of design activity. On the one side were a set of naive and prescriptive views of design, originating in the psychology of problem-solving and in the "waterfall" methodologies of software engineering. These views held that design problems could be systematically decomposed into sets of routine puzzles. On the other side, were the somewhat fuzzy and often disturbingly naturalistic views of theorists who had actually seen real design projects!

I think we were fortunate to be working in an industrial laboratory; our colleagues were real software designers. I was still close enough to graduate school to persistently try to see software design as hierarchically organized, simple information processes. But it wasn't working. Our studies showed, for example, that software designers don't work from hierarchical decompositions, but that they interleave top-down and bottom-up development. We found that the design process involves the development of partial and interim solutions that play no concrete role in the ultimate solution. Indeed, we found that the goals of a design project routinely change through the course of the process.

The design practice we observed in the late 1970s was more complex than contemplated by psychology and software engineering, but it was still woefully oversimplified. "User testing" was generally seen as a validation process tacked onto the very end of system development. In those days, the objective of user testing was to identify glitches that could be "papered over" before the system was delivered. Indeed, users played almost no role at all in system design. The requirements gathered early in the system development process, and used to develop the initial goals for a project, came from managers, often with no involvement of the workers who would ultimately be the users of the system.

Our work found a place within the broad shift in thinking about the role of prototyping, usability testing, and user models in the system development process. We ended up helping to articulate a prescriptive design methodology that is now widely taken for granted: iterative development. Today, one just assumes that usable and useful systems cannot be specified first-time final, that the real needs and practices of users must be understood as design requirements, and that the extent to which the designed system meets these needs must be directly and continuously evaluated throughout the development process via mock-ups and prototypes.

What is the connection to minimalism? If one imagines that design is a process of systematic decomposition, specification, and implementation, one will seek hierarchically detailed models and structured methods. And this is precisely the process assumed in the systems approach. If, however, one understands design as a process of iterative development and goal discovery, one will seek a strong and concrete starting point, a coherent design vision that may (perhaps must) entrain design dilemmas and trade-offs. That's the way to get the most out of a process of iterative redesign.


The human need for sensemaking

The ideas that guide us in technical communication are necessarily bound to the technology contexts within which they develop. The systems and documentation materials that served people so poorly in our early studies do belong to a bygone era. Indeed, in 1980 - as we can now look back and appreciate - better models for information design were already in hand, they were merely waiting to be applied, and innovations in systems and user interface software were already implemented in commercial products. Maybe the time for minimalist information slashers was to pass as quickly as it came.

In 1983, Sandra Mazur-Rimetz and I made a detailed study of professionals learning to use the Apple Lisa. The Lisa incorporated many of the user interface ideas pioneered in the Xerox Star system, and was the direct precursor of the Apple Macintosh. Our study was circulated internally in IBM for three years before being cleared for outside publication, so we had plenty of time to ponder our results. For me, the most important outcome was a strong encouragement to generalize the descriptions and interpretations we had been making of the problems and experiences of secretaries learning to use IBM systems like Displaywriter. Although the Lisa incorporated genuine advances in user interface presentation and although our "professional" users were far more knowledgeable about computers than were the secretaries we had studied earlier, the basic problematic patterns of user and learner interactions remained.

In 1985, Mary Beth Rosson and I wrote a paper entitled "Paradox of the Active User." We argued that although people need to learn in order to engage effectively in activities, their compelling orientation to meaningful activity continually undermines the motivation to spend time and effort "just" learning. We showed that this mechanism could explain a variety of the new user problems that had originally innervated our minimalist design work, but that it also explained phenomena associated with more experienced users, for example, the tendency for skill to asymptote at relative mediocrity.

These two projects transformed the minimalist enterprise for me. They led me to see our inventory of learner problems, not as reflecting merely a set of design blunders (which of course they do), but as also exemplifying types of problems that are necessarily entrained when knowledgeable people try to acquire new cognitive skills through self-instruction: People want to learn by doing, but this inclines them to jump around opportunistically in learning sequences. They want to reason things out and construct their own understandings, but they are not always planful and they often draw incorrect inferences. They try to engage and extend their prior knowledge and skill, but this can lead to interference or over generalization. They try to learn through error diagnosis and recovery, but errors can be subtle, can tangle, and can become intractable obstacles to comprehension and to motivation.

I came to understand that the very dispositions that make people good sensemakers, are also causes for characteristic learner problems. I came to see our project more as managing design dilemmas that can never merely be "solved" rather than as correcting design blunders tout court. In re-reading my own expressions of minimalism, I do not now find as sharp a shift as I then felt in my own thinking about what we were trying to create: prior to 1984, I was truly captured by the aesthetic of presenting less information, of responding to learner problems by cutting rather than adding. After 1984, I was more centrally concerned with better-supporting self-initiated sensemaking. Both aspects were always there.


Managing design

As my understanding of educational philosophy and technology grew, and as minimalism took on for me a more extensive, more articulate, and more general meaning, I was also coming to be increasingly dissatisfied with mere "iterative" development as an attitude toward understanding and managing design. I began to recognize that a strong starting point and a continuing responsiveness to evaluation were not enough: What was the guarantee that iterative design would not merely produce local optimizations and thrashing; what was the guarantee of global convergence or coherence in the final design result? Replacing the unrealizable ideal of systematic decomposition with a chaos of local perturbations, unguided by any overall design concept or integration, seemed to me to be an advance from the frying pan to the fire.

I became interested in techniques for managing the process of iterative development. Our first notion was that a set of written "usability specifications" could be created early in the system development process and then carried along through the process as a "living" goal statement. Usability specifications were to be measurable claims about the use of the system being developed. They could be updated if and when necessary, but they would be maintained as a precise description of the usability commitments and performance of the system - analogous to functional specifications. This approach is fundamentally different from merely emphasizing testing and design refinement.

Our initial conception of usability specifications strongly emphasized user performance (e.g., "secretaries will be able to type, edit, format, and print a 1-page memo after 2 hours of instruction"). Over the next several years, we continued to develop concrete approaches for managing iterative design. These evolved in the direction of becoming qualitative hypotheses about the inferences users might make as they engage in learning activities, what we (eventually) called "psychological design rationale." We suggested that the usability tradeoffs implicit in a design should be made explicit and managed as part of the system documentation. For example, we described the scenario in which a person learns to type and print using training wheels as incorporating the following tradeoff: "immediate feedback on blocked device state instigates evaluation while relevant intentions, plans, and actions are still active in memory, but could also encourage nonplanful action." A thorough set of such tradeoffs provides guidance in planning and evaluating iterative design refinements.


Scaling up: The "simple domain" challenge

In 1990 I published a book I called The Nürnberg Funnel, consolidating the early developments of minimalism under the image of the legendary funnel of Nürnberg - literally a funnel through which one was to pour knowledge into the head of the unfortunate learner. Minimalist design offers a genuine alternative to the ill-considered search for a Nürnberg Funnel, but with this somewhat coarse issue settled, I wished to move on.

I was attracted to three possible continuations of the project. The first of these was longer-term outcomes: We had demonstrated transfer effects of initial training with minimalist manuals and interfaces, but these were very limited investigations, and we had not considered how to design minimalist reference materials. The second area I was attracted to was better specifying the underlying psychological dynamics of using minimalist materials. Our analysis had followed the social cognitivism of Dewey, Piaget, and Bruner; we had eschewed information processing models (basically because they tend to specify behavior and experience at uselessly fine grains of detail from the standpoint of practical design). Much remained to be done in better specifying particular elements of minimalist designs: inference, examples, error recovery activity.

The third area that specially interested me was the question of whether minimalism would scale up to complex domains, whether minimalist materials and techniques could support learning highly technical concepts and skills. There is a fundamental difficulty with the very statement of this challenge, namely, that the "complexity" scale alluded to in fact does not exist. Word-processing is less complex than rocket science but more complex than tic-tac-toe: is it a simple or a complex domain? These examples suggest a few guides: complex tasks may have many subtasks or options, many steps per subtask, and many conditions or dependencies on subtasks and options. In my work environment at IBM, the general issue was finessed: there was a broad, tacit understanding there that routine office tasks are simple, and that programming and software design tasks are complex.

In the spring of 1988, there was a ground swell of interest in Smalltalk and object-oriented software in my research area. We had been using and exploring Smalltalk for several years already, but just at that time it seemed to click more widely in the work of a number of my colleagues. This presented an opportunity to me: I was finishing the first draft of The Nurnberg Funnel, the rest of what I still had to do would be edits and refinement. The most obvious way that I could contribute to the ground swell, and allow it to carry me along as well, was to tackle the problem of helping experienced procedural programmers - something IBM had lots of - attain a practical understanding of Smalltalk and object-oriented design. In the next six years, we created and studied a variety of programming environments to support learning and programming. We found that while the main thrusts of minimalism still provided useful guidance, the specifics did require some reworking.

A key principle of minimalism is that people need to engage in real tasks. However, the real tasks of complex domains can be overwhelming for learners and unmanageable for instructional designers. In our work on Smalltalk, we developed a set of realistic projects, analysis, enhancement and debugging activities directed at intrinsically interesting software systems (many of them interactive games). For example, we gave learners a blackjack game and suggested they try to make a specific enhancement to the user interface; we created a gomuko game that occasionally stole moves, and invited learners to discover how it cheated and to correct it. These are not the real tasks of professional programmers, but they include the elements of real tasks.

Minimalism assumes that people engaged by a task will creatively reason and improvise, that they will make sense. Complex domains often encompass immense content, myriad entities, relationships, and rules. For example, Smalltalk includes thousands of software building blocks in its classes and methods. Of course, it is possible (necessary really) to practice Smalltalk programming without knowing or using all of these. The point is that there is an order of magnitude more to learn about Smalltalk than there is about even the most function-laden word processor. We decided not to try to provide instruction for a general "core" of domain content. Instead, we tried to convey and support meta-skills of the domain that could help learners make sense on their own. For example, we tried to convey the utility of causal analysis of code, and to encourage reflection and self-critique in programmers.

Minimalism emphasizes getting learners started quickly. Because the tasks of complex domains tend to incorporate many subtasks, and many steps per subtask, "getting started fast" becomes more a matter of sustaining interest and activity than of quickly dispatching a task. We had to give up our early commitment to absolute modularity, adapting the concept of scaffolding to design chunks of intrinsically motivating, task-oriented activity that were as self-contained as possible, but that cumulated within a discovery-based curriculum. Structuring and managing the presentation of such dynamic projects is difficult using only paper materials; we found tool-supported exploration particularly critical.

Minimalism supports error handling: recognition, diagnosis and recovery. However, it becomes intractable to enumerate all possible errors and their interactions in a complex space. We found it more useful to provide a higher level of support, for example, critiquing strategies instead of individual actions. When we could not be certain about the exact nature of an error, we made suggestions, explicitly warning the learner that the advice was our best guess, but that it could be wrong.


Design rationale

Design iteration was always the process touchstone for minimalism. We encouraged risk-taking in design analysis and initial design, assuming that the best guidance ultimately would emerge from observing real people trying to learn and use prototypes. Complex domains challenge this orientation: when too many dimensions are involved, when too many aspects of a design situation can change, attributions in formative evaluation become indeterminate. The shift in our technical work toward the more complex domain of programming and software design had more strongly encouraged our interests in psychological design rationale. Building explicit theories about how designs are expected to impact situations of use, as illustrated earlier for training wheels interfaces, constrains and focuses the interpretation of formative evaluation data. This is the same hypothetico-deductive logic as in the scientific method.

In the early 1990s, we developed a framework in which the design rationale for particular artifacts could be abstracted to design archetypes or models. For example, we developed a minimalist tutorial and tool ensemble for Smalltalk (MiTTS) and showed how its psychological design rationale could be seen as a specialization of the rationale for the minimalist model. The five tradeoffs below summarize a psychological design rationale "view" of minimalism.

• working on a realistic task provides the learner with an appropriate framework for integrating and applying learning experiences, but realistic tasks may be too difficult and there may be too many kinds of task settings to support.
  
  
• working on a familiar task orients and motivates learners by engaging prior knowledge, but may encourage task-specific learning and engage inappropriate prior knowledge.
  
  
• incorporating planning and acting throughout the learning experience helps orient the learner to applying knowledge and supports skill transfer, but increases task complexity.
  
  
• retrieval, elaboration, and inference-making engage and sustain learner attention and make skills more robust and accessible, but learners might not have access to enough information to reason successfully and may be anxious about bearing such responsibilities.
  
  
• diagnosing and recovering from errors focuses and motivates learners and helps sharpen a concept of correct performance, but errors can be frustrating and disrupt task goals.

One tradeoff in the MiTTS design was a specialization of the second proposition: exploring the execution stack in the Smalltalk environment orients and motivates learners by engaging their prior knowledge of call stacks, but inappropriate procedural programming knowledge may also be engaged. Another MiTTS tradeoff specialized the fourth proposition: specifying the function name but not the message name in instructional projects forces learners to infer or retrieve the connections between goals and methods, but they might not have access to enough information to reason successfully and may become anxious about bearing such responsibilities. We argued that building design rationales for models or archetypes could make design work scientifically cumulative by allowing formative evaluation results to be adduced not merely to the particular artifact being evaluated, but to the model (or models) instantiated by that artifact.

Reflections on the future

Much of the future is just the continuation of themes from the past: I am pleased that the minimalist results and design interpretations of the mid-1980s have proven sound and replicable. A growing number of colleagues around the world have been able to apply, refine, and extend both the practice of minimalism and our understanding of why and how it works. Many questions remain open; many challenges remain ahead. I believe that there cannot be an ending to the project of reconstructing minimalism, because I believe there cannot be an ending to the project of learning how to design information. We do better, but we can do better still.

My own current research interests have focused largely on learning in the context of networked community information systems. As in the object-oriented programming work, this has been a minimalist revelation to me. The vision of an "information highway" affording universal access to vast libraries of digital information is bold and exciting, but it is incomplete. People want to share, discuss, and create information, not just retrieve it. For example, our on-going work augments the community information available through the Blacksburg Electronic Village network with a community "historybase" to which residents can contribute their own stories, reflections, and perspectives, as well as their comments on the contributions of their neighbors. Our most ambitious current project is directed at a collaborative environment for middle and high school science students to work together on simulated experiments.

The balance of this book presents a sample of the most important current developments of minimalism. The 14 chapters summarize and update the statement of what minimalism is, and identify typical misconceptions about minimalism, to both clarify what was originally intended, and to better focus analysis and investigation of open questions. They report on efforts to teach information developers to employ minimalism. They illustrate how minimalist principles can be incorporated throughout the system development life cycle through several case studies. They describe various minimalist techniques. They extend minimalism to address individual differences in learning, managerial acceptance, and a broader conception of task orientation that incorporates social, cultural, organizational and technological dimensions of the user's work. The two final chapters describe the development of a research agenda for the future of minimalism. There is a lot to do to achieve more with less.

My view of minimalist design continues to evolve, driven as always by the particular domains and materials with which I am working, and in the case of this project, by the insights and activities of an excellent group of colleagues. Our current projects are all vehicles for pursuing a Deweyan vision of design as participatory inquiry, and of inquiry as necessarily involving design. No doubt these most recent directions will both develop and, in their turn, be reconstructed. At times, these latest endeavors feel a long way off from making tiny manuals; at times, they seem like the inevitable consequence.

Adapted by John M. Carroll from his book Minimalism: Beyond the Nürnberg Funnel and reprinted by permission of the publisher (MIT Press, 1998). John M. Carroll is professor of computer science and psychology, and head of the Department of Computer Science at Virginia Tech. Carroll@cs.vt.edu


Educom Review Table of Contents