In a previous blogpost I demonstrated some methods for mapping social relations as well as emotions/liked-and-less-liked-parts-of-a-process. In this blogpost, I will show some ideas on documenting the processes with your participants by writing step-by-step instructions together.
Here is what I came up with:
Step 1: List tasks
First we need an overview of what the participant does. It would be ideal to collect these activities³ together with the participant by observing him/her, however this is not always possible and even if we, lets say, would do a few hours of observation, we still might miss important activities (like the setup when starting work or the cleanup routine when ending it).
My first ideas was to ask what the participant does and to write it down with the participant.
However, this was a bit too general in my eyes. To make it more concrete, I asked for things that the participant was doing just now and some minutes ago, too. This makes it somehow more reliable since it is likely that recent activities are remembered. In addition, these remembered recent activities have actually been done in (possible) contrast to activities in general which may be written down because they should have been done.
To ease this for me, I created a little template:
You see that there is a second column, asking for “effects if the activity in not done”. This can help to focus on the (seemingly) most relevant activities first.
Before creating the list, I show an example how the result may look like. The example is concerned with a very different domain (to avoid biasing the participant), so people working in a cafe got a »How I repair a computer«-Example from someone who volunteers in a hackerspace repairing computers (hmm, that someone is me).
Step 2: Describing the activity(s)
After having an overview of activities I choose the one that appears most relevant and ask the participant to document this activity with me. I frame it as possible instructions which could be used to teach somebody else the activity. I show an example for this too.
I provide a template, with an »activity name« and a »notes/sketches« column, and fields for basic infos like the name of the activity, the trigger, the result, the risks/problems and the motivations to do the activity.
When documenting the process, the participants only write down the general steps (I hoped they would include some sketches, hints etc. too). After they are satisfied I go through their list and ask questions:
You wrote “Distributing team work” – how do you do this?
This point “Let the milk cool down” – what happens if you skip this?
In addition, I may ask for a demonstration:
Can you show me that coffee-container-thingy you need to clean?
…How is that thing attached to the coffee machine?
I add the information I asked for as notes and sketches, either in another color or by creating references to another note sheet using (latin) numbers.
The latin numbers link to tasks the participant wrote on the template sheet. We ran out of space, so we used another sheet.
At the end we created a documentation of the work process on one or two pages.
The data is mainly written text (as opposed to audio or video or researcher’s memories) so there is no transcription required. However, I strongly recommend to review your notes afterwards, add possibly forgotten data from your memory and to rewrite hard-to-read words so that the document is useful at some future point.
I still think that a interview/observation gives more opportunities for experienced researchers. However, the method described above may provide beginners with some structure and still leaves room for own questions and ideas. A motivational advantage might be that an actual artifact is created (the sheet of paper on which the process is documented) instead of just having collected “more data”.
Old: Both in German. Write me a comment, if you need a template in
Old: Linked templates are now in English.
- Tudor, Leslie Gayle, et al. "A participatory design technique for high-level task analysis, critique, and redesign: The CARD method." Proceedings of the Human Factors and Ergonomics Society Annual Meeting. Vol. 37. No. 4. SAGE Publications, 1993.
- Herrmann, Thomas, et al. "Semistructured models are surprisingly useful for user-centered design." Designing Cooperative Systems (Coop 2000) (2000): 159-174.
- »Activity« is used here like in everyday language, it does (most likely) not exactly match the definition of an »activity« inactivity theory
Text and images are licensed under a Creative Commons BY 4.0 License