Design Space Analysis (DSA) is aimed at helping software designers reason about design (individually and in groups) and to produce a representation which can help others understand why the resulting design is the way it is. Our work focuses primarily on HCI design, which is much more informal, more open-ended and more poorly understood than some other domains. Reasoning is not always clear and developing the `knowledge base' by cumulating design rationale promises to be a powerful way to compile contextualised design knowledge. The project has been in existence since 1988, and much of the work has been done under the auspices of the European Esprit funded AMODEUS project (Esprit BRA 7040).
The project has three main scientific objectives: to develop a suitable representation for a design space as the output of design; to determine processes which can be used for the practical application of the representation, and to develop ways of re-using components of the design space to support further design and re-design. These have been addressed by a combination of approaches including theoretical, laboratory based and practical application.
A key characteristic of the approach is that it focuses on producing a design space rather than a single artifact. This contrasts with the traditional conception of design which assumes that the end product is simply a specification or artifact. The final artifact, although embodying the designer's decisions, does not preserve any of the thinking and reasoning which went into its creation. This representation of a design space provides a succinct rationale for the final design by placing it in a broader context which highlights how it might be different and why it is the way it is. Such a representation can support communication between people with different backgrounds and goals, for example between members of a design team working on an initial design, between the original designers and designers of a later generation system who want to re-use parts of the original design, and even between the designers and users of a computer system. The ultimate goal is to support design activities right across the lifecycle. The focus on work to date has primarily been in the earlier stages of design to support the structuring of and reasoning with design information. Within AMODEUS, one of the roles of DSA has been to integrate the analyses of the various modelling approaches.
We use a semi-formal notation (called QOC, for Questions, Options & Criteria) to represent the design space around an artifact being produced. This design space is an explicit representation of alternative design options, and the reasons for choosing among those options. The figure overleaf shows a design space using the QOC notation. Questions highlight key issues in the design space. Options can be thought of as `answers' to Questions. Criteria are the reasons that argue for or against possible Options. We represent relationships between Options and Criteria as relatively positive (solid line between Option and Criterion) or negative (dotted line) -- i.e. arguing for or against the Option. Options may spawn off consequent Questions which allow more detailed aspects of the design to be addressed.
The research activities which we have carried out to pursue the development of this work include:
The preservation of rationale for why decisions were taken is a key to continuity within an organisation and is often seen to be central in improving organisational learning. In particular, product design in large organisations typically progresses by building on previous designs. In this context it would appear that there is enormous potential for leveraging from records of the design rationale. In practice this is seldom if ever done satisfactorily. Most organisations rely solely on continuity across people to pass on relevant parts of the organisational history. However, this is subject to people leaving the organisation, being transferred to other roles, or simply forgetting. On the other hand, attempts to preserve records typically fail either because the overheads are too great for producing the records or for retrieving information from them. For example, some groups have tried to maintain a video library of key meetings during design projects to minimise overheads in recording information, but this fails because it is impossible to find information being looked for in a reasonable time and because much of the real work in design doesn't happen in meetings anyway. On the other hand, producing detailed documentation with good indexing is very time consuming, and even where it is done it is generally weak in preserving rationale, often focusing more on describing decisions.
The Design Space Analysis work has been developed by bearing in mind that there are many different settings and purposes to design, and cost benefit payoff in putting in effort to record rationale will vary from setting to setting. So understanding what the rationale is to be used for and who will make use of it is critical to justify whatever commitment needs to be made. We have developed DSA in such a way that it does not make any specific claims about what information should be included. Its contribution is in providing a means of structuring the information being used. The basic structure which has to be learned is very simple. This means that it can fit into existing practice fairly easily. It simply provides a way for the designer to organise the information which is available and thought to be relevant and makes it available for later inspection and use. The information may come from another design method, or simply the prior experience of the designer.