# Capturing Design Decision Rationale with Decision Cards

Marisela Gutierrez Lopez, Gustavo Rovelo, Mieke Haesen, Kris Luyten, Karin Coninx

► To cite this version:

Marisela Gutierrez Lopez, Gustavo Rovelo, Mieke Haesen, Kris Luyten, Karin Coninx. Capturing Design Decision Rationale with Decision Cards. 16th IFIP Conference on Human-Computer Interaction (INTERACT), Sep 2017, Bombay, India. pp.463-482, 10.1007/978-3-319-67744-6_29. hal-01676154

HAL Id: hal-01676154

https://inria.hal.science/hal-01676154

Submitted on 5 Jan 2018

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Capturing Design Decision Rationale with Decision Cards

Marisela Gutierrez Lopez, Gustavo Rovelo, Mieke Haesen, Kris Luyten, and Karin Coninx

Hasselt University - tUL - imec, Expertise centre for Digital Media, Hasselt, Belgium
{marisela.gutierrezlopez, gustavo.roveloruiz, mieke.haesen, kris.luyten, karin.coninx}@uhasselt.be

**Abstract.** In the design process, designers make a wide variety of decisions that are essential to transform a design from a conceptual idea into a concrete solution. Recording and tracking design decisions, a first step to capturing the rationale of the design process, are tasks that until now are considered as cumbersome and too constraining. We used a holistic approach to design, deploy, and verify *decision cards*; a low threshold tool to capture, externalize, and contextualize design decisions during early stages of the design process. We evaluated the usefulness and validity of decision cards with both novice and expert designers. Our exploration results in valuable insights into how such decision cards are used, into the type of information that practitioners document as design decisions, and highlight the properties that make a recorded decision useful for supporting awareness and traceability on the design process.

**Keywords:** Design process. Decision-making. Design rationale documentation.

## 1 Introduction

Designers are knowledge workers with a creative mindset that helps them achieve the end goal of a design project. These solutions, which often represent designer's style and craft, emerge from an unconstrained, free flowing stream of ideas and brainstorming among the different partners of the project. In this context, externalizing the outcomes of the design process is a complex task, both for co-located and remote teams. Moreover, there is a lack of appropriate tools to document the evolution of artefacts and its design rationale in a design process. Existing tools that serve this purpose, while widely explored, are not adopted due to the "extra effort" that they require from designers, and due to the fact that they often interrupt the creative flow.

We identify three problems related to the lack of detailed documentation of design rationale [1,2,3]: (1) the iterative and incremental nature of the design process means that ideas are explored and expanded, but possibly also discarded or radically changed, making it harder to keep track of the rationale behind each idea; (2) a free flow of ideas can be disrupted by documentation activities; and (3) documenting design decisions in collaborative settings is more complex given the various stakeholders that are directly involved in the decision-making process.
Despite these problems, keeping track of how designs evolve toward a final design proposal has high value [4]. First, a clear rationale of how a design was realized makes a proposal more acceptable. Second, externalizing the design process reveals useful knowledge on how issues were resolved or on important bottlenecks that appeared during the process. As such, it contributes to document good practices and “bad smells” (that indicate a decision bottleneck could occur) for later use. Third, the design process involves various stakeholders having different backgrounds, such as product and software engineers, who need to understand and translate designs into fully functional interactive systems. Fourth, documented design proposals are useful for increasing awareness, and promoting the team and self-reflection on the design process. However, despite of the value of capturing design rationale, it is not widely adopted by design practitioners due to a mismatch with their work practices [5,6,7]. We seek to address these problems and enhance value in design propositions by tackling the challenges to record design rationale with a suitable tradeoff between efforts and benefits.

We introduce *decision cards* as a tool to make design rationale concrete by documenting it in a lightweight format. Decision cards are open and flexible, as they do not force any specific technique for recording design rationale. We designed and evaluated decision cards by taking a pragmatic, bottom up approach based on the existing practices of designers. By documenting design rationale within fast-paced projects in a systematic way, we address a core need of designers working in commercial settings. This paper explores how novice and expert designers use decision cards to record design decisions. Subsequently, we analyze the value of decision cards when presented to team members external to the design process. Our findings demonstrate that the *informative* and *actionable* format of decision cards provide a good fit for their integration in design activities, supporting awareness and traceability without constraining creativity.

## 2 Related Work

Design is a reflective practice where a designer actively transforms an artefact, appreciates the consequences of this transformation, and continues reshaping the artefact until it reaches a desired form [8]. Reaching this desired form is a gradual process which involves a co-evolution between the problem and solution spaces [9,10]. The process of “framing and reframing” these spaces is at the core of creativity [8], [10,11]. It is widely accepted that this co-evolution of design problems and solutions is a social process [9], [11]. Furthermore, for a solution to be recognized as such, it needs to be accepted by relevant stakeholders from different disciplines [9], [12].

Designers working in the UI design of interactive systems produce tangible artefacts, such as sketches and prototypes, which are communicated and negotiated with a diversity of stakeholders. The work of a designer in such teams (as in any other design discipline) is to create artefacts that represent a design, which is then materialized by other team members [8]. Shared artefacts serve to create an “external memory” for the team [13], maintain common ground, and facilitate the decision-making process [1], [14]. However, design teams seldom keep track of the process that leads the evolution of
visual artefacts. Thus, the reasons that explain the current state of an artefact – its ra-
tionale – often get lost [15]. The process followed by the team to adopt a solution in
order to realize the design, depicted by the artefact, remains implicit in the memory of
designers or, in the best scenario, hidden in formal documentation or team conversa-
tions (e.g. e-mail, chat threads) [3], [16].

The lack of a proper record of the design rationale can lead to several problems. For example, misunderstandings regarding the next steps in the project (the evolution of the design), or underestimations of the effort that preceded a certain design proposition. These problems could ultimately lead to reduced understanding or acceptance of a proposed design solution [17]. Keeping track of the rationale could potentially solve these issues, although such activities force designers to invest time and effort [15].

## 2.1 Approaches to Capture Design Rationale

Many approaches have been explored to capture, retrieve, and use design rationale in an effective way, but it remains an open challenge to create such a record with an adequate tradeoff between efforts and benefits [3], [5]. Shipman and McCall [16] propose three core perspectives to categorize these approaches: argumentation, communication, and documentation. Table 1 summarizes the characteristics of these perspectives for capturing design rationale.

<table><caption>**Table 1.** Three perspectives to capture design rationale [16], discussed in function of their goals, approaches, advantages, and limitations.</caption><thead><tr><th>Perspective</th><th>Argumentation</th><th>Communication</th><th>Documentation</th></tr></thead><tbody><tr><th>Goal</th><td>Structure the reasoning of designers, improving the outcomes of the decisions</td><td>Capture the natural flow of the conversations of design teams</td><td>Capture rationale with a structure, but without influencing the design decisions</td></tr><tr><th>Approach</th><td>Semi-structured notes which connect related ideas</td><td>Unstructured archive of information occurring in different channels of communication (e-mail, chat, notes, etc.)</td><td>Structured record of design decisions, together with information about who made those decisions and when</td></tr><tr><th>Advantages</th><td>Retrieving and reusing rationale; communicating to externals; comprehensively recording ideas</td><td>Capturing information is easy, since it does not disrupt the design process</td><td>Communicating to externals what has been done; widely adopted by designers</td></tr><tr><th>Limitations</th><td>Capturing rationale is cumbersome since it imposes structure in the reasoning process; not widely adopted by designers</td><td>Retrieving rationale is difficult due to the large amount of information; lack of clarity for communicating with externals</td><td>Capturing information can be time consuming; relevant information might be lost</td></tr></tbody></table>
We explored the advantages and limitations of each of the perspectives detailed in Ta-
ble 1 in order to define a suitable approach to capture design rationale in consideration
of the needs of designers. The argumentation perspective is commonly used in systems
to capture the design rationale. As introduced in Table 1, a number of semi-formal no-
tations have been proposed to structure the argumentation process [15]. Three notable
examples of these notations are: (1) The Design Space Analysis (DSA), which uses a
QOC (Questions, Options, and Criteria) notation [18] to represent the questions around
an artefact, the options to solve these questions, and the criteria for assessing the op-
tions. (2) The IBIS notation, which is graphically represented in the gIBIS tool [19],
represents design problems, their alternative solutions, and related tradeoffs. Likewise,
Compendium is an IBIS-based environment to structure rationale with hypermedia el-
ements [20]. (3) SIBYL [21] is a tool that expands the QOC and IBIS notations to
support teams to visualize the knowledge acquired during the decision-making process.

While these tools and notations offer a valuable insight into how to facilitate the
decision-making process and to exchange information to reach consensus, their adop-
tion among professional designers is limited [5], [16]. A reason for this is the fact that
the argumentation perspective imposes a structure in the design thinking, which results
cumbersome for designers [6,7].

Decision-making in design teams usually happens in face-to-face settings, both in
formal and informal contexts, as designers communicate, negotiate, and reach consen-
sus on design decisions with stakeholders [2,3], [17]. Despite the existing systems for
capturing design rationale, designers are more interested in doing design work than in
recording it, especially since the benefits of this documentation are not evident and
immediate [22]. Our work has been informed by using a bottom up approach, meaning
we started from input, feedback, and the wishes of active practitioners on documenting
design rationale. Instead of focusing on creating solutions for specific decision-making
processes, we explore approaches for supporting designers to record the rationale of
their design decisions without significantly constraining their way of working.

## 2.2 Documenting Design Rationale through Design Artefacts

A variety of tools and approaches have been proposed to document the rationale of the
design process aiming to reduce the time and effort needed, and matching its capture to
the “wicked” nature of design tasks [12], [23]. In the HCI field, some approaches in-
vestigate how design rationale can be attached to tangible artefacts to inspire and guide
designers while keeping track of the rationale of their inspiration sources. In addition,
there is a growing interest in Research through Design (RtD) approaches. RtD aims to
document the knowledge gathered during design processes in a way that makes it suit-
able for communicating with a broader, academic audience [7], [23]. Rather than an
exhaustive list of tools and approaches, we describe the notable insights learnt from
documenting design rationale in a structured way.

One approach is to use tangible artefacts to inspire the design process with the use
of design rationale. Wahid et al. [24] explored how to present visual artefacts together
with a textual description of the design rationale in the form of claims – a representation
that contains the design rationale in the form of positive and negative tradeoffs [25].
Similarly, the Inspiration Cards [26] are tangible artefacts used to communicate sources of inspiration within heterogeneous design teams. Using these simple, “low-tech” cards and a roughly structured method during workshops facilitated engagement of team members. Results of these approaches using tangible artefacts suggest that using standardized templates for coupling artefacts with their rationale in a straight-forward manner is useful to assist idea generation, decision-making, and communication between designers and externals [24], [26]. However, in both of these approaches, artefacts and rationale are crafted in anticipation of ideation activities, which might be a limitation for routine design.

Another approach is to document rationale during ongoing design activities. Dalsgård, Halskov, and Nielsen [27] propose to use maps to structure and visualize the interrelation between elements of inspiration material and ideas emerged during the design process. Similarly, the Project Reflection Tool (PRT) was used to document design projects with the objective of promoting reflection and discussion [22]. The experiences with the PRT showed that documenting design should be straight-forward and result in immediate benefits for the ongoing design tasks [22].

In Design Workbooks [28], Gaver proposes capturing “design proposals” and associated artefacts as a method for creating design spaces. The workbooks include ideas, approaches, and inspiration for a given design problem. Additionally, they allow ideas to change and progress, as it documents proposals and not final designs. Thus, the value of the workbooks lies in the fact that externalizing early ideas can help designers to concretize and expand them. The advantages of this approach is that it includes input created by the designers during the design process and represents progress in a visible way. The limitation is that workbooks usually evolve over a long period of time, which makes them less suitable for teams working in fast-paced design projects [28].

We build upon existing research by adopting the concept of using design artefacts associated to their rationale as a solution to facilitate communication between multidisciplinary design teams. In our research, we analyze how such artefacts could be used to document design rationale in ongoing design tasks, embracing the “ill-defined” and even chaotic nature of design, and attempting to support the decision-making process in a natural, organic way. To this end, we use *decision cards*, a lightweight format for coupling design rationale and artefacts without interfering in the reasoning process. We extend previous research by verifying this approach with design practitioners, seeking to address existing limitations by answering the questions on “what to document” and “what level of detail to use” [22].

## 3 Decision Cards

Decision cards document design decisions related to a set of artefacts that evolve toward the final design. A decision card captures three properties of a design decision: (1) what decision was taken, (2) why it was taken, and (3) who was involved in taking the decision. Decision cards emerged in response to the need detected with design practitioners to be able to keep track of a project in the long term [4], [29]. For instance, in
our previous research we found that designers working in commercial settings consist-
ently report problems such as keeping track of “who said what?” and “why was this
option chosen?” [30]. Current solutions include creating meeting minutes, tracking e-
-mails, and video recording. However, retrieving design rationale from these solutions
is considered to be too cumbersome or time consuming [6], [16]. Decision cards try to
solve this issue with a minimally structured approach to document design activities. We
focus on supporting the early stages of design, where communication around visual
artefacts, such as sketches, pictures, and notes, has an important role in the generation
and selection of ideas [13], [31]. Thus, we aim to capture design rationale without in-
fluencing or interfering with the design thinking or its outcomes.

We explore ways to put minimal structuring into practice, and investigate the per-
ceived value of decision cards. Thus, we defined a basic decision card with a format
that does not constrain decisions in any way, and allows for maximal freedom to facil-
itate capturing design rationale [22]. Shipman and McCall [16] found that documented
decisions need to include “what decisions are made, when they are made, who made
them, and why” to facilitate externals to understand the recorded rationale. Conse-
quently, our decision card template includes a set of basic information fields (see Fig.
1): (1) the title of the decision, (2) a description of the decision in natural language (free
text space, no structure is imposed), (3) the list of team members involved in making
the decision, and (4) supporting material that is related with the design decision, such
as sketches, pictures, and notes.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** The basic information fields in the (A) paper and (B) digital formats of decision cards include: (1) title, (2) description, (3) team members involved, and (4) material related to the decision.</figcaption></figure>

We followed an iterative process to design and validate decision cards. This process,
which resulted in two different formats of decision cards, was used to optimize the
format and approach of decision cards. Fig. 1(A) illustrates the tangible format of de-
cision cards we used in our initial exploration. Fig. 1(B) shows the iterated, digital ver-
sion of the format, which was used in our subsequent study. With these predefined
templates for the decision cards, we attempt to achieve a balance between simplicity
and completeness of decisions. These have been identified as valuable characteristics
of documenting the design process [16], [22]. In the remainder of this paper we analyze
how decisions cards are created by designers and interpreted by people that were not
involved in the decision-making process. Additionally, we explore what aspects of de-
cision cards support awareness of, reflection on, and trust in the design process. This
allows us to optimize decision cards to support the creative flow of a design process,
and convey to externals how and why a design proposal came about.

4 Validating Decision Cards with Designers and Practitioners

We explore the use of decision cards by designers and practitioners who are external to the design process. We organized two workshops to explore how decision cards are used by novice and expert designers to capture design rationale in both co-located and remote settings. We focused on studying the early stages of the design process, when designers are concerned with refining their design goals, exploring, and comparing various design solutions [13], [29]. In addition, we conducted a follow-up lab study to analyze how decision cards are useful to externalize design rationale to team members not directly involved in the design process.

## 4.1 Workshops with Designers: Methodology and Participants

We aim to study how designers use decision cards to record design decisions rationale.
Thus, we organized two workshops: one with novice designers in a co-located setting,
and another one with expert designers in a remote setting. This division was made to
ensure that we covered a variety of perspectives in the design process. The co-located
workshop reproduced the setting in which a group of designers work at the same
place/time to solve a design problem. The remote workshop replicated a situation in
which designers work individually on a design problem, and share their ideas with peo-
ple who are in a remote location, such as other designers, clients, and project managers.
Remote design work is an increasingly frequent situation, thus, it was important to ex-
plore how it can be supported with decision cards.

Validating decision cards in controlled – but realistic – settings is a first and essential
step to explore the potential benefits/constrains of decision cards, and to determine how
they could be optimized for solving real-life design challenges. Including design prac-
titioners in our experimental settings allow us to evaluate decision cards with knowl-
edgeable users, but avoiding the unpredictable circumstances that usually occur in real-
life design work [17].

**Workshop with Novice Designers in a Co-located Setting.** We conducted a 3-hour
long workshop with six novice designers (three female, three male). All participants
studied industrial design at university level (3 Master and 3 Bachelor students). Participants of the workshop were enrolled in an academic course where they were instructed to prototype a digital application while following a user-centered approach.

The workshop consisted of two brainstorming rounds in which the students worked on a design assignment to ideate on an early prototype to enhance awareness in teamwork. The first brainstorming round took place in two small teams using the outcomes of the aforementioned academic course as their source of inspiration. Designers were prompted to record their decisions for this round using a paper version decision cards. The decision cards were briefly introduced as “a template for recording decisions” at the beginning of the session, but it was not explicitly mentioned what information was expected to be included in each individual field. After the first brainstorming round, we asked the full group of designers to converge in one solution integrating the ideas of both teams, also recording their decisions with tangible decision cards. A team of two facilitators and one observer conducted the workshop. The facilitators had a neutral role during the workshop, intervening only to introduce and control the time of the design activities. Due to scheduling constraints of two volunteers, one designer left the session after the first brainstorming round, while a new designer joined for the second round. This fact was not considered as a limitation in the methodology, as we expected to capture an open and dynamic design process.

**Workshop with Expert Designers in a Remote Setting.** For testing the usage of decision cards in a remote collaborative setting, we organized a workshop with five professional designers (two female, three male). Designers had an average of 5 years of experience working in one or more design disciplines, including product and UI design of interactive systems. The individual tests lasted around 90 minutes and were conducted by a team consisting of a facilitator and two observers. The facilitator had an active role by introducing participants to each scenario and encouraging them to think aloud while performing the tasks, but did not interfere with design activities.

Designers were individually guided through four scenarios. These scenarios encouraged designers to explore an existing set of recorded decisions and related artefacts for a hypothetical design project. The design assignment required designers to iterate an early prototype of the dashboard of an app to reduce water consumption. The scenarios assumed that the designer was the new team member of the project, and had to get familiarized with existing knowledge in order to propose a solution. We used a *web application* for presenting designers with relevant content for this design project, including artefacts annotated with decision cards (e.g. storyboards, prototypes). Additionally, the web application enabled participants to upload artefacts, add annotations, communicate with the team, and create a digital version of decision cards.

We asked designers to explore the content on the design project, available in the web application, and propose a solution by creating and uploading sketches. They also had to document their decisions using decision cards. Subsequently, we simulated remote asynchronous collaboration as the observers of the session assumed the role of team members. Without briefing the participant about this process, the observers used the web application to give feedback on the sketches of the designer. Finally, we asked the designers to review the feedback of their team and iterate the solution accordingly.
**Data Collection and Analysis.** To facilitate data analysis, we captured audio and video recordings of the co-located and remote workshops. Additionally, we collected information by means of an interview that took place after each workshop. All the comments from the participants were recorded by the facilitators and observers. The analysis of the recordings from both workshops looked for recurrent activities, topics, and comments of designers. As a strategy to find out how ideas were transferred through the stages of the study, each of the artefacts produced in each session was mapped to the point in which it was created. The results from these workshops are eight sets of decision cards and coupled artefacts, as detailed in Table 2.

<table><caption>**Table 2.** Decision cards recorded during the workshops with designers.</caption><thead><tr><th>Team</th><th>Amount of decision cards</th><th>Designers involved</th><th>Setting</th></tr></thead><tbody><tr><td>T1</td><td>3</td><td>D1, D2</td><td rowspan="3">Co-located</td></tr><tr><td>T2</td><td>4</td><td>D3, D4, D5</td></tr><tr><td>T3</td><td>4</td><td>D1, D2, D3, D4, D6</td></tr><tr><td>T4</td><td>2</td><td>D7</td><td rowspan="5">Remote</td></tr><tr><td>T5</td><td>1</td><td>D8</td></tr><tr><td>T6</td><td>2</td><td>D9</td></tr><tr><td>T7</td><td>2</td><td>D10</td></tr><tr><td>T8</td><td>1</td><td>D11</td></tr></tbody></table>

## 4.2 Follow-up Study with Practitioners: Methodology and Participants

The aim of the follow-up lab study was to analyze how decision cards are useful to externalize design rationale to team members not directly involved in the design process. This lab study simulated the real-life setting where people who are external to the design process, must interpret and use design outcomes (e.g. clients, developers, designers that come in at a later stage). Because of the lack of context to understand and situate design outcomes, this can lead to rejection of the design outcomes, or worse, formulation of alternative designs that are less desirable. Thus, our aim is to explore how decision cards can facilitate the externalization of design outcomes.

The eight sets of decision cards recorded during the workshops with designers were used as input for this study, which involved eight HCI practitioners (five male, three female) aged between 23 and 38 years. The participants had an average experience of eight years in the UI design of interactive systems. They had a background in computer science and visual design, and all had experience working in a multidisciplinary team. The participants were not involved on the workshops conducted with designers.

The participants, hereafter referred as *practitioners*, were asked to review the eight sets of the decision cards recorded during the workshops with designers (see Table 2) as if they were about to join the team. Each individual review session lasted around 45 minutes and was led by a facilitator. The role of the facilitator was to introduce the session and the tasks, and to take a neutral role in guiding participants during their explorations. For each set of decision cards, the practitioners first had six minutes to
explore the decisions. Each set of decision cards was introduced to the practitioners one
by one, and in a randomized order. The practitioners were not briefed about the content,
context, or structure of the decision cards in advance. After a first exploration, the prac-
titioners had to order the set of decision cards based on how important they estimated
each of the decisions was. Next, based on the decisions they reviewed, they were asked
to answer questions regarding which team they perceived as most trustworthy, was hav-
ing the most acceptable solution, and at which stage of the design process they consider
the decisions were taken. To facilitate data analysis, we captured audio and video re-
cordings. In order to find recurrent or relevant responses, the answers of participants
were clearly linked to the set of decisions that it referred.

5 Creating Decision Cards during Design Activities

Participants of the workshops integrated decision cards into their design activities with
minimal effort, having the advantage of supporting the documentation of design deci-
sion rationale. We found that the minimal structure of the decision cards was considered
to be very useful for *externalizing ideas and recording agreements*, partly because it
can be done in a quick and easy way. Designers described decision cards as useful, low-
threshold tools to record design rationale in order to facilitate traceability and awareness
about the outcomes of the design process. Next, we present the evidence gathered dur-
ing our two workshops with designers to support these claims.

**5.1 How were Decision Cards Used by Designers?**

Design processes guide designers iteratively through activities such as *framing* prob-
lems, *generating* ideas and *evaluating* these ideas in order to define an appropriate so-
lution [11]. We found that designers used decision cards in two ways: (1) to convey
ideas during framing activities and (2) to document ideas after evaluating them. The
usefulness of the decision cards to support design activities lies in the fact that they
provide an overview of agreements, do not constrain design thinking, and can be cre-
ated in an easy and organic way. A novice designer expressed during the post-workshop
interview: "*[It's] very easy to write what you think. You know what your thoughts ear-
lier in the process were. It's good to have an overview of thoughts*" [D6].

During the two workshops, we observed that designers used decision cards to gather
prior knowledge for framing a design problem. Detecting relevant information for reuse
can potentially improve efficiency of the design process [29]. In the co-located setting,
designers used decision cards to externalize knowledge previously generated by them
in an earlier stage. For instance, the designers of T3 used decision cards to externalize
"beginning points for a concept" [D3] to be further elaborated. Additionally, decision
cards facilitated for novice designers to externalize their ideas in a meaningful way.

Similarly, in the remote setting, expert designers used decision cards and other arte-
facts as a starting point for their activities. Decision cards facilitated designers to re-
trieve and reuse design knowledge, as expressed by an expert designer during the post-
workshop interview: "If you have decision cards, you can just go back and look it up.
*That makes things a lot easier" [D8]. During the workshop in a remote setting, expert designers found decision cards valuable to overview what decisions were taken and by who. This last point reveals the social nature of design: the role and active participation of team members in the project is crucial when assessing existing decision cards. It was hard for designers to assess the relevance of the documented decisions, as they encountered (fictitious) team members that they have never met, and from who they cannot discover their working style. These findings showed that decision cards should be trusted in order to represent an appropriate solution. An expert designer highlighted this fact when exploring existing decision cards during the workshop: "I reckon these decision cards are some way of using the artefacts in validation meetings, you come to a conclusion, and then you make them like really tangible by putting it on these decision cards. [...] I can see that they [the team] might have a good solution, but I don't know, it can be that [the team's] decisions are a shortcut" [D7].

Additionally, our analysis of the two workshops pointed out that decision cards documented the outcomes of the idea evaluation activities of designers. Decision cards represent consensus moments, where a team agreed on a possible course of action. Consistent with previous research [28], we found that recording ideas in a tangible way facilitated concretizing and expanding decisions. Purposely writing down decisions, as pointed out by one novice designer during the post-workshop interview, was beneficial for self-reflection and traceability: "[Decision cards are a] clever way of showing your thoughts. [...] Could take some effort to write the thoughts, but also forces to think about it, how to write it down. This is good to keep others in track when absent" [D4].

In the co-located setting, novice designers gradually adopted the decision cards as a way of recording and discussing possible courses of action. As the workshop progressed, designers were increasingly confident on how and when to document decisions. The strategies of novice designers for recording a decision was in itself a social process. One team member created the decision card, asked the rest of the team for input while writing it down, or read it afterwards to make sure that the entire team agreed with the content. In some cases, this process resulted in amendments and iterations to the content of the decision (e.g. strikeouts and additions). The adoption of decision cards was also reflected in the fact that their tangible format was actively manipulated and referred to during discussion, as depicted in Fig. 2.

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** Manipulation of decision cards during the co-located workshop with novice designers. Decision cards are framed in red.</figcaption></figure>
While decision cards were useful records of agreements, they did not steer designs in a strict direction. Both novice and expert designers either iterated the decisions into a more refined solution or discarded them. Furthermore, designers did not consider decision cards for idea generation, but as an overview of explored ideas. More than a limitation, we consider this an advantage, as decision cards did not constrain creativity.

## 5.2 What Information was Recorded in the Decision Cards?

The analysis of the content of the decision cards gathered in our studies taught us that decision cards are low-threshold tools, as their purpose can be easily understood and completed by designers with minimal guidance. The information recorded in the decision cards varied according to differences in personal preferences, team styles, and study conditions. Rather than focusing on the type or quality of each decision, we concentrate on the completeness of the information recorded in each field of the decision cards: title, description, list of team members, and supporting material (e.g. sketches, post-it clusters). We found these fields were important to construct and externalize a decision, but that the setting and format of decision cards (paper or digital) in which they were recorded had an influence on its completeness.

As shown in Table 3, the fields of *title* and *description* were filled in all the eight sets of decision cards (19 decision cards in total) we collected. All designers used natural language for recording this information, without using any specific structure or notation. Titles included single words or full sentences to summarize the decision, while descriptions included explanations of team agreements, with different lengths. For instance, the description of some decision cards comprised an extensive reflection about a decision and its implications, while others only a brief, simple description. The type of decisions ranged between high-level ideas to functional requirements. Having a free text space for describing decisions helped designers to document ideas at different levels. This is illustrated with an utterance of a novice designer who expressed during the workshop that one of their descriptions was “*quite straight-forward, but also a decision*” [D3].

<table><caption>**Table 3.** Fields recorded in the decision cards by each design team (T1-T8) for the co-located and remote settings.</caption><thead><tr><th rowspan="2"></th><th colspan="4">Co-located setting</th><th colspan="5">Remote setting</th></tr><tr><th>T1</th><th>T2</th><th>T3</th><th>T4</th><th>T5</th><th>T6</th><th>T7</th><th>T8</th></tr></thead><tbody><tr><th>Title</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>Description</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>Team</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><th>Artefacts</th><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

The study setting had an influence on what information was recorded in the *list of team members* and *supporting artefacts* fields. For the co-located setting, the team members field (i.e. who took a decision) was overall confusing for novice designers. As shown in Table 3, eight decision cards contained information in this field. However, only two
included the names of the designers involved in taking the decision. The rest of the decision cards included broad terms such as “all” [T1] or “the entire design team and others in the room” [T3] (see Fig. 3(B)). When asked about what information they considered to complete this field, novice designers mentioned that they recorded who they thought would be impacted by a certain design decision (e.g. stakeholders, end-users). We believe that the reason of this confusion was the terminology used in the decision card, and that the face-to-face discussion did not immediately showed designers the value of documenting who took each decision.

The *support artefacts* field of decision cards contains a blank space to attach one or more artefacts related to a decision. Our initial expectation was that designers would directly link a decision card to one (or several) artefact. Nevertheless, as shown in Table 3, this was only the case for two decision cards created during the co-located workshop. Data analysis revealed an evident link between visual artefacts and decision cards, but this connection is not straight-forward when looking at the decisions cards as a standalone artefact. Fig. 3(A) shows one of the cases where a decision card was linked to an artefact. Fig. 3(B) depicts a decision card created by T3 where there are no supporting artefacts visibly attached in the decision card.

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Examples of decision cards created by novice designers: (A) created by T2 and (B) created by T3, with supporting artefacts not directly attached to the decision card.</figcaption></figure>

For the remote setting, expert designers used a prototype web application we set up in order to provide a digital version of decision cards and allow designers to collaborate remotely on them. Fig. 4 shows the digital version of decision cards. This digital version, which is an optimized version of the initial paper format, includes a comments and feedback section, list of team members involved in the decision, as well as a set of keywords that classify the decision. Expert designers considered the team members field intuitive and relevant. However, the remote setting of the study and lack of familiarity with the activities of the other team members led designers to be more cautious on who to mention as a part of their decisions. The digital version encouraged designers to create a strong link between supporting artefacts and decisions, since this link could be identified explicitly in the digital version. Designers added a main visual artefact, such as an early mock-up, together with *notes* and *evaluations*, which act as virtual
equivalents of post-it clusters and team deliberations within the apparatus. Fig. 4 presents a decision card produced by D8, together with its attached artefacts.

<figure><img src="image_5.png" /><figcaption>**Fig. 4.** Decision card created by D8, including (A) early sketch of solution, (B) decision card, and (C) evaluation (top) and notes (below) as supporting material.</figcaption></figure>

Besides the fields reported above, we also experimented with secondary fields, such as *priority* and *keywords*. The priority was vastly ignored by novice designers, as they considered difficult to prioritize design elements. Nevertheless, this was a crucial characteristic for expert designers. Expert designers also mentioned the usefulness of keywords. However, they highlighted the need of a more automated tagging process that could potentially facilitate organizing and retrieving decision cards in an efficient way.

# 6 Interpreting Design Decisions by Practitioners

Results of our studies with designers showed that decision cards are useful, low-threshold tools to document and externalize design rationale in an easy way. We believe these characteristics can facilitate awareness about the outcomes of the design process with people not involved in the design process. As validation, we organized a lab study involving practitioners external to the design process to interpret and contextualize the decision cards created by designers. Results of the lab study indicated that practitioners were able to easily interpret the structure of decision cards. Furthermore, the decision cards seemed to facilitate awareness on the flow of ideas and decisions taken by the design team. In this section, we describe what makes a design decision trustworthy and understandable, thus what makes a good documentation of a solution.
## 6.1 What Makes a Decision Card Trustworthy and a Solution Appropriate?

The lab study showed that the completeness of a decision card defines its trustworthiness and appropriateness. It is not surprising that practitioners deemed decision cards as complete when (1) decisions help to clarify the design process and rationale of the artefact, and (2) decisions include the opinions of different team members. Both imply a decision card needs to contain sufficient information.

During the lab study, we asked practitioners to select the most trustable and appropriate solution from our workshops with designers (described in Section 5). The solution proposed by T1 was selected by five practitioners as the most trustable and appropriate. The characteristic that made this set of decisions stand out from the others was that decisions were high-level, yet concrete enough, to guide the early stages of the design process. This is illustrated with the quote of a practitioner: "*[I trust T1 the most] because the ideas are quite concrete and applicable to the context [of the project]. Also I have the feeling that they were talking about ideas that are more important [...]. It was talking about concrete ideas to make it work*" [P8]. However, completeness should not be confused with level of detail. On the contrary, the lack of technical details is an indication for an open, and less limiting creative process in the early stages of the design process. In the context of the design assignments used for the workshops, high-level decisions were perceived by practitioners as more creative. Decision cards that contained many technical details were trusted the least by the practitioners.

Including who is involved in the decision and why such decision was reached, made the decision appear as trustworthy, as described by a practitioner: "*The decision says, people involved: "all". Decisions record the process, so everybody knows this decision and why*" [P2]. The trustworthiness of a decision card is also related to team involvement, and specifically an active and meaningful involvement. Additionally, including indications on timeframes, task division, usability, and end-user acceptance can also increase the value of the decisions.

Considering all responses gathered during the lab study, the most recurrent reasons for reduced trust in a set of decisions were: (1) vague content or missing elements, (2) spelling and grammar mistakes, (3) lacking a clear link between the decision and subsequent versions of the related design artefact, and (4) a mismatch with the stage of the design process that was specified (e.g. already including widget types while still in the early design phase). These reasons often make people feel a decision card is *rushed*, given insufficient thought and discussion, and they are less likely to accept such a decision. For instance, a participant clarified that the solution proposed by T4 was perceived as the least trustworthy because of the mismatch between the decision and its supporting artefact: "*[The decision card] presents misleading information, I don't understand from which circle diagram it is talking about*" [P6].

## 6.2 What Makes a Decision Card Understandable?

We found that decision cards are understandable when (1) decisions are concrete and concise, and (2) decisions are clearly linked to a related design artefact. The consensus from practitioners was that decisions that include a clear title and a concise description,
addressing the rationale, are more understandable and informative. Having a balanced amount of structured text and artefacts was preferred, as described by a practitioner: "I think [T2] is more concrete. This one [T3] focuses on really tiny details. And this one [T2] has the structure and yeah, the overall ideas, but also motivation [is] a bit clearly organized" [P7].

Furthermore, information about a version number and date was mentioned as useful to contextualize a decision and facilitate its understandability. The understandability of decision cards is enhanced if it includes concrete points of action as this information documents how the decisions fit into the design process. Decision cards that clearly state what should be done next by the design team (e.g. requirements, graphical guidelines, concepts to explore) facilitate its inclusion into design activities.

# 7 Decision Cards as Tools to Document Design Rationale

We introduced decision cards as a lightweight, minimally structured way to record design rationale. Decision cards emerged in response to the need detected with designers working in commercial design settings of keeping track and reusing design rationale in long-term projects [4], [29,30]. Our work was informed using a bottom up approach, meaning we started from input, feedback, and wishes of active practitioners on documenting design rationale. Thus, we aim to support designers to record rationale without significantly changing their work practices. This paper describes how decision cards were created by designers and interpreted by people that were not involved in the design process. Our findings highlight the fact that decision cards are *informative*, as they serve to record agreements for future reference, and *actionable*, as they externalize design outcomes and activities that are to be undertaken by the design team. Next, we discuss the implications, advantages, and limitations of documenting design rationale with decision cards.

## 7.1 Record Agreements among Design Teams

The information recorded in decision cards reflected the outcomes of the idea evaluation activities among design teams. Decision cards were created to contain information about what decision was taken, why it was taken, and in some cases, who was involved in taking the decision. The template with minimal structure helped both groups of designers to keep track of their ideas during discussions.

The main limitation in documenting a decision card is consistent with the limitations in capturing design rationale [5,6]: it slowed down the free flowing stream of ideas as it took time to create decision cards. However, nine out of the 11 designers involved in our studies claimed that they were willing to adopt decision cards in light of the potential traceability of long-term projects. During the post-workshop interviews, we prompted designers to reflect on how decision cards could fit in their professional practice. Five out of six novice designers mentioned that decision cards could serve to focus and synchronize team discussion, and to spark inspiration within the boundaries of the design problem. Additionally, novice designers considered decision cards as a "pile of
landmarks”[D3] that could be used to reference their deliberations and agreements in a more useful format than traditional collaboration tools (e.g. online repositories, e-mails). The five expert designers valued the use of decision cards in one or more of the following situations: (1) large projects involving many team members, (2) projects that run over an extended period of time, (3) multidisciplinary settings where people with different backgrounds need to be informed about the design results, but not about the process, and (4) projects where teams change frequently.

## 7.2 Externalize Agreements to Heterogeneous Team Members

In large, heterogeneous teams, keeping a record of design rationale can serve to increase the acceptance of a proposed design solution. We found that decision cards were useful to externalize ideas within design teams and to people external to the design process in a quick way. However, not all decision cards were constructed nor perceived by externalers in the same way. These results are consistent with previous research which elabo-rates on the challenges of *what content* and *what level of detail* to document as a deci-sion [21]. Thus, we synthesized three properties that helped to valorize a decision card in terms of awareness and influence on the perceptions about the proposed design so-lution.

* **Complete.** Decisions that include concrete information and details about why a de-cision was taken were perceived as more trustable and led to higher acceptance of the solution. This is related to the fact that the effort invested in creating a decision is associated with the quality of the process and rationale behind it. This suggests that decision cards should be optimized to solve the tension between creating deci-sion cards without disturbing the creative flow and including the correct amount of information. We found that using a digital version of decision cards facilitated for designers to include more information. However, it is clear that more content does not always generate more trust in the decision. For instance, if a decision card asso-ciated to the early stages of the design process contains many (technical) details, it is perceived as a less valuable decision since it does not document the ideation pro-cess that led to a solution.

* **Connected.** Decisions that are linked to artefacts, previous decisions, or support ma-terial (e.g. artefacts, notes) are perceived as more valuable. Connected decisions pro-vide an overview of the evolution of an artefact making the flow of ideas evident. With connected decisions, a stronger rationale is build: following the links between decisions, various aspects of the resulting design get an underpinning. It adds trace-ability that can be used to track the evolution of a project from the beginning up until the most recent design decision.

* **Inclusive.** Decisions that include a larger representation of team members involved in a project were more interesting: they involve multiple opinions and perspectives. Decision cards that include relevant questions and/or discussion were considered as more inclusive, even if less team members were explicitly mentioned in the decision card. This type of content as part of a decision card implied that the voices of the
team members had an impact on the design process. Note that the roles that are rep-
resented by team members listed on a decision card, are also considered to be an
important aspect. If an essential role is missing (e.g. a designer is not part of a deci-
sion on graphical layout), the decision card might lose its value.

These properties are guidelines to inform design rationale systems on what content and
level of detail to record as a decision. We argue that a minimally structured way of
documenting decisions provide a suitable tradeoff between efforts and benefits for cap-
turing and retrieving design rationale.

8 Conclusion

While there are tools and notations to record the design decision rationale, they remain
unused as they fail to be incorporated in the practices of design teams. In this paper we
proposed an approach to capture and externalize the design decisions in an organic and
straight-forward way: *decision cards*. Our results showed that decision cards allowed
designers to elaborate their decisions freely. Furthermore, decision cards facilitated
team members to understand the flow of ideas and decisions taken by a team, even
when these team members were not part in the design process. Decision cards provide
a way to reflect on the design process both to each team member individually and to
the entire design team. We consider decision cards as a starting point to create a bridge
between structured and rigid documentation of design rationale, and an approach that
matches the free flow of ideas that characterizes the design process. Furthermore, given
the *actionable* and *informative* format of decision cards, they can be used from the con-
ceptual stages of the design process to the later stages of the process.

A potential limitation of the decision cards could be that it requires designers to
spend time and effort in documenting the decision. However, designers who were in-
volved in our studies creating decision cards recognize the long-term benefits of having
such a record of their process. Future validations of decision cards will benefit from
longitudinal, in-the-wild studies. The evidence we gathered in controlled (but realistic)
situations suggests that decision cards, in combination with design artefacts, can be
used for supporting awareness and traceability on the design process.

**Acknowledgements.** This research was supported by the COnCEPT project, funded by the European Commission 7th Framework ICT Research project (no. 610725). We give special thanks to the designers involved in our studies, and to our colleagues Jesús Muñoz Alcantara (Eindhoven University of Technology) and Benny Daems for their input and support for the co-located workshop.

References

1. Mentis, H.M., Bach, P.M., Hoffman, B., Rosson, M.B., Carroll, J.M.: Development of Decision Rationale in Complex Group Decision Making. In: CHI '09 Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, pp. 1341–1350. ACM, New York (2009)

2. Haug, A.: Emergence Patterns for Client Design Requirements. Des. Stud. 39, 48–69 (2015)

3. D'Astous, P., Détienne, F., Visser, W., Robillard, P.N.: Changing our View on Design Evaluation Meetings Methodology: A Study of Software Technical Review Meetings. Des. Stud. 25, 625–655 (2004)

4. Klemmer, S.R., Thomsen, M., Phelps-Goodman, E., Lee, R., Landay, J.A.: Where Do Web Sites Come From?: Capturing and Interacting with Design History. In: CHI ’02 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 1–8. ACM, New York (2002)

5. Burge, J.E.: Design rationale : Researching Under Uncertainty. Artif. Intell. Eng. Des. Anal. Manuf. 22, 311–324 (2008)

6. Horner, J., Atwood, M.E.: Design Rationale: The Rationale and the Barriers. In: NordiCHI ’06 Proceedings of the 4th Nordic conference on Human-computer interaction: changing roles, pp. 341–350. ACM, New York (2006)

7. Bardzell, J., Bardzell, S., Dalsgaard, P., Shad Gross, Halskov, K.: Documenting the Research Through Design Process. In: DIS ’16 Proceedings of the ACM Conference on Designing Interactive Systems, pp. 96–107. ACM, New York (2016)

8. Schön, D.A.: The Reflective Practitioner. Temple Smith, London (1983)

9. Dorst, K.: Design Problems and Design Paradoxes. Des. Issues. 22, 4–17 (2006)

10. Dorst, K., Cross, N.: Creativity in the Design Process: Co-evolution of Problem-Solution. Des. Stud. 22, 425–437 (2001)

11. Warr, A., O'Neill, E.: Understanding Design as a Social Creative Process. In: C&C '05 Proceedings of the 5th conference on Creativity & cognition, pp. 118–127. ACM, New York (2005)

12. Buchanan, R.: Wicked Problems in Design Thinking. Des. Issues. 8, 5–21 (1992)

13. Cross, N.: Design Cognition : Results from Protocol and other Empirical Studies of Design Activity. In: Eastman, C., Newstatter, W., and McCracken M (eds.) Design Knowing and Learning: Cognition in Design Education. pp. 79–103. Elsevier, Oxford (2001)

14. Dow, S.P., Fortuna, J., Schwartz, D., Altringer, B., Schwartz, D., Klemmer, S.: Prototyping Dynamics: sharing Multiple Designs Improves Exploration, Group Rapport, and Results. In: CHI ’11 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 2807–2816. ACM, New York (2011)

15. Shum, S.B., Hammond, N.: Argumentation-based Design Rationale: What Use at What Cost? Int. J. Hum. Comput. Stud. 40, 603–652 (1994)

16. Shipman, F.M., McCall, R.J.: Integrating Different Perspectives on Design Rationale : Supporting the Emergence of Design Rationale from Design Communication. Artif. Intell. Eng. Des. Anal. Manuf. 11, 141–154 (1997)

17. Stempfle, J., Badke-Schaub, P.: Thinking in Design Teams - An Analysis of Team Communication. Des. Stud. 23, 473–496 (2002)

18. MacLean, A., Young, R., Bellotti, V., Moran, T.: Questions, Options, and Criteria: Elements of Design Space Analysis. Human-Computer Interact. 6, 201–250 (1991)

19. Conklin, E.J., Yakemovic, K.C.B.: A Process-Oriented Approach to Design Rationale. Human-Computer Interact. 6, 357–391 (1991)

20. Shum, S.B., Selvin, A.M., Sierhuis, M., Conklin, J., Haley, C.B., Nuseibeh, B.: Hypermedia Support for Argumentation-based Rationale : 15 Years on from gIBIS and QOC. In: Dutoit, A., McCall, R., Mistrik, I., and Paech, B. (eds.) Rationale Management in Software Engineering, pp. 111–132. Springer-Verlag, Berlin (2006)
21. Lee, J.: SIBYL: A Tool for Managing Group Decision Rationale. In: CSCW '90 Proceedings of the 1990 ACM conference on Computer-supported cooperative work, pp. 79-92. ACM, New York (1990)

22. Dalsgaard, P., Halskov, K.: Reflective Design Documentation. In: DIS '12 Proceedings of the ACM Conference on Designing Interactive Systems, pp. 428-437. ACM, New York (2012)

23. Zimmerman, J., Stolterman, E., Forlizzi, J.: An Analysis and Critique of Research through Design: Towards a Formalization of a Research Approach. In: DIS '10 Proceedings of the ACM Conference on Designing Interactive Systems, pp. 310-319. ACM, New York (2010)

24. Wahid, S., Branham, S.M., McCrickard, D.S., Harrison, S.: Investigating the Relationship Between Imagery and Rationale in Design. In: DIS '10 Proceedings of the ACM Conference on Designing Interactive Systems, pp. 75-84. ACM, New York (2010)

25. Sutcliffe, A.G., Carroll, J.M.: Designing claims for reuse in interactive systems design. Int. J. Human-Computer Stud. 50, 213-241 (1999)

26. Halskov, K., Dalsgaard, P.: Inspiration Card Workshops. In: DIS '06 Proceedings of the ACM Conference on Designing Interactive Systems, pp. 2-11. ACM, New York (2006)

27. Dalsgaard, P., Halskov, K., Nielsen, R.: Maps for Design Reflection. Artifact. 2, 176-189 (2008)

28. Gaver, W.: Making Spaces: How Design Workbooks Work. In: CHI '11 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 1551-1560. ACM, New York (2011)

29. Sharmin, M., Bailey, B.P., Coats, C., Hamilton, K.: Understanding Knowledge Management Practices for Early Design Activity and its Implications for Reuse. In: CHI '09 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 2367-2376. ACM, New York (2009)

30. Gutierrez Lopez, M., Luyten, K., Vanacken, D., Coninx, K.: Untangling Design Meetings: Artefacts as Input and Output of Design Activities. In: ECCE '17 Proceedings of the 35th conference of the European Association of Cognitive Ergonomics. In press (2017)

31. Sharmin, M., Bailey, B.P.: Making Sense of Communication Associated with Artifacts during Early Design Activity. In: LNCS (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), pp. 181-198 (2011)