Within this section I highlight development points throughout my Master's (past and present), linking to the Areas of Expertise. Within the text, I refer to projects and courses. By clicking on these words, you are taken to the specific page of the project or course.
Context oriented (U&S)
When I started my master's, my design process was already strongly user- and context-oriented. This was something I wanted to deepen, as such understanding allows me to become sensitive to an environment and to empathize with a user's needs. M11 Shellcraft and UME gave me a wider understanding of what a context can be. As both were material-driven projects set in a non-human context, they taught me how to look beyond the perspective of the user. For example, I learned to use autoethnography by writing down reflections and engaging with the material frequently. Simply exposing myself to the context produced relevant insights and during M11 Shellcraft it even steered the whole project. There, we shifted from finding an implementation for an eggshell material to creating a performative exhibition that shows the effort a chicken puts into creating an egg.
During my M11, I had defined music as a context across my other projects. My reason for this was to work with a context close to me and to build up my sensitivity to it over a longer period. Within M12, however, I noticed a slight disconnect with my user, as I could not empathize as well with composers. This meant my prior experience as a musician did not serve me as strongly as I had hoped, and left me less confident in my decisions. In M21 and the FMP, I brought this connection closer by focusing more on music from a player's point of view.
System design (M,D&C)
In my work before the master's, I created interactive prototypes within a single software environment, mostly using Arduino code. These prototypes were interactive, but operated within a closed loop of input and output, which limited the complexity of interaction I could achieve. To move beyond this, I spent the start of my master's building a broader overview of the software available to me within my context of music design (M11 and SOST). 
In a musical context, instant responsiveness is essential to couple interaction with sound, which makes latency one of the main challenges when prototyping with music. During M12, I developed a clearer understanding of this problem and made sure to keep processes separate: Arduino handled the electronics, Python the computation, Ableton the playback, and Max MSP the sound modification. In M21, I used this systemic understanding to develop more complex interactions, and during my FMP I built on it further by creating real-time responsive interactions. As a result, the prototype was not only experienceable but also implementable.
Becoming an independent system designer (M,D&C) 
Setting up the system described above required me to understand how these systems actually work, and at first I relied heavily on experts: Kamil Musial for code and system development, and Francesco Di Maggio for coding with sound. Early on (M11), I depended on them for validation and technical support, but their teaching gradually helped me establish a more independent and systemic way of coding. They remained closely involved during M12, but by M21 and my FMP their role had shifted. Rather than hands-on support, I turned to them mainly for brainstorming or occasional questions. This progression gave me real independence and put me in control of the system and its workflow.
AI played a key part in that shift. Instead of writing code line by line, I developed more of a coder's perspective. The experts taught me to recognize the steps and phases involved in building such a system and how to use AI effectively within it. The principle throughout was to stay in control of the system and genuinely understand it. To keep on top of the workflow, I wrote debugging code and built in a constant stream of feedback so I could identify issues quickly.
Sound prototyping (T&R)
As mentioned in the previous sections, I began my master's by building skills in sound design (M11, SOST), set on exploring sound and music as a design context for the projects to come. This first focus was mainly digital, centered on software and coding in tools like Max MSP and Ableton. Because my ultimate aim was to create tangible interactions, I then expanded these skills by physicalizing the digital setup: in M12, my physical prototype acted as a MIDI controller connected to Ableton. To achieve greater complexity and make better use of the connectivity between programs, I worked on strengthening the flow within the system. During M21, I used this digital system to translate an analysis of the music into a physical interpretation through an elastic band. Finally, during my FMP, I brought the user into the system by making interaction a central contributor to the workflow.
Creating refined prototypes (T&R, C&A)
Throughout my master's, I increasingly focused on fine-tuning my models and physical results. Because I aim for designs with implementation potential, a high-quality finish is essential where users should experience a prototype as if it were a finished product. To achieve this, I began embedding the electronics further into the design.
During M12, which involved a large amount of electronics that took up considerable space, I used a prototyping board to solder the wiring together, saving space while keeping the prototype functional. Here, my focus was mainly on hiding the electronics and making them work. In work without electronics involved like CADAI, UME and CDR, I developed how to focus on form rather than function. The IoT course expanded on this, as I created a product that integrated form, function and interaction. This approach I could apply more effectively in later projects such as M21 and FMP. During my FMP, I developed these skills further through stronger form-giving, achieving a more complete aesthetic.
Music as data (M,D&C)
Within my making process, I see music as data. The course CADAI taught me how data can be used creatively in interaction design, and I applied this from my M11 project onward. In M11 and M12, I treated music as a binary parameter, where in M12 a physical token represented a recording saved on the device. Here the physical interaction was the added value, since the recording could also have been made digitally in existing software. For that project this was fitting, as my aim was to research the physical translation itself, but in later projects I wanted to make this physicalization of data more novel and complex.
During M21, I explored the parameters within a musical piece, translating them into harmonic tension and then condensing that more complex framework into a single linear movement using the elastic band. A limitation here was the lack of feedback to the user about how the movement and the data were connected. I addressed this in my FMP, where the platform's movement was driven by parameters displayed by the prototype itself. Lights made both the input and the data visible, explaining why the platform moved as it did. This gave the prototype far more transparency, and, most importantly, helped the user understand how the movement was created. That understanding is crucial for users to contribute. By playing along, they need to grasp the system, which in turn adds further layers to the interaction.
Design process
The Reflective Transformative Design Process (RTDP) helped me combine different modes of ideating. Five activities sit at the center of this process and can be revisited or repeated in any order. This makes the process open-ended and shaped by the designer and the specific societal context, with reflection guiding the move from one activity to the next. When I first used it during the M11 project, the RTDP gave the team a shared overview. By reflecting often on our next steps, we made sure we were all working toward the same goal.
During M21 and my FMP, I began to make the RTDP more personal and noticed recurring paths that did not always need reflection anymore before I chose the next activity. After analyzing, for instance, I would often move straight into making. I realized that making is, for me, a way of making sense of the large amount of information I tend to gather. Whether from analysing my own material or reviewing academic work, the act of making gives me clarity on that information and shows me how it can be translated into the design.
Finding creativity during the design process (C&A)
This sense-making through making is a large part of how I ideate and spark creativity. Throughout the master's, I learned to find creativity through several different routes. The SOST course made me aware of how to prototype with sound and music and to approach it more creatively. In Max MSP, for example, the visual structure of the software allows for a more intuitive process. The IoT course taught me to think metaphorically, linking theory to interaction which is something I drew on in my FMP to simplify and physicalize harmonic tension and get a sense of how it could translate into interaction. During M21 and my FMP, I also learned that, within the context of music education, I can ideate by visualizing content. I did this by analyzing music theory and looking for patterns, drawing on top of chord sheets (FMP) or sketching intuitively to interpret what I heard (M21).
Expert involvement (U&S)
In my projects, I greatly value the involvement of experts, as they offer a different perspective on the user, and current context. Usually, I involve experts to deepen my understanding of that context. During my FMP, however, they served a more direct purpose, tied to where I was in the design process at the time. For example, I discussed my analysis of a piece of music with a conservatory teacher, which broadened my view on how to approach such an analysis and how conservatory students are taught to do it. Because the analysis was something I was actively working on, I could steer the conversation toward something concrete and directly relevant to that stage of the process.
Implementation (B&E)
In order to get into contact with my context, I built a network of relevant stakeholders, using a variety of methods: drawing on my own existing network, approaching organizations directly, and attending conferences. As my context stayed similar in my last three projects (M12, M21 and FMP), I could build this network over a longer period, which made me able to involve experts from a very early point during my FMP. I employ an entrepreneurial attitude to stay in close contact with the context of my user. This is an attitude I already apply in service design outside of my studies, building startups such as Bandwerf, a platform that makes booking live music easier, and EHOOG, which records live sessions for bands.
This close contact with the user and their context also keeps me close to the application itself. The constant validation and engagement with the context steers how I design, so that the eventual application within that context does not come as a surprise. As a result, my FMP became a proof of concept through this close relationship with the context.
Back to Top