What I’ve Learned from Lunchtime Creative Writing Workshops

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.

Using an outline versus letting the characters drive the outline

Using a pre-decided outline for story versus letting characters drive the story

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.


Adobe RobohelpMadcap Flare

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

15 thoughts on “What I’ve Learned from Lunchtime Creative Writing Workshops

  1. Laura Winkelspecht

    Nice post. I’ve found that my creative writing has helped my technical writing and vise-versa. Even poetry, which I’ve been creatively focused on recently, helps with my technical writing. Word choice is really important in poetry and the same is true when you’re explaining complex information. As the same time, the details matter in technical writing and that has helped me to pay more attention to them in my creative writing.

  2. Vinish Garg

    Very intriguing correspondance between fiction writing and technical writing. I particularly liked how you mapped the *goal of characters in fiction, with goals of users in a manual*. Just as different goals of different characters complete a plot (or sub-plot), different goals of different users of a system can help us write more *relevant procedures*.

    As regards the patience and persistence, there is a difference.
    – In technical writing, the manual has to be shipped with a product because we are always doing it for a product (client). So there is a definite deadline and the scope to override is next to null.
    – In fiction, we invariably override whatever timeline we set for ourselves; when we have many cups of coffee (or puffs of smoke) while staring out of the window.

    1. Tom Johnson

      I love the image of drinking many cups of coffee and blowing puffs of smoke while staring out the window. I think most believe that fiction consists mainly of that. Certainly that description has a ring of truth. But I think if we were to study techniques of successful writers, we’d find that many fiction writers do extensive research and even immerse themselves with their subject and characters. For example, in the Lonely Polygamist book I recently reviewed, the author spent time living with polygamist families to research their lifestyle and culture.

      Writing fiction is hard. It involves more than blowing puffs of smoke. I think many times technical writers romanticize fiction writers this way, when in reality there are many crossovers. The research one does in putting together user personas in technical writing is probably on par with an author’s research of his or her characters. Don’t you think?

      1. Vinish Garg

        I understand that *fiction writing* is hard. I only meant that the author is at far more liberty for *endless cups of coffee, or puffs of smoke*, in fiction writing, than in technical writing.

        I can also very well understand *fiction writers do extensive research and even immerse themselves with their subject and characters.*. I have gone through that many years back, when my first fiction was published in 2006. :)

  3. Oana

    Wow! I would have never throught of such comparison between fiction writing and technical writing. Although the comparison makes sense, I must agree to Vinish regarding patience and persistence.
    In tech writing you have to meet the deadline otherwise the consequences would more drastic than exceeding the deadline for a novel or book.

  4. Laura Mahalel

    The difficulty of just sitting down to write and seeing a project through to completion reminds me of a friend’s idea to write a book called “How to complete your dissertaion in just 15 minutes a day”. The basic idea is that if you really do work on your thesis for (at least, but no less than) 15 minutes a day, you’ll get there. :)

  5. Laura Mahalel

    Oh and this to file randomly under “plot”.
    A friend recently got into a conversation on the bus with a woman and somehow ended up talking about me, her friend the technical writer.
    The other woman’s eyes grew wide and her tone turned conspirational.
    “Technical writer? You know that’s a code word for SECRET AGENT!”

    I couldn’t wait to share this with you in my tech writing community.

  6. Tom

    You said that the main reason why most people don’t publish a book,is because they don’t finish it. That is a good point! The conclusion ia the hardest part of technical writging. It´s like painting, i never know when i´m finished.

  7. NoveltyHoliday

    Another way the style of Fiction can supplement that of Tech Writing is in examples. Although real world, hands-on examples are useful, the fact of the matter is, most times the writer is creating hypothetical situations, based on research, in order to help the audience conceptualize a key point.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>