Search

This article discusses the epistemology of design as a process, arguing specifically that sketching and drawing are essential modes of thinking and reasoning. It demonstrates that the commonly accepted notion of a spontaneous and intuitive vision in the mind's eye—encapsulated in the cliché of the napkin sketch—obscures the exploratory inferences that are made while scribbling with a pencil on a sheet of paper. The draughtsperson, along with their work tools (such as the 6B), modes of notation, specific techniques, and epistemic strategies as well as the resulting design artefacts form milieus of reflection that facilitate complex processes of exploration. Case studies, including the genesis of the Mini by Alec Issigonis, samples of work by Alvar Aalto, and a reinterpretation of student sketches from a classical design study by Gabriela Goldschmidt, serve to illustrate how drawing inferences with pencil and paper occurs. [ABSTRACT FROM AUTHOR]

Scenarios have gained acceptance in both research and practice as a way of grounding software-engineering projects in the users’ work. However, the research on scenario-based design (SBD) includes very few studies of how scenarios are actually used by practising software engineers in real-world projects. Such studies are needed to evaluate current SBD approaches and advance our general understanding of what scenarios contribute to design. This longitudinal field study analyses the use of scenarios during the conceptual design of a large information system. The role of the scenarios is compared and contrasted with that of three other design artefacts: the requirements specification, the business model, and the user interface prototype. The distinguishing features of the scenarios were that they were task based and descriptive. By being task based the scenarios strung individual events and activities together in purposeful sequences and, thereby, provided an intermediate level of description that was both an instantiation of overall work objectives and a fairly persistent context for the gradual elaboration of subtasks. By being descriptive the scenarios preserved a real-world feel of the contents, flow, and dynamics of the users’ work. The scenarios made the users’ work recognizable to the software engineers as a complex but organized human activity. This way the scenarios attained a unifying role as mediator among both the design artefacts and the software engineers, whilst they were not used for communication with users. The scenarios were, however, discontinued before the completion of the conceptual design because their creation and management was dependent on a few software engineers who were also the driving forces of several other project activities. Finally, the software engineers valued the concreteness and coherence of the scenarios although that entailed a risk of missing some effective reconceptions of the users’ work. [Copyright &y& Elsevier]