The Agile software development process is increasingly the process of choice for commercial applications (particularly web based and mobile). It encourages very documentation-light working, as specifications and requirements are negotiated on the fly between developers, clients and users. It raises issues as to how design of human interaction with software with its tradition of more considered working, can be integrated.
In comparison, the human-centered design process that I teach, whilst acknowledging the iterative nature of effective design, looks very close to a waterfall methodology – and the constraints of modularised semester based teaching, where each element must be addressed sequentially, reinforces this. Shouldn’t the apparent emphasis on documentation and traceability be abandoned and instead the human-centred designers’ contribution to the development of a user story in a sprint be explored?
To defend my teaching of the ‘standard interaction design process’ I rely on this point: it is teaching. This has a number of implications:
- The way a practical subject is taught should not slavishly mimic how it is practised (and shouldn’t ignore it either). Expert practitioners use heuristics based on multiple previous experiences of dealing with the problem at hand (short-cuts), and carry a store of knowledge and valid assumption. The beginner must build this resource.
- The beginner often finds it difficult to distinguish the fundamental from the superficial, and the general from the specific. These distinctions need to be developed.
- The beginner often arrives with a set of mistaken beliefs and expectations about the practice they are to learn (notably in the case of interaction design, that it is a species of graphic design). These misunderstandings must be cleared away.
With regard to 1: experienced designers of human interaction with software now working in Agile teams will have been trained, or developed their expertise in a more formalised environment. Whilst they may have difficulties adapting to the new regime, they do have a solid understanding of the principles of their specialism, and they will be aware of the problems any short-cuts or compromises may introduce; They have an idealised process model to guide them. To a greater or less extent this is the case for other specialisms in the Agile team. Is teaching Agile development ab initio actually possible (or at any rate desirable)?
Someone submitting themselves to teaching may reasonably expect that they will be offered a formative experience that leads them eventually to an appropriate level of competence in the subject. Once achieved, they then develop their own expertise as they use, adapt, replace and even reject what they have been taught. The standard interaction design process offers a template for that formative experience. Distinct techniques and methods to support its different activities can be introduced in a way that allows the specific to be understood in the general context of a rational process.
However the standard interaction design process is not merely a teaching device. It represents an appropriate model for development of a wide range of software types, e.g., shrink-wrapped software products, safety-critical and legally constrained systems, and embedded software. It is necessary that new designers are able to work in these fields where a more formal documentation driven process is mandated. Learning a formalised process and then adapting to a less constrained one is likely to be less painful than visa versa.