Blog Categories

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.

References

1. Denley and Long (2010) Dialectic Approach to Multidisciplinary Practice in Requirements Engineering

2. Dowell (1998) Formulating the Cognitive Design Problem of Air Traffic Management

3. Hill (2010) Diagnosing Co-ordination problems in the Emergency Management Response to Disasters

4. Newman (1994) A Preliminary Analysis of the Products of HCI Research, Using Proforma Abstarcts

5. Salter (2010) Applying the Conception of HCI Engineering to the Design of Economic Systems

6. Stork and Long (1994) A Specific Planning and Design Problem in the Home: Rationale and a Case-study

I have always argued for the strongest possible relations between HCI research and HCI practice. For example: ‘The HCI discipline can be summarised as: the use of HCI knowledge (acquired by research) to support practices (of design and evaluation) seeking solutions to the general problem of HCI (humans interacting with computers to do something, as desired/ to perform tasks effectively, as desired) (1). My own research (along with many others) has acquired such knowledge (in my case) in the form of design models, methods and principles to support practice.

However, I have always been acutely aware of the gap between knowledge acquired by HCI research and its application by designers. Bellotti reported empirical support for such a gap in her study of commercial system interface design projects (2). She concluded that: ‘The study suggests that HCI design and evaluation techniques, although potentially valuable to commercial design, are not applied in practice’. A comparable study of London HCI Centre designers (the commercial arm of the Ergonomics Unit) reached the same conclusion. Later, in 1997, I cited Bellotti’s paper, concluding that: ‘In terms of the capability maturity model (3), HCI fails to support design practices, which are either ‘defined’, ‘repeatable’, ‘managed’ or ‘optimised’.

My view has remained unchanged, in spite of the intervening years. In my 2010 Festschrift, I wrote: ‘….I would like to celebrate the world of HCI. Obviously, students, practitioners and researchers, who identify themselves with HCI and who together make up the HCI community. But also IT professionals, outside the community, who do not identify with HCI; but who actually design so many of the interfaces in use to-day. Most IT interfaces continue to be designed and implemented by such professionals. We forget them at our (professional) peril.’

Further, I expressed the hope that: ‘HCI research improves the effectiveness of the design knowledge, which it acquires to support HCI design practices (a hope shared by festschrift authors – knowledge, which is ‘more assured’ (Carroll), ‘more reliable’ (Dix) and ‘offering a better guarantee’ (Hill)). Anyone who doubts this need should seriously consider:

1. How much interface design is performed by IT professionals, outside the HCI community;

2. How little HCI actual design, as opposed to related studies or evaluation, is carried out by individual HCI practitioners (as consultants) or even by those working as teams in large organisations; and

3. How much design is performed with little or no reference to HCI design knowledge (of any or no conception), other than perhaps evaluation. But how is this much-needed improvement in HCI design knowledge to be achieved? In my view, it can only come about, if HCI research and practice diagnose more design problems and prescribe more design solutions and in so doing evaluate the effectiveness of HCI design knowledge (of whatever kind).’

However, lots of HCI water has passed under the bridge in the last 25 years or so. Also, I am a researcher and not a practising designer. A timely reconsideration of the relations between HCI research and practice – past, present and future, seemed a good idea for the website to address. By sheer good fortune, I was in contact with Victoria Bellotti at this time and she agreed to an e-mail exchange on the topic. Victoria is both a very successful researcher and designer and, of course, set the ball rolling in 1988 with her paper cited earlier. We should be so lucky.

Bellotti, 1988

Carroll, 2010

Dix, 2010

Hill, 2010

Long, 2010

Long and Dowell, 1989

Paulk et al., 1993