According to Kindle Author, Craig Stone was a promising young novelist who, at 23, had some book deals and appeared to be on the brink of becoming the next big writer when, for whatever reason, the book deals fell through. Facing financial difficulty, he took up a job at a well-known company and lived the office life until one day he snapped. He writes,
I quit my decent job in the city working for a pretty famous company, left my home and walked away from all I had and went with a sleeping bag and a bag full of clothes to be homeless and live in a park.
I was miserable in my job and all I wanted to do was write; my philosophy being that maybe we all over-think our fears and undersell our dreams. So I simplified. I took a leap of faith and walked into the park armed with an A4 pad, a pen and no idea what tomorrow would bring. (See Kindle Author Interview: Craig Stone)
He started living in the park and planned to write about his experiences there, but as nothing eventful happened, his imagination took over and he eventually wrote The Squirrel That Dreamt of Madness.
I haven't read his book, but I like the story of the would-be writer giving up his office cubicle life to pursue his writing dreams. I don't know what sort of corporate job he had (it was for "a pretty famous company," he said), so let me fill in the blanks with my own imagination. He might have been a technical writer working for EMC or IBM. He might have been documenting some miserable API, or writing instructions on how to install and configure some boring system that he himself would never actually use. He might not have been in a situation too unlike many other technical writers out there, who started out their college educations with dreamy eyes and literary ambitions, only to be sucked into corporate life for financial sustainability.
I love the story of walking away from it all to pursue your dreams. While it's not something I'm planning to do, I am not entirely convinced that technical writing and fiction writing have to be so different from each other. Which brings me to the point of my post: the conference proposal I did not submit.
I wasn't going to submit a proposal to the STC Summit this year because nothing in particular motivated me -- except fiction. Then listening to my colleague's enthusiasm about his proposal (something about intellectual property rights), at the last minute I decided I would submit a proposal called "Using Literary Fiction Techniques in Technical Writing." The short description:
You wanted to be a great novelist, but you sold your soul and became a technical writer instead. Actually, technical writing is not so different from fiction writing. Fiction writers see the world through a perspective that is not their own. They get inside the heads of their characters [users] and explore their pain points and challenges [tasks]. Good technical writing does the same thing.
By literary fiction techniques, I'm not talking about incorporating dialogue into instructional procedures, or introducing character-driven scenarios into your how-to guides. I'm not talking about using flowery adjectives or elaborating with fictitious examples that go on and on.
While those could be fiction techniques, what I'm thinking about aligns more with simply getting inside your users' heads and exploring their challenges. If I have one main failure as a technical writer, it's that I'm not connected closely enough with my users. I don't understand them enough -- what they think, what they do, what pain points they have. I should find ways to immerse myself in their world, to walk around in their skin as much as possible. This is what good fiction writers do with their characters. They let their characters drive the plot forward (rather than manipulating the characters with the author's motives). And what really is the difference between a character and a user, especially if you've developed several personas from your user research?
Asked to describe his writing process, Craig Stone says,
I am a method writer that blends the now with the impossible. If I want to write about a subject I will go and live it. My books are one foot in the here and now and one foot on the back of a confused cow chewing grass wondering where that guy came from with the PC that he is trying to plug into its ear. Sorry cow, it's nothing personal—but I've got to plug it in somewhere.
He tries to live his characters' lives. He immerses himself in the scene and environment he wants to write about. Ted Conover, one of my favorite nonfiction writers, does the same thing. He's more of an ethnographer. To write an insider's view of a prison, he became a guard at Sing Sing. To write about the hobos, he spent a summer riding the trains with hobos. To write about the rich in Aspen, he spent a summer living and working among them.
To torture ourselves in a miserable existence as a technical writer, dreaming of the day when we might break free and write fiction, seems to me a bit of an illusion. The best technical/fiction writers immerse themselves in the minds of their users/characters. They get outside of themselves. This immersion is the starting point that makes your writing/manual more than a navel-gazing experience.
Once you immerse yourself among your users, the next step is to become familiar with your character's/user's goals and challenges. What does your user/character want to accomplish? What kinds of challenges stand in the way of the user? These then become the tasks that you write about. The end product may be vastly different, but the process of getting there is similar.
I ended up not submitting this proposal because, as much as I like the idea, it's too theoretical for me. I haven't immersed myself among my users, I haven't really worked with personas, and I certainly don't feel like I've managed to merge the technical and creative writing fields/genres. It would be a lofty goal to work towards, something I would hopefully solve by the time the conference rolled around.
Based on my past experience, that sort of experiment is the perfect formula for stress, because it presumes that all pieces of the puzzle will fall into place just when it's time to show the puzzle to the audience. It's much more practical to submit proposals on techniques and topics that I've already mastered and feel comfortable with (for example, quick reference guides). The only problem is, that's a bit boring to me. It's explanatory more than exploratory. It's like looking backward instead of looking forward. I'd much rather have a race that I'm preparing to run, one whose path I have never run.
I decided to put this as a goal to work toward this year, to find more ways to get inside my users' heads and let them drive the topics I write. Closing the gap with users would pose an enormous shift in my own efforts as a technical writer, and I'm guessing that the interaction and proximity to the characters will be just interesting enough to remove me from whatever factors contribute to the miserable corporate cubicle existence.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, 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.