I have been involved with technical writing for almost ten years, both as an external consultant and as internal staff. I completely agree with the idea that change is the only constant in this field: where Microsoft products were the tool of choice, now we also have Google applications; where we used to work on a document one person at a time and email it back and forth (heaven help you if a file size was too big to fit in an email and your collaborator was off-site), now we have cloud storage and library repositories that can store documents and track version history; and where we used to chase people through buildings to collect signatures, now we have DocuSign.
Throughout it all, though, I’m not sure I ever heard the phrase “heuristic.” Yes, I had general frameworks for how to approach a project, or previous projects I could use as a baseline template, but there was not a formal name for it. As described in the introduction to “Solving Problems in Technical Communication,” every project I’ve worked on has been different. With each project, solutions were chosen based on previous projects and successes, and then each solution would be adjusted to fit the new project. We were identifying tendencies and commonalities and using those as a jumping-off point for the new project.
The detailed description given of the four phases – Mapping the Field, Situating the Field, Understanding the Field Approaches, and Developing Field Knowledge – was very interesting. I think most technical communicators, sometimes unintentionally, go through some or all of these phases with every project they tackle. My peers and I did not follow a true heuristic approach, probably because we were not familiar with that phrase. There was no second level of analysis; we just moved on from one project to the next and repeated the process of identifying and utilizing a previous solution that best matched the current project. There was no retroactive assessment of the problem and its solution, no identifying what worked well and what failed. It seems like such a basic concept to evaluate a completed project and I’m a little embarrassed to say we never did. As they say, hindsight is 20-20.
As the text points out: “technical communication problems are – at their core – ill-structured, complex, and messy, defying easy or pat solutions.” I completely agree with that assessment. Each project, or problem, has its own set of parameters, metrics, and rubrics for success, and each project may have its own audience or stakeholders which require unique handling. Because each problem is so different, I definitely see the value of utilizing all four phases of a heuristic to continuously refine the approach to communication.
The first two phases focus on context. Mapping the Field asks problem-specific questions and Situating the Field asks broader questions. The text states it does not matter which of these phases occurs first, which is good. I cannot remember an instance where I asked broad, general questions after asking for specific details; I think my default is to situate the field first and map the field secondly.
In technical communication, the broader questions are the first things I look for: what type of document will be required, have I done something similar that can be used as a template, and who are my stakeholders? Then I ask the specific questions: what are the formatting requirements, and does the delivery method impact the tools available to create the document?
When I step back and think of technical communication as a field, I think it does make sense to map first and situate second. It makes sense that a “concrete snapshot” should be captured before moving on to consider or develop theories that may be applicable to that particular snapshot.
The third and fourth phase address the broad applications before moving to the specific applications, which fits better with what my instinct says: ask how we can do something and then ask what we need to do it. Much of the time when I ask these questions – again, unintentionally following these phases in a project – I am only asking to understand the practical application of them; I do not consider the theoretical application of them. I’m excited to see how this book encourages using the four phases of heuristics so that I better understand the rationale for each phase and how I can apply it my own technical communication projects.