The Agile Development Framework we’re following for the development of the eLivingCampus is very much user focussed. We’ve just spent a few days developing dialogue diagrams that explore possible flows of interaction. The basis for this process is an analysis of each task (person interacting with a functional requirement = a task).
I think that the interaction design is the most crucial part of the development process. Inside that, the development of the dialogue diagrams is the most important modeling process. If I had to chose only one tool in development, I’d be hard pressed to decide between dialogue diagrams and entity relationship models.
We prefer dialogue diagrams that are organic, showing development of thought rather than strict sequences of neatly drawn boxes. Our interpretation of dialogue (and indeed its purposeful spelling) is that of interaction – we aim to represent the flow of interaction the user has as if it were a conversation rather than a focus on what the computer is doing (dialogs). We combine the dialogue and sequence diagrams into a single tool, drawing first the straight though lines, then the “wiggly paths”. These wiggly paths represent things going wrong; all the possible variations on the theme; the notion that the user is at best approximating their way towards an often muddly goal; and added value – what can we do to make their experience better?
We do some dialogue diagrams on the whiteboard (I do the drawing but the outcome is very much the result of the class working together). Groups then develop several diagrams for their tasks, testing them against the tasks. This is an iterative process with much opportunity for role playing, metaphor stories and much iteration between groups pointing out dead ends, circles etc in each others’ processes. The dialogue diagrams are also closely linked to the developing data models on the basis of “no magic” – all the information has to come from somewhere and go somewhere.
Next, pulling the interactions together in wireframe interfaces.