About a month ago, one of my colleagues approached me and asked if I would be interested in having an informal creative writing workshop every now and then. Huh, I thought, maybe. I floated the idea by the other four writers in our technical writing group, and it turns out everyone was interested in participating in this, except one, who was already busy with another creative writing workshop that had even more participants.
We've met a couple of times, and the discussions are interesting. In the first workshop, we talked about letting characters drive the story, rather than the writer. In other words, you get inside your character's head and decide what he or she would do. The author shouldn't control the character's actions in manipulative way.
This technique -- letting characters drive the story, rather than the author -- poses some challenges in sketching out the overall plot. If you have your entire plot mapped out, it's unlikely that you've been letting characters drive the story. Often it's not until you begin writing that you get a better sense of what the character would do or think. Actions and emotions inside a character's head may be at odds with a detailed plot outline.
As a compromise, we decided it's good to have a general idea of where you're going, but to work out the specifics and details along with the way. Another writer said that there are as many techniques for plot as there are writers. Some writers make a detailed outline of every twist and turn of the plot from the beginning; others don't have any plot at all -- they can just work from a general idea.
I like the technique of having a general idea but not knowing the specifics, because the magic of writing is that it clarifies thought. Often when I start writing, I end up going in a different direction than my plan. I don't know exactly what I"m going to write until I write it.
Although it may not seem like it, approaches to technical writing should be much the same way. We should get inside our users' heads and let them drive the topics we create, rather than driving those topics from a set of features within the application itself. The better we understand our users, the more that understanding will inform what we write.
In our second workshop, we talked about goals. My submission was up for critique during this workshop, and one of the writers asked what my main character's goal was. I hadn't thought what her "goal" was, but it was a poignant question that got me thinking. Another writer added that it's interesting when an external goal forced upon the character differs from the goal the character wants. And it's more interesting when that external goal has merit, when it's not just a ridiculous goal forced upon the character but really has reason.
Again, the similarity to technical writing is there as well. Our users have goals, and we need to understand these goals from the start. Without a clear idea of our users' goals, our help file will lack relevance in the same way fiction stories lack plot.
In this same workshop, one of the writers asked if how-to books on writing are helpful. Apparently this writer has 25 books on writing, and their main effect, he confessed, was that they motivated him to write, not that they taught him how. He mentioned that John Irving was in a writing workshop with Kurt Vonnegut one time when Vonnegut said he hadn't ever taken a class or read any how-to books on writing. Many people think writing workshops and how-to books can even be damaging to your writing. This is an interesting paradox -- to think that all the instruction might only worsen your ability to write.
The main reason why most people don't publish a book, my colleague said, is because they don't finish it. And it's true -- this is probably the most difficult part of writing, just sustaining the effort with constant motivation. It's easy to knock out a short story now and then, but a novel can take months or years. How do you carve out a time from your life to work on such a project, which might never be published, which might never yield financial rewards, and which might only frustrate you in the end? Writing requires a lot of time and mental energy, and there's no guarantee that your efforts will result in anything profitable.
Again, are there parallels to technical writing here? How many times have you struggled to maintain momentum in writing a gargantuan help file. Writing help content can be tedious and dry. It's easier to get distracted into other tasks. Reading how-to books can help rejuvenate our momentum.
I know this is a blog about technical writing, not fiction, but I have a hunch that technical writers could borrow a lot of fiction techniques to supplement their technical writing efforts. Establishing the parallels and building on common techniques might be one way to convert the tedium of technical writing into a more engaging writing experience.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.