Interaction Design Patterns: Twelve Theses

This position paper was written for the CHI2000 Patterns Workshop, The Hague, 2–3 April, 2000. It is a revised and extended version of a paper for a patterns workshop of the British HCI Group in March 2000. It offers twelve statements outlining my position about patterns in human-computer interaction (HCI). The first, under “Roots”, suggest how HCI, unlike software engineering, can adapt the original patterns idea from architecture. The second set, “Adaptation”, shows how this concept can be expanded to cope with the dynamics and requirements of user interfaces. The “Users” section explains how HCI patterns lead to participatory design. The closing claims introduce some current work on using patterns in software engineering, HCI, and the application domain to enhance communication in interdisciplinary design teams, and outline how those pattern languages fit into the usability engineering lifecycle. ROOTS Claim 1 Architecture is closer to HCI than to software engineering. The original intention of patterns as introduced by architect Christopher Alexander [1, 3] was to capture the essence of successful solutions to recurring design problems in urban architecture. According to Alexander, “a building or a town is given its character, essentially, by those events which keep on happening there most often” [1, p. 66], and the social patterns of activity in an environment determine the geometrical and structural patterns of that environment. Consequently, Alexander’s patterns of urban architecture describe aspects of the physical environment in which people live and work. The architect is the “designer”, and the inhabitants are the “users” of these environments. The artefact that the architect designs is something that its inhabitants directly interact with and live in. The task of HCI design is very similar to this: User interface designers shape a virtual environment in which the user works, or, in the case of 3-D virtual environments, may even live. As we know, users generally identify a software system with what its user interface shows them, without caring about its inner works. The artefact that the user interface designer creates is something that its users directly interact with or even live in.