Materializing DesignResearch Group

Guides & Tools

Practical guides, workflows, and tools for MDM

  • Jul 21, 2026

    Rilla Khaled

    Read

    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.

    Fig1

    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 [2], physical construction techniques [23], 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 [20].

    Fig2

    Commit messages accompanying bundles of modified materials conveying design reasoning

    Descriptive and/or reflection-in-action accounts of design practice [31] 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.

    Fig3

    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 [31]. 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 [28], 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?” [13] 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” [14]. 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 [21], but which we seek to change.

  • Jun 29, 2026

    Rilla Khaled

    Read

    Practicing MDM

    Make it material

    Ensure that your research workflow accounts for surfacing and materializing your design reasoning / reflecting / moves / problem solving / problem finding.

    Context Research-through-Design (RtD) makes room for scholars to problem solve through making. At the same time, that problem solving can only be partly demonstrated in any resulting design/creation outputs. Most of the knowledge gained “along the journey” is legible only to the maker. Counteract this by intentionally forming material traces of your design reasoning as your project is underway, whether in the form of annotated sketches, well formed questions, design intentions, regularly maintained process journals, visualisation sketches, or prototypes associated with design research questions, and more. The operative rules of thumb here are externalise the idea in your head and connect your design reasoning to your design materials.

    Make space/time for capture

    Ensure that your research workflow affords regular archival capture of design reasoning / reflecting / problem solving / problem finding.

    Context The practice side of design research can take us away from a headspace of critical reasoning, especially when it flows smoothly. A common response we hear with regard to adopting MDM is, “but it will interrupt my practice flow1!” Design practice in an academic context necessitates different commitments and forms of discipline from design practice in an industry/professional context. Revisit your entire workflow, checking that most of its major stages can be documented or captured, and/or that any gaps can be offset by regular, recurring documentation (and/or reflection) phases. This will facilitate responsibly contributing new knowledge to the body of design knowledge. Next comes the hard part: 🦾 being disciplined to your revised workflow 🦾

    Make space/time for reflection:

    Build intentional regular reflection “stops” into your research workflow where you write about and document what you have been doing, why it is significant, and how your design activity and reflection will inform your future trajectory.

    Context Reflection is how practitioners learn from their own experience. Our work has shown that it assists designers in forming stronger understandings of their design problems, and enhances their ability to perform design problem solving. Having a regular, reflective account of personal design practice also greatly facilitates the task of communicating design research and learnings for external audiences. Most designers are not in the habit of incorporating regular reflection stops into their workflow, however. Schedule them if need be, but target doing them no less than once a week, because memory is fallible.

    Chain of evidence:

    Protect the integrity of your chain of design research evidence.

    Context There are many moments in game design research where confidence in implied chains of evidence are under threat. If the integrity of the evidence is cast into doubt, any claims leaning on that evidence are likewise cast into doubt. Seek to form a chain of evidence in your research with as few breakages as possible linking together material traces relating to research question – concept/intention – sketching/prototyping – formal/material/functional experimentation – feedback – updated intention/realisation. If your working environment and resources allow for it, keep all of your interim prototypes, and make them publicly available in an online repository. This enables scholars to build on your work in the future.

    Meaning comes from difference

    Enhance the affordances for understanding the nature of any entity by putting it in context with another.

    Context It is hard to perceive qualities of something familiar. To enable yourself and others to perceive that thing from a broader vantage point, put it in context with something that is different in a significant way, i.e. to notice qualities of a mobile app prototype give it to someone other than yourself to try out OR compare it to the prototype that preceded it OR compare it to a competing, similar app.

    Intentions as arbitrator:

    Prioritise the solution that is most in line with your design intentions when you are faced with more than one way to solve a design problem.

    Context There are many ways to solve any design problem. If you have flexibility in how you distribute your resources (time, materials, tools, financial cost, effort cost), prioritise the solution that keeps you in line with your design intentions. Good design self-reinforces its rhetorics through internal consistency. Internal consistency emerges over the duration of the design process and across design iterations.

    Writing for Peer-Reviewed Publications

    Make your theory lift:

    Explain the theoretical framework enough to motivate the methodology and provide context for your contributions.

    Context RtD is often applied in interdisciplinary research settings, resulting in projects with specific epistemologies / theoretical frameworks, and as a result, bespoke methodologies. An impoverished presentation of the theoretical framework will confuse the reader by not giving them enough insight to engage critically with what you did and why. In fact, if you can drop your explanation of your theoretical framework without affecting the flow of your argument, are you using the theory for anything substantive? In which case, do you need to reconsider your theoretical framework?

    Clarify context

    Clearly articulate timeframes, environments, sources of funding, power structures, and academic contexts in which work was undertaken.

    Context Without context, there is no design. Without specifying context, your audience will not have an understanding of how similar / dissimilar / relevant / irrelevant your design practice and research is. At best, your design research claims will be inaccurate. At worst, they will be fraudulent. In all cases, the integrity of your work has been compromised.

    Clarify positionality:

    Author a block that clarifies how your identity connects to and informs your RtD practice.

    Context To maximise the chances that your readers will trust your work and findings, provide them with insights into who you are and reasons why you have sufficient expertise and lived experience to effectively tackle your research questions. Not all scholars come to RtD with the same amount of design experience. If you are experienced in the specific area of design practice, declare this in your writing (ideally including links to publicly accessible previous work you have completed). Your design experience and history evidence your design problem solving ability.
           Feeling shy due to a lack of track record? Remember that track records build up over time only if you keep producing work and tracking it.

    Method in 1080p:

    Describe your RtD method in high enough resolution that a reader would have a decent chance of recreating it.

    Context Descriptions of method in RtD are often minimal, mirroring the sparsity of language used to describe scientific experimental conditions. Picture your favourite movie in 640 x 480. It’s disappointing, right? Luckily, RtD is not science2. If design privileges doing, then method is the logic that binds the doing. A rich description of your method3 not only respects the work you invested in establishing that method, it helps your readers follow your lines of design reasoning and activity. A rich description also facilitates other scholars in building on your work.

    Description ≠ reflection:

    Explain your design process using description and reflection.

    Context If description in design is a capturing of “what happened”, reflection in design is “what it meant, why it was meaningful, and what it triggered”. Description can exist without reflection; reflection cannot exist without description. Reflection is most likely where your design insights are to be found: after all, they are your attempt to articulate your design reasoning. Note that if you find yourself engaging in a design reasoning path that involves your previous experience or expertise, you are invoking reflection.

    E before C:

    Use evidence to power your claims (and not vice versa). Evidence may concern: context, process, materials, designerly reasoning, feedback from others, approaches to data interpretation, and paths between iterations.

    Context Design research should be able to assert its own goodness / value in terms of its own standards. Creative work does not need statistics to express its qualities unless a statistical argument would be relevant to the epistemological orientation of the encompassing research agenda.
           Note that temporal aspects of evidence make a difference: the narratives we produce at the end are not what we produced at the beginning, and the path/displacement between the narratives at the beginning and end will reveal a lot about designerly reasoning and problem solving.
           About design evidence: quantity does not necessarily entail quality. If you write, “4 games were produced from framework Z”, I will think to myself, “but a good designer should be able to produce work based off of any framework”. Evidence is always more trustworthy if it has been contextualised. If in the same piece of writing, I learn that the 4 games were produced by inexperienced designers, but that framework Z was robust enough to scaffold their making, then “4 games were produced from framework Z” becomes significantly more compelling as evidence in favour of Z.

    Clothe your claims in evidence4

    Ensure claims you make in relation to the contributions your work is claiming are supported by chains of evidence and reasoning present in the same “bundle”.

    Context RtD researchers often make claims in publications that are under-supported in terms of presented evidence (which may well be true - if only the evidence were there!) Contributions are what your publication presents and argues, on the strength of your supporting evidence. Do not make a claim that extends beyond what your contribution reasonably declares. Do ensure your claims are backed by evidence you have presented (and that can ideally be verified by readers).
           Keep in mind practical considerations around paper length, with regards to how much you can argue / demonstrate / prove in any single publication. Check the length limits for the publication venue you have in mind, and scale the contribution you wish to make based on the page real estate you have available (i.e. don’t attempt to compress your PhD findings into a short paper with an upper limit of 4 pages. Conspicuous wastage of your hard work!) Establish a publication strategy such that paper A → paper B (cites A) → paper C (cites A & B).

    Share your failures:

    Share solutions that you tried that did not work, especially if those failures led you to explore more promising directions.

    Context In most academic publications, scholars tend not to dwell on their failures5. In design research, this is problematic if omission of failure trajectories produces an incomplete rendering of how “successful” design activity took place. Yes, it’s embarrassing to fail, but it’s real – and in design epistemology, real transcends true.
           Also, if we all did this, it would be less embarrassing. Just sayin’.

    Be the change:

    Put written works out there that you personally would be excited / interested / grateful to encounter.

    Context We should all read more: agreed. But in our collective defense, when was the last time you read peer-reviewed design research literature that was not a chore to read and was rhetorically well-crafted (i.e. logically sound and elegant, made you care, enabled you to know and respect the author?) Due to the disciplinary standards inherited from everywhere other than design, many of us get trapped into believing that the formula for an authoritative academic written tone is DESCRIBE MY WORK IN THE DRIEST WAY POSSIBLE.

           Enough6. Our work deserves more than that.

           If you want there to be more academic work out there that moves you, you need to put that kind of written work out there yourself. Only write work you want to read. Only write in a way that balances “AUTHORITY” / I am my audience / other people would want to be my audience. The more we signal that this type of writing has value, the more welcome other scholars will feel in terms of following suit. Like attracts like.

    Reading is UX:

    Once you have a completed first draft, edit it with usability heuristics in mind.

    Context Implicit in the written standards specific to each academic discipline are the values they hold dear. Papers in medical journals demonstrate a disciplinary commitment to scientific objectivity and experimental rigour, not only in terms of their methods and subject matter, but also in their written style – distanced, neutral, and mostly devoid of subjective detail. Contrast publications from journals on critical race theory: these reflect authorly commitments to standpoint epistemology and the disciplinary valuing of storytelling as a means of conveying experience – markedly different from what is commonly found in writings from medical science. Academic writing about design likewise ought to reflect a commitment to widely accepted values of design, especially ones concerning learnability, efficiency, and transparency. Jakob Nielsen’s usability heuristics may have been derived from analyses of commonly recurring issues in software, but arguably all are applicable to the context of effective communication. We suggest focusing on these guidelines at a minimum:

    1. Visibility of System Status: The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.
    2. Match Between the System and the Real World. The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.
    3. Consistency and Standards: Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.
    4. Recognition Rather than Recall: Minimize the user's memory load by making elements, actions, and options visible

    Footnotes

    1. Yes. As meals will interrupt your day flow. ↩

    2. If it were it would be RtS – Research through Science. RtS is the disciplinary home of the famously contentious conundrum, how long is a piece of string? ↩

    3. Neither adjectives nor adverbs are dangerous in design research, and your readers will absolutely suspect that you did it, so write in a hi-res, first person (singular or plural) active voice 🦾 ↩

    4. Evidence which is constituted from real material as opposed to the Emperor’s New Materials. ↩

    5. Perhaps for fear that it will undermine their competence. Hot tip: nobody cares. Be free! ↩

    6. My commitment from 2025 onwards: I shall not engage in writing destined for peer-reviewed publication that I would not want to read myself. Join me if you like. ↩