Whats in Design Rationale

Summary

Lee and Lai examine what a design rationale representation must capture to support design work. They argue that evaluating design rationale systems requires looking at their expressive adequacy: whether they can make explicit the alternatives, goals, questions, claims, arguments, dependencies, and decisions that matter during design. The article develops a framework for comparing rationale representations and presents DRL, the Decision Representation Language, as a highly expressive approach for documenting and reasoning about design decisions.

Important Keywords

Design rationale: the explicit record of design decisions, alternatives, goals, claims, arguments, and reasons for accepting or rejecting options.
Expressive adequacy: how well a rationale representation can capture the elements needed to support design tasks.
Decision Representation Language (DRL): Lee and Lai's representation language for modeling design reasoning through decision problems, alternatives, goals, claims, and relationships.
Alternative: a possible design option considered in response to a decision problem.
Goal: a desired property or criterion used to evaluate design alternatives.
Claim: a statement used in the rationale to support, oppose, or qualify a design alternative.
Argument: reasoning that connects claims, goals, and alternatives in support of or against a decision.
Dependency: a relationship showing how one rationale element depends on or affects another.

Important Concepts

Design rationale is more than the final decision; it includes why alternatives were considered, rejected, supported, or modified.
A rationale representation should support design tasks such as evaluation, communication, reuse, conflict detection, and justification.
DRL models design reasoning through decision problems, alternatives, goals, claims, and relationships among them.
Making rationale explicit helps teams understand trade-offs and revisit decisions when constraints change.

Examples

A team choosing between two interface layouts records not only the selected layout but also the usability goals, rejected alternatives, supporting evidence, and objections.
When a later requirement changes, the rationale helps designers identify which earlier decisions need to be reconsidered.