In the software and interface design process, designers must make critical decisions about the system. Whether the choice of the architectural style or picking a color palette for the interface, these decisions determine crucial components for the development phase. Therefore, it is vital to document these choices. A design rationale helps the designer do so.
A design rationale documents all the decisions made by the designer and the reasons behind making those choices. Additionally, it records various alternatives which were considered by the designer and the reason for rejecting them. In short, a design rationale explains why a system has been designed the way it is.
In interface design, the designer has to come across many HCI-related design decisions. Therefore, a design rationale is fundamental in HCI, owing mainly to the following reasons:
Assessing alternatives: In the interface design process, the designer is sure to encounter situations where they are presented with alternatives they can choose from. For example, the menu options on an interface can either be shown in the navigation bar or hidden behind a hamburger menu. In such a situation, the designer considers trade-offs between the available options and decides which one to go for. All this must be documented in the design rationale.
Avoiding missing the optimal solution: Realistically, the designer considers only a few of the alternatives at a time. Therefore, there is a possibility that some options are left undiscovered, which may prove to be better than the currently chosen one. In such a situation, the designer can have a look at the design rationale and determine if the ideal solution has been investigated already or not.
Reusing design rationales: Most often, the context of the interface under design relates to another interface previously designed. If the design rationale of the older interface has been recorded, it can be reused, so the designer does not have to go through the decision-making process again.
There are two techniques of organizing the design rationale, which determine its type. The types of design rationales are as follows:
Process-oriented
Structure-oriented
Process-oriented design rationales accurately capture the history of all the design decisions as they occur. These are process-oriented because they can efficiently integrate into the interface design process.
One way to represent process-oriented design rationales is through the issue-based information system (IBIS) notation. It displays the design decisions as a hierarchical structure, having the following components:
Issue: The main problem under question.
Positions: The possible solutions for the issue.
Arguments: To support or reject the positions.
Sub-issues: Secondary issues which modify the root issue.
The following illustration showcases how IBIS structured a process-oriented design rationale graphically.
Structure-oriented design rationales involve structuring the decisions after all of them have been considered. Such a structure-oriented approach to organizing the design rationale is also known as design space analysis.
Design space analysis is represented using the Questions, Options, and Criteria (QOC) notation, which has the following components:
Question: The major issue considered.
Options: The alternate solutions for the question. Favorable options are linked with solid lines and negative ones with a dashed line. The best option is outlined with a rectangle.
Criterion: Used to evaluate the options to select the optimal one.
The following illustration showcases how a design space analysis is structured graphically using QOC notation:
Free Resources