User Requirements and Design problems – Same or Different?

There is general agreement that the requirements phase is the foundation upon which the rest of the system development life-cycle is built. Requirements can be divided into different categories – functional and non-functional; also vital and desirable. More specific types of requirements may also be identified, including organisational; user interaction; and interface (1). Of concern here are User Requirements, because although part of the initial phase of the system development cycle, they do not appear to include, explicitly at least, the concept of design problem as such (although they do not exclude it explicitly either).

The omission is important because elsewhere much research claims to be addressing design problems, although it does not appear to include, explicitly at least, the concept of user requirement as such (although it does not exclude it explicitly either). For example, Hill (3) is clear, that her models and method are intended to: ’Support diagnosis of specific design problems and reasoning about potential design solutions’. Stork and Long (6) specifically include design problem in the title of their paper – A Specific Planning and Design Problem in the Home. Likewise, Dowell (2) – Formulating the Cognitive Design Problem of Air Traffic Management. The diagnosis of design problems and the reasoning about potential design solutions are performed by HCI researchers, as part of their attempts to acquire and validate new design knowledge. The question then arises as to what is the relation between user requirements and design problems?

One possible relation is that user requirements and design problems are one and the same thing. That is, there is no difference between them. Although it is not totally clear, Newman (4) might be understood as taking this view: ’Recognising the need for an artifice, and thus identifying a problem in computer systems design whose solution will meet this need (the initial stage of the engineering design process)’. This view, however, is rejected here. Following the HCI Discipline and HCI Design Problem conceptions, in the manner of Hill’s research, a design problem occurs, when actual performance (for example, expressed, following Hill, as Task Quality, User Costs and Computer Costs does not equal (is usually less than) desired performance, expressed in the same way. Alternative, but equally well specified, expressions of performance, might be used here. In contrast, user requirements have no such expression or constraints, even allowing user requirements to conflict or to be obviously unrealisable.

This difference indicates that user requirements and design problems are not one and the same concept. Rather, it suggests that design problems can be expressed as (potential) user requirements, but not vice versa. Salter (5) appears to agree with this asymmetric relationship, although his terms differ. The Specific Requirements Specification (‘design problem’) is an abstraction over the Client Requirements (‘user requirements’). The Specific Artifact Specification (‘design solution’) is an abstraction over the Artifact. The Client Requirements/Artifact relationship is derived and verified empirically. The Specific Requirements Specification/Specific Artifact Specification is derived and verified formally. Salter’s conception is consistent with those proposed for the design research exemplars, which accompany each framework. Note that the Innovation, Art, Applied and Science frameworks have their own ‘problem’, which may or not be expressed as a design problem, in the manner of Craft and Engineering.

Whatever the terms used, however, the general point for HCI research, whatever the approach and whatever the framework, is that differences between User Requirements and Design Problems need to be both explicit and clear.