Communication with Coders

In contrast to the wireframe being overly defined for the clients when discussing overall structure of the site in Project A, we found that compositional elements of pages were not defined in sufficient detail to communicate with the software development team responsible for implementation. The development teams' approach was to identify logical units within each page so that common software classes and routines could be identified early on. This entailed marking up the prototypes with regions regarded as logical units, and numbering them. Clearly this added another level of detail to the wireframe which we had not initially envisioned when designing it. Since the wireframe was developed in HTML using layers it was not technically possible to annotate the prototype itself, so paper copies of the pages were used and marked up. As development progressed, and the prototype was refined due to client requests and an improved understanding of the user requirements, it became increasingly difficult to maintain a link between the regions marked on the paper copies and the evolving prototype.

Given the lack of fidelity in the prototype required by the software coders, use cases were written to specify the user-system interaction in more detail. Use cases are a software development representation that describes the "dialogue" between a user and system in a task context. For example, in the task context of "Write an e-mail", the dialogue could be: (1) The user creates a new message; (2) The system displays an empty message window; (3) The user gets a recipient from the address book; (4) The system checks the validity of the address, and so on. These use cases were specified by use-case writers and then taken by a test team who developed test plans to better support the implementation effort. These additional specifications referred directly to particular parts of the wireframe — for example, the use cases detailed particular user-system interactions, while the test plans relied on both the wireframes and use cases. Maintaining the consistency between these multiple representations became more difficult as more and more people came to rely on the wireframe.

In terms of our dimensions, our prototype did not allow for sufficient detail in its description when the target audience was the software development team. Moreover, the unchanging paper copies became further out of synch with the evolving prototype as development progressed thus imposing an overhead on the communication between the HCI and development teams. Essentially the development team needed a view of the prototype that was at a greater level of detail than our own.

The same problem occurred again in Project B where the prototype was used as a means of communication between the HCI team and the software coders. As in Project A the prototype was not detailed enough to meet the needs of the coders. Therefore we adopted use cases to further detail the requirements on the functionality. Initially HCI was responsible for specifying the use cases. However, at a later stage the system developers took on this responsibility to make sure the use cases were detailed enough to support them in their work. The use cases together with the wire frame were used to drive the development process and to identify issues that needed to be resolved.