Give programmers detailed specifications

 Introduction

The point of all your efforts to understand tasks & processes at a detailed level, and consult with users on every detail of their interaction with the system, is so we can accurately specify the design to the programmers who will make it happen. We communicate with the programmers using our detailed design document and/or a prototype.

What to specify in the design document or prototype

Structure & navigation: The structure of the site or application should already be set, and tested with users, before programmers start coding.

EVERY user function: By the time we come to communicating the detailed design to programmers, all high level objectives need to have been broken down into detailed descriptions of every function that the user will be able to execute, every interaction and outcome mapped-out in detail.

Visual design: The visual look & feel, complete with colour schemes and branding, already tested with real users, should be included in the design specification.

Issues need resolving during development

Various aspects of the design specification will need clarifying during the development phase of the project, perhaps because the design document or prototype lacks the required detail, or because the technical platform that the site/application will sit on (e.g. a particular portal platform) is not capable of implementing a particular behaviour as specified in the design.

In such a case, every proposed change must be checked with the user. If a prototype has been used, modify it and check the design change with users. If not, use whatever other briefing mechanism has been used in the project.

The value of prototypes: By far the most effective way of communicating with programmers (as well as users and stakeholders) is through the use of a prototype.

Briefing programmers using a visual representation of the product which has already been user-tested is simply more communicative than a wordy document, particularly where there are interactions to explain.

Culture change required: There may be some resistence to the inclusion of a new team member with the role of usability, many programmers considering it an unnecessary or irrelevent role.

Some effort should be made to educate other team members of the value of this new role, and the benefits to the whole team of increased success of the project.