Oud de Phenomenology

Albeit the name may seem a bit unconventional, this is the second part in the series “Motvational Design in music production”, and this is an oude for phenomenology. At this point you are thinking something like: “Oouud de pheno-me-no-what?”, which is also the only reasonable response.

Citing Stanford Encyclopedia of Philosophy, Phenomenology refers to the study of structures of consciousness as experienced from the first-person point of view.

Your reaction should still be something like as stated above. However, in this particular article I will approach phenomenology as a methodology used in carrying out analysis on phenomena during qualitative research. E.g. As a phenomenological way of viewing reality – or the matter at hand that is studied. I will approach phenomenology as the notion of studying phenomenons in and out from themselves, by using so-called “bracketing”. In essence: Setting aside any preconceived notions of a studied subject matter, when studying it.

Why?

Because the whole point of proper qualitative research is to find out why something is – not to affirm what is already known.

In my qualitative study on facilitators and barriers of motivation in music production, my presumption was that motivation in creating could be manipulated via some technological implementation. However, phenomenology forced me to push aside any preconceived notions, and to study the phenomenon for what it is.

Phenomenology helped me find insights I wouldn’t have found, had I used an approach to affirm preconceived notions.

Who are those that affirm preconceived notions?

I don’t think anyone who wants to find out about something settles with reaffirming preconceived notions on purpose. Rather I believe, reaffirming preconceived notions is only the effect of lackluster methodology. To my experience, when someone (including myself) refers to coding transcripts of interviews, they usually refer to either descriptive coding or some sort of interpretative coding, without acknowledging what the process to coding is, other than just coding the material. Let’s call this arbitrary coding.

Arbitrary coding is by no means an implausible way of coding – I use this method almost exclusively when I code interviews professionally. But I am aware of the fallacy, and I am aware of my bias; coding things belonging to my preconception as more important than they are, simply because the process isn’t rigorous enough to filter them out. Fuck the system, right?

I'm sold, how did you do it?

By coding in multiple cycles, with the intent to highlight anything that conveyed meaning, without drawing any preconceived notions to whether it was relevant to motivation.

Here follows a brief description of each cycle:

First cycle coding

The intent of the first cycle coding was to find meaning, and as such, I attempted to code everything that was meaningful, which was categorized on subject matter.

Second cycle coding

In the second cycle, codes from the first coding cycle were re-coded into descriptive codes, process codes, and concept codes. E.g. finding descriptive patterns/themes in the transcription, interpreted processes, and interpreted concepts.

Second.5 cycle coding

In a later stage of the second cycle coding I employed a practice called magnitude coding. Which is a sub-coding process that codes to which magnitude – positive, neutral or negative that a code impacts something. In this case, how the descriptive codes, concepts and processes impacted motivation.

Third cycle coding

To make the final prioritization, the user pain points and needs were combined with the administrator pain points, and finally weighed towards the number of occurrences. Which yielded the following design goals:

Theming

The codes were then quantified, where only the most prominent codes rose to become emergent themes. The themes, which included the most prominent codes were then presented as results of the study.

Conclusion

This method is not without its fallacies. Even coding where an attempt is made to reduce bias, do inevitably include bias. Coding in multiple cycles like this, may result in data loss, and some codes may even be attributed to motivation, although motivation may not be the root cause of behavior.

However, knowledge has to start somewhere, and no matter what we do, methodologies will always be tainted. It is however up to the researcher to reduce the tainted-ness to a reasonable level. Taking a phenomenological approach into multiple cycle coding is one approach to do just that.

Did I leave something out?

That is probably on purpose. I try to keep things brief around here. Lucky for us, you can find my entire thesis on this link:

Facilitators and barriers to motivation in music production: Discovering opportunities for product companies to support motivation in music production

And if you want to stay up-to-date with my upcoming articles on the subject, subscribe to my newsletter, “Tuna Post” here:

Tuna Post

Subscribe to the Tuna Post to get my bi-weekly update of cool stuff, original articles, and music.