Clay Spinuzzi, University of Texas at Austin
So far, our analytical models have allowed us to examine our research sites at three different levels (Table 1).
Table 1. Analytical models, time scale, and disturbances.
But these three levels really aren't separate. All those second-by-second operations at the micro scale make up the minutes and hours at the meso level and the longer cycles of work at the macro level. The disturbances at each level are connected. But how do we make the case for those connections? How do we triangulate across levels of scope?
Looking at the individual levels, we might find it hard to make connections. But pulling the different disturbances into a single table helps us to make these connections more easily, letting us name the different issues that our participants face. CDB tables represent findings in our research, findings that point the way to recommendations.
For instance, in Tracing Genres through Organizations Ch.5, you can see some CDB tables in which contradictions, discoordinations, and breakdowns have been related, showing how they are all part of the same problem: representations from two different activities simply don't mesh for the participants, and participants consequently have to spend a lot of time bridging between them.
If you were to write a Findings section based on these tables, each table would represent a different finding. Let's use these tables as examples for developing our own.
To develop CDBs, you first need to list disruptions (contradictions, discoordinations, and breakdowns) from each model. Once you do that, you'll start to see congruences among them. For instance, in TGTO Ch. 5, I saw discoordinations and breakdowns clustering around certain texts, and I saw with my ASDs that these texts came from different source activities.
To nail down the issue, I developed CDBs that pulled in disruptions from each model, making sure that I could point to evidence for each disruption.
You'll do the same thing. For instance, if one finding is that two different texts are incompatible, you might
You might come up with something like Table 2.
Table 2. A CDB based on the scenario above.
As you go through your CDB table, you may find disruptions that don't quite fit. That's fine: They may belong in a different CDB table, representing another cluster of issues.
Once you develop a CDB table and confirm that it works at all levels, describe the issue with a summary phrase. This summary phrase is your finding.
For instance, the summary phrase for the table above could be something like "Participants have trouble relating dialog boxes and forms." It's a simple claim, but one that you can back up with several pieces of related evidence working at different levels.
This last step seems simple, but it's crucial to get it right. Use a phrase that can describe your CDB at all levels. This phrase is the main takeaway that readers will absorb for this point, and it's also the basis for a corresponding recommendation. So don't oversimplify.