Usability Data Reports

The following kinds of data are being collected in BASELINE:

• Types of electronic information applications, user validation requirements and constraints in the Information Engineering domain
• Objectives of user validation, critical success factors, validation criteria
• Types of technology and end-user groups involved in validation, varieties of tasks supported by the electronic information applications, and usage contexts
• Types of methods used for user validation
• Results of user validation activities, to be used as reference values in future validation projects
• Amount of time and effort spent doing user validation as well as the benefits of user validation.

Clearly, important information required to complete the satisfaction of the so-called 'ten commandments' of the Telematics Applications Programme.  The validity of reference values collected by BASELINE depends on the help of everyone involved in usability engineering in the Information Engineering domain. Aware of the fact that 'nothing is free' BASELINE offers usability engineering advice and support in exchange for information about how projects are handling the user validation issues:  this is communicated through the Usability Validation Assistant, the UVA form.

Reports to date are available through the BASELINE File Archives page, or you can directly transfer .RTF documents by ftp:

• BASELINE Usability Data Report (1997)
• BASELINE Usability Data Report (2nd Ed., 1998)

From the experiences of projects which started several years ago, we find it is imperative to stress the value of starting the planning for UVA activities early in the lifecycle of the project.  In the BASELINE survey reported at our last annual workshop, several issues emerged very clearly.  One was that projects which saw  user validation activities as an integral part of their design practice considered that they were able to use the data arising from validation activities to locate design deficiencies and problems users may have with the product. However, there were two problems seen in followup:

• Lack of time in project to do anything positive about the results of user validation;
• Difficulty in relating general to specific validation goals.

A possible cause for this may be that projects did not adequately address the elicitation of quality factors from initial requirements analysis which is something the User Valiation Assistant form attempts to establish as good practice. We anticipate that projects which begin now will be able to take advantage of the lessons learnt from the earlier experiences.

Return to BASELINE Homepage
Go to top of this page