Last 3 Donors
Support us
Funding progress for 2010:
Task-artifact cycle
The task-artifact cycle (artifact can also be spelled artefact) captures the idea that tasks and artifacts coevolve (Carroll et al. 1991). The cyclical relationship between the two can be described as follows: A given task sets requirements for the design of an artifacts to help an individual perform the task. The resulting artifact, in turn, creates new or uexpected possibilities or pose new constraints on the performance of the task. These possiblities and/or constraints often suggest a revision of the original task for which the artefact was made. The new task sets new requirements for the redesign of the artifact and so on and so on (de Lëon 1999). The task-artifact cycle is in other words an iterative process of continuous, mutually dependent development between task and artifact, a process that will never reach an optimum state.
Figure 1: The task-artifact cycle.
In software terms, it means an endless versioning of software, or a branching of specific sub-programs (e.g. the web components of Adobe Photoshop became ImageReady). This happens because requirements never stabilize and because the act of introducing the software into the work process changes the nature of the work. Also, software is always "appropriated" and will consequently never be used as intended by the designer.
Further perspectives of the task-artifact cycle
Not only does the artifact itself, as suggested by the task-artifact cycle, change the task it was designed to address, but it also has to adapt to other changes in the context of use. Human organisations are continually evolving in the face of changing circumstances and wherever humans are involved, there is a constant negotiation and re-negogation of meaning, work processes, identities, etc. This poses a problem to information systems as computers and software can only respond to pre-defined situations or problems in a finite problem space (Harris and Henderson 1999). Information systems therefore have an inherent disadvantage when trying to keep up with the constant change of the unpredictable humans. Pre-defined, rule-based behaviour is not sufficient, and therefore it is only natural that people continually find their artifacts insufficient for their evolving work practices.
The canonical reference for the term task-artifact cycle is Carroll et al. 1991, but the idea that the term describes was by no means 'discovered' by these researchers.
What do YOU think?
Give us your opinion! Do you have any comments/additions
that you would like other visitors to see?
You say:
Mar 21st, 2010
References (bibliography)
Carroll, John M., Kellogg, Wendy A. and Rosson, Mary Beth (1991): The Task-Artifact Cycle. In: Carroll, John M. "Designing Interaction: Psychology at the Human-Computer Interface". Cambridge University Press
de Léon, David (0000): Building Thought into Things. In: Proceedings of the 3rd European Conference on Cognitive Science 0000. pp. 37-47.
Harris, Jed and Henderson, Austin (1999): A Better Mythology for System Design. In: Altom, Mark W. and Williams, Marian G. (eds.) Proceedings of the ACM CHI 99 Human Factors in Computing Systems Conference May 15-20, 1999, Pittsburgh, Pennsylvania. pp. 88-95.
Changes to this page
Get Notified!
Get notified when new entries are added to the encyclopedia! Want to know more?“ Software design is the act of determining the user's experience with a piece of software. It has nothing to do with how the code works inside, or how big or small the code is. The designer's task is to specify completely and unambiguously the user's whole experience. ”
-- David Liddle, From Bringing Design to Software, edited by Terry Winograd, 1996
”
- Share this quote on...
- Get more quotes
Eva Hornecker on Tangible Interaction
Eva Hornecker explains the evolving concept of Tangible Interaction.
Read Eva's insightful entry here..
Open Content