"Oh yeah, I stuck some codes on some text - by which I mean we did grounded theory."
"We used a grounded theory approach, and here's a classification model."
"What statistical analysis have you done to confirm your results?"
Hi, I'm Tom Cole, and this video presentation is on Grounded Theory: what it is, how it's been misunderstood, and what it can offer HCI.
This paper was born out of an ongoing frustration with how Grounded Theory seems to be viewed and discussed by many within HCI.
Both in reviews of my work and in several informal discussions, again and again I come up against serious misunderstandings of what grounded theory methodology is,
where it comes from, how it should be used, and it's potential for making great contributions to the field of HCI.
In this presentation, I'll focus on what grounded theory methodology is, and some of the
major errors that I've seen in papers where people *claim* to have used grounded theory.
So let's get stuck in.
Grounded Theory Methodology is an exploratory qualitative methodology for generating novel theory from empirical data.
The result is a theory, that is 'grounded' in the data that you have collected and analysed.
It's a methodology that was originally developed with the social and healths sciences by
Barney Glaser and Anselm Strauss in the late 1960s.
It's really powerful for coming up with new angles on well-examined fields,
but it's particularly beneficial for new areas of academia where there isn't much research done yet.
In a way, it's a rigorous methodical way to metaphorically march your way into an area where little work has been done,
plant your flag and stake out some territory.
It's got a hell of a lot to offer HCI, bit it's often misunderstood.
Many tend to regard grounded theory as more-or-less a singularly agreed upon method,
but this isn't true at all.
There's about 50 years worth of VERY heated debate behind all this.
Broadly speaking, there are three main schools in grounded theory.
Glaserian or Classic, Straussian, and Constructivist.
For more details about the historical origins as well as the major differences between these three traditions, go and have a read of the
full paper. But *do* do that, because there *are* big differences.
Now, despite their differences, there are a number of common principles and tools that are shared between all three schools:
Production of a theory: This is what distiguishes grounded theory from other qualitative methodologies.
Whereas other methods produce a description or categorisation of the domain,
grounded theory produces...well...a theory which *explains* what's going on.
Simultaneous data collection and analysis.
In grounded theory you don't collect all your data and then analyse it like with other methods.
You collect a bit, analyse it, then go collect some more based on that early analysis, analyse that, repeat.
If you like you can think of it being a bit like AGILE development, but for theory instead of software.
Theoretical sampling.
You sample according to what's going to challenge, test and develop your evolving theory,
not according to a need to represent diversity amongst participants or data sources.
Memoing:
This is the act of writing down your developing theoretical ideas and inspirations as they come to you during the analysis.
This helps you track and develop your theory, gives space for reflection and forms the basis of write up at the end.
Constant comparison:
This is ongoing comparison of new codes against old codes, memos against codes,
memos against memos, everything with everything really.
A lot of cross-referencing, all the time.
Theoretical sensitivity:
This is keeping an open-mind to what's happening within a set of data.
It's constantly asking yourself, "What is the data trying to tell me?".
Theoretical saturation:
You will always collect new data. There will always be something 'new' that's being collected.
But is that data adding anything or challenging your theory in any significant way?
If it's not, then you've achieved saturation, and this is where you stop your analysis and begin write up.
There's a few more which are important which we describe in our paper,
but these are the ones that are more characteristic of Grounded Theory.
Now, the title alludes to the fact that Grounded Theory is rather more than just a bit of coding,
and I hope I've helped make it clear that there really is rather more to Grounded Theory than people often realise,
and it isn't actually just a case of pick and mix the bits you like and leave the rest.
There are some errors that I've encountered more frequently than others in articles that claim to use Grounded Theory :
Lack of theory:
Not to be facetious, but the clue is in the title, and if you don't have an explanatory theory as the result of your analysis it's not
Grounded Theory.
Overly detailed theory:
A grounded theory should be simple, easy to grasp.
If it's got too much detail, it's more a description
rather than a theory and will have it's power diluted.
Just doing some coding:
Just because you've done some coding doesn't mean you've used grounded theory,
anymore than mixing sodium bicarb and vinegar at home and watched it fizz means you've 'done science'.
Besides, lots of qualitative methods use coding - it's hardly specific to grounded theory.
Top down approach:
The whole point of grounded theory is that original theory develops organically from the analysis.
If you began with a pre-determined set of codes or ideas which you wanted to prove,
then it isn't grounded theory, and this isn't the right method for you.
Separate data collection and analysis phases,
as in collect all data first then analyse second.
You need to keep an open mind during the analysis.
The resulting theory could pivot drastically at times and look very different at the end from where you
*thought* you were going say, half-way through.
You can't be reactive and keep an open-mind if you've gathered all your data already,
and you can't do theoretical sampling or saturation unless your analysis and data collection is interleaved with each other.
Not using theoretical sampling:
related to the last point, you're sampling to improve, test and flesh-out your developing theory.
Now, this doesn't mean that work is bad -
just that it hasn't implemented grounded theory fully, and that's a problem.
Either do it properly, or don't say it's grounded theory.
Either is fine.
Now, grounded theory is very flexible and reactive, and no two projects will look the same.
But if you're wondering how this all might look in practice, then there's an outline for what a
grounded theory project might look like in the full paper.
I realise some may find this all rather opinionated.
Ah well, sorry about that.
But I hope for some of you that this presentation has whetted your appetite to explore Grounded Theory further.
Also, I hope it's convinced you that, if it's worth doing,
is worth doing *well* in order to yield its full potential, and that it really
does have a lot to offer the field of HCI.