Design Rationale

Problem

There used to be a lot of interest in machine-processed records of
design rationale. The idea was that designers (software designers,
mechanical engineers, architects, you name it) would not only record
the results of their design thinking using computer-based tools, but
also the process that they followed while designing. Thus, instead
of just creating a user interface mock-up (say), the software designer
would also record a justification for why it was as it was and what
other alternatives were considered and rejected.

The problem is that designers simply don't like to do this. The early
tools that let them do so rather got in the way and forced them to
describe their design decisions in terms of a rhetorical structure
(as in: "this is the question I was considering," "here is one solution
to the question," "here is another solution," "The first solution
doesn't work because...", "The second solution costs a lot..." and
so on.)

But the idea keeps coming back. The current notion is that rationale
can be captured on the fly while the designer designs. The key idea
is that design has to be regarded as a continual inquiry process, in
which the designer records lots of open questions that need to be
considered later. So the questions and the answers to them mediate
between earlier and later forms of the design. The rationale is the
trace of the design history in terms of what the design was like,
what questions were asked, and how it evolved; there's no need for the
designer to record any rationale explicitly. We're looking at three
kinds of rationale captured in this way: motivations for design
decisions (in terms of higher level artifacts -- such as features
being derived from goals), illustrations of design reasoning (such
as scenarios illustrating the need for a feature), and resolutions
of issues (much like classical design rationale, but done more
surreptitiously as annotations to the artifacts).

In this project, you'll take a single documented design process (from
the CHI'97 design briefings) and redocument that process in retrospect
as an inquiry cycle (design version - deliberation - change - design
version...) The goal is to compare the roles played in that process
of the three kinds of rationale. Are there any generalizations you can
make about this?

This project uses the HCI literature and a user interface example, but
it should appeal to anyone interested in software design, CAD, HCI
or intelligent systems. There are also connections with hypertext and
DB research, since all this information would have to be stored and
indexed in a real design rationale support tool.