The relationship between the main intermediate products generated during the design process are shown simplified and idealised in the diagram below.
Where an intermediate product is generated by a relatively mechanical procedure from a precursor document, the flow is shown with a solid blue line. A dashed pink line shows the flow of less precisely defined (but no less important) influence. I.e. information discovered or created during the development of one product that is used in the creation of another.
Many other flows of influence could have been drawn, e.g. from the evaluation report to any of the preceding products, but as this would have made the drawing difficult to interpret only the main influence flows are shown. A brief explanation of each document follows (in diagram top to bottom order).
This may be a document named explicitly as such, or other project kick-off or initiation documentation. It is what exists before any interaction analysis or design had been undertaken. It describes the aims and objectives of the proposed development together with any analysis and specification already developed. In scale it can range from the proverbial back of an envelope to a multi-volume document.
Like all of the other documentation, it may be revised at any stage of development as more is discovered about any aspect of the project. This may be done informally, or versioning may be controlled.
User Profiles contain details of the user population. They provide the repository of empirical evidence about the users characteristics discovered at the beginning and during the project. There may be input from any marketing analysis, job descriptions, demographic data or other sources.
These are descriptions of example users developed out of the User Profiles. Whilst a User Profile is rather dry listings of characteristics, the Persona conveys this information as a brief pen-portrait of a believable person. In particular their expected attitudes towards and expectations of the project are described.
A Persona is often presented as a ‘wanted poster’, with a photograph of an individual chosen to represent a user group, accompanied by a brief textual description. The intention is that these should be displayed in the design studio as a constant reminder of the users.
Scenarios are essentially stories about the eventual product in use. They can be written at different levels of detail. For interaction design purposes a detailed record of each step in the task involving the software and also ancillary systems or procedures are required. They have much in common with software engineering use-cases, with the significant difference that internal software processes are not described.
Abstract Task Model
Where the software to be designed supports more than a very small number of scenarios, recording these exhaustively requires significant effort, and may be practically impossible. This technique allows all recorded scenarios and, in principle all unrecorded scenarios, to be combined and represented succinctly in diagrammatic form.
User Conceptual Model
This document records the user’s beliefs about the data the software will contain and the actions that can be carried out on it. The software engineering paradigm of object orientation can be used to express this through the UML static-relationship diagram notation. There is a relatively mechanistic procedure for deriving this from Task Scenarios.
As analysis progresses, significant usability issues that the software design must address become clearer. This document attempts to capture these requirements formally so that their achievement can eventually be demonstrated during a summative evaluation of the software. There is a standard that specifies development of this document.
There are legal requirements that must be met in commercial interaction design. These come under the headings of accessibility, data protection and health and safety. In addition the task domain may impose regulatory requirements. These legal obligations should be acknowledged by their inclusion in the usability requirements documentation.
Style Guide and Rationale
This may be an informal document, perhaps a design notebook, or it may be a number of substantial documents. Major companies often mandate use of a company style guide. The implementation platform may have a style guide describing the available GUI components and their appropriate use. The application domain may have standards for nomenclature and other detail that must be complied with. General interaction design guidelines and application domain guidance may be available. It is the formal point at which current professional good-practice is input.
It is good practice to keep a rationale of design decisions made, for consultation during subsequent maintenance of the software.
The User Conceptual Model contains detail of all the applications input and output data. The Naive Wireframe simply consists of a single ‘screen’ containing this information.
The Naive Wireframe may often be, in principle, an ‘ideal’ design allowing rapid and unconstrained manipulation of the interface. However there may be ‘screen real-estate’ restrictions that prevent this, and usability requirements may demand separation into a number of ‘screens’. A succession of incrementally developed Wireframes are created as the design is evolved.
Whilst much can be learned by the designers running scenarios against wireframes, for presentation to representative users a more finished version of the design is required. This can still be on paper, or a range of tools can be used to create non or limited functionality prototypes.
Formative evaluation occurs throughout the design phase, the results being documented in informal notes and possibly videos of user trials. For project sign-off a formal summative evaluation may be required, and this may be documented in a style specified in a standard.