Materializing Design
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.
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.
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.
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.
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. Digital files in software repositories are associated with metadata pertaining to their form and origins. Metadata are not first order design materials per se: they are second-order digital artefacts of the design process – or digital traces – which themselves shed light on how design practice takes place.
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. In Figure 2, we see how the designer of the alt.ctrl game Lest Ten Horizons Cry (LTHC) has used a commit message to not only describe what has technically changed (the dials), but how (the feedback loop involving a dial and a press, i.e. graphics as well as timing), as well as why (to make it better match to the author’s vision for how such a dial should operate).
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. We assert that designers within the academy should practice the discipline of methodical documentation of practice to justify gesturing to their own processes as evidence of their design knowledge contributions.
A reflective journal documenting higher-order design reasoning
While commit messages enable us to capture reflection-in-action reasoning, a lot of design problem solving happens outside of design activity, i.e. what Donald Schon characterizes as reflection-on-action. Git does not by default include a feature to capture reflectionon-action, thus MDM introduces a document to a standard Git repository dedicated to the capture of longer form, reflection-onaction accounts of design reasoning: the reflective journal. The reflective journal is updated on a regular and ongoing basis all throughout the process of a design project (once a week is fairly typical). The journal’s absence of immediate connection to modified design materials invites designers to disengage from immediate technical concerns and instead frame their design activity in the context of higher order conceptual intentions. In Figure 3, we see an extract of a reflective journal entry pertaining to the LTHC project where the designer is considering meanings and framings to place around the UX-driven playful experience he wishes to bring to life. Contrast the nature of content he includes in his commit message (Figure 2) with that of his journal entry (Figure 3): commit messages tend to revolve around specific technical materials and their behaviour, whereas journal entries tend to grapple with higher order perspectives of core design concepts.
Practice-based disciplines all feature a common difficulty: in order to be mastered, they must be practiced – for they concern knowledges that are embodied, contextual, reliant on intuition, and tricky to capture in terms of cut and dried rules. Learning relies on the learner making sense of their own practical experiences. Reflection is a form of cognition in which individuals revisit experiences they have faced that surprised them, coupled with deconstruction and reconstruction such that those experiences can be meaningfully situated alongside existing knowledge (and thus, are no longer surprising). Reflection has long been a mainstay of pedagogical approaches adopted by practice-based disciplines including nursing, teaching, and social work, and the reflective journal has frequently been adopted as a concrete tool for capture of such reasoning experiments. Reflective journals are useful both for learners to maintain a documented trace of their learning experiences, and for instructors to gauge how much their students have learned. We deploy reflective journals in MDM both as a means for designers to collate their reflection-on-action (in the service of learning) and also as a way to house designerly reasoning in a form legible to parties wholly external to the design situation.
We pause here to note that not all writing that appears in a journal intended for reflection necessarily counts as reflection-onaction. Newcomers to MDM sometimes struggle to differentiate description from reflection: the former is necessary for the latter, but the latter is not interchangeable with the former. In our experience, responding to Terry Borton’s provocations, “What? So what? Now What?” when authoring reflective journal entries provides designers with a simple template around which to document their design activity in a way that invites reflection-on-action.
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 statement at 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. As Sue Breakell writes in relation to the material body of an archive, it “. . . is not materially monolithic but bears the material imprint of its construction, woven from its component parts into a system”. 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. Scholarship stemming from an MDM archive supports its assertions with evidence sourced from its original archive, through citation and/or direct linkage. We position MDM as part of a larger academic cultural shift that is digital first, upfront about the provenance of its evidence and materials, acknowledges subjectivity and positionality, and makes up for a shortfall in data quantity by transparently demonstrating data quality. 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. This is a quality we see underrepresented in much practice-based design scholarship, but which we seek to change.
View Archives