Method for Design Materialization

To emphasise that designerly knowledge is of value (beyond its outputs), we must consciously attend to how we articulate and materialize design knowledge, as well as consider how it affords scholarly engagement and debate. We believe that designers need to develop a discipline of documentation of their design activity, and assume that they are documenting not only for themselves but as a way to continuously demonstrate a through-line in their design reasoning. Documentation resulting from such a mode of audience-oriented introspection can then serve as material traces of design activity that peers in the field can engage with and critically evaluate. They can additionally use it as material evidence on which to theorize designerly reasoning and practice.

Purpose

The Method for Design Materialization (MDM) is our proposal for exactly this. Devised especially for materializing game and interaction design reasoning, and taking inspiration from prototyping theory, reflective practice, interaction design, software development, archival practice, and qualitative research, MDM involves methodical digital archiving of all stages of design and production, coupled with regular and reflective journaling by the designer. It challenges us to make the way we think about design less opaque in the way we document design, bringing it closer to the way we practice design.

It involves...

Materializing design activity involves intentionally surfacing context, constraints, intentions, timelines, materials, development environments, experience, and subjectivity. Design activity also involves exploration of multiple solutions that may impact significantly on the designer’s reasoning process, but which the external world may never encounter. Fortunately for designers whose practice is primarily digital, a class of existing software already roughly provides the functionality necessary to support the capture of components of the aforementioned list: version control software.

Version control in its standard usage is the incremental tracking of the history of a software project’s code. Each time a developer writes a significant block of code, they commit it to a version control software repository which, over time, comes to represent the entire history of the project from the first line of code to the last. Each change is accompanied by a commit message that briefly describes the work done (e.g. “feat: Dials refined”). Each moment along this timeline can be fully recovered by checking out a specific version of the project via the associated commit. Contemporary software projects often use online archives (such as GitHub, GitLab, or BitBucket) that are viewable either publicly or privately by teams of developers who can work on them simultaneously. Software engineers use these features primarily as a form of team management, error proofing, and open sourcing.

Figure 1: Components of an MDM archive (optional items are preceded by an asterisk).

MDM leverages version control processes, concepts, and technologies, but reorients them to privilege intentional documenting or tracing of design processes primarily involving digital materials: the repository of software development becomes the archive of digital design practice. Alongside housing code and assets, which are discretely grouped chronologically as “commit” bundles, a designer practicing MDM explicitly documents the evolution of their design motivations or intentions and their design reasoning and problem solving along the duration of design activity (which may factor in previous design experiences), using both descriptive and reflective forms of writing.

Next we examine in closer detail key components of MDM documentation built on top of a basic GitHub repository infrastructure.

  • Motivation statement.md

    The repo starts with a motivation statement, a "why" behind the project where the designer sets their design intentions and lays the groundwork for their investigation

  • Journal.md update # 1

    Along the way, the designer reflects on their design trajectory at a distance, relating what they have done, how this brings them closer to the goal. We often use the What // So What // Now What mechanisms to get the designer thinking.

  • Bundle # 1

    Commit message + reasoning of why you have done so

  • Bundle # 2

    Commit message + reasoning of why you have done so

  • Bundle # 3

    Commit message + reasoning of why you have done so

  • Playable build

    Being able to play the artifact adds an affective dimension to the analysis that can not be captured otherwise.

  • Journal.md update # 2

    Journal reflections are different from the commit message reflections in their distance from designerly action and hence the designer's point-of-view on the investigation

  • Bundle # 4

    Commit message + reasoning of why you have done so

  • Bundle # 5

    Commit message + reasoning of why you have done so

  • Bundle # 6

    Commit message + reasoning of why you have done so

  • Playable build

  • Bundle # 7

    Commit message + reasoning of why you have done so

  • Bundle # 8

    Commit message + reasoning of why you have done so

  • Journal.md update # 3

    These reflections give the analyst an insight into the mind of the designer, an added degree of resolution and confirmation about the designer's intention which can at best only be assumed when analyzing the artifact in isolation.

  • Playable build

  • Closing statement.md

    The designer concludes the project with a closing statement reflecting on the completed project.

A comprehensive collection of design materials

The academic design community typically does not have access to the interim materials that helped the designer determine how to go about solving their design problems. This is a shortcoming, as those materials often hold clues to why a designer did things in certain ways. Because GitHub stores repository contents online, so long as the designer adopts a mindset of “include all of it on the record”, it becomes possible for anyone not directly involved in the making process to later access these interim materials. These interim materials – which include assets, code, and builds – can be used to form a materially-informed understanding of the design problem context. Over time, with most materials being committed to the archive, the archive contains a fairly comprehensive capture of how project materials evolved over time.

In line with archival practices associated with visual arts, an MDM archive can house more than text-based content: it may trace designerly reasoning through physical design process artifacts such as sketches, physical construction techniques, and more. Given its digital nature, however, instead of asking, “Can I use MDM to archive a specific artifact?”, a designer practicing MDM asks, “What forms of digital capture will communicate a legible trace of my reasoning?”. As such, digital photos, videos, and voice notes are mainstays of MDM archives.

Commit messages accompanying bundles of modified materials conveying design reasoning

Descriptive and/or reflection-in-action accounts of design practice are reported for each set of materials bundled in a “commit” via use of Git commit messages. Commit messages are a foundational element of MDM that enable researchers to draw connections between material changes and designerly intention. Whereas in regular software development contexts, commit messages usually report on technical changes, in MDM a commit message acts as an annotation associated with a bundle of modified code or assets that expresses designerly reasoning and intention underlying the modifications.

We acknowledge that this style of commit message is at odds with how many (perhaps most?) software developers are accustomed to using commit messages, meaning that there is friction between existing context of practice and our prescribed context of practice. At the same time, all disciplines involve discipline in the sense of adherence to a set of expectations and practices.

Figure 2: A commit made to the Lest Ten Horizons Cry archive

Additional MDM components

The three aforementioned MDM components – a comprehensive collection of design materials, commit messages accompanying bundles of modified materials conveying design reasoning, and a reflective journal documenting higher-order design reasoning – are non-negotiable foundational forms of evidence on which MDM is premised. For newcomers to MDM, we advise first focusing on developing a robust documentation practice around maintenance of those three components before committing to further forms of documentation.

For designers who enjoy documentation, we encourage the authoring of a motivation statementat the start of a project. Such a document serves to orient the designer in decision making during design activity. Project motivations also typically change over time – and having a record of these changes sheds additional insight into why particular paths of design activity are pursued when.

Designers may also wish to use their MDM archive to house any precedent studies they undertake to inspire and inform their own design directions.

A final form of documentation we invite designers to adopt is a closing statement, in which they reflect on the entire process, their outcomes, and what reflections they take forward with them.

We do acknowledge that documentation of design practice can feel like an expense of resources that could have otherwise directly supported design practice. We reiterate that MDM documentation as an academic endeavour ultimately serves to facilitate the lives of designers, as it greatly enhances our abilities to materially engage with and/or theorize design practice.

MDM archives as subjective data

Traditionally, archivists are not necessarily the same individuals whose work is being archived – or indeed those engaged in archival research. In contrast, MDM archivists are the designers themselves, and are performing archiving in real time as creation is taking place. By definition, then, an MDM archive is a subjective form of data: its contents are determined by the designer’s choices around inclusion and exclusion. An MDM archive therefore amplifies qualities of design practice itself: it is contextual and subjective.

Data that is contextual and subjective ought to be handled and interpreted as such. MDM archive materials are interpreted methodically using qualitative techniques such as close reading, Grounded Theory, or Thematic Analysis. In keeping with this philosophy, MDM archives are intended to be public and open, inviting their interpretation to be debated by other scholars in the community.