Intermediate Product Workflow

The relationship between the main intermediate products generated during the design process are shown simplified and idealised in the diagram below.

A diagram showing the flow of information and influence between the intermediate products of the design process.

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).

Concept Document

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

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.

Personae

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.

Task Scenarios

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.

Usability Requirements

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.

Naive Wireframe

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.

Wireframes

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.

Lo-fi Prototype

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.

Evaluation Report

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s