Design

Why Developers Make Really Bad Tech Writers

~ Susan Kelley ~ 1 Comment

 

coding-future

Every now and then, I come across a blog post or other article or column declaring that technical writing for software development is a dying career, lamenting that all of us in the tech writing game should plan our exit strategies and admit that if a product is truly well-designed, our services are simply not needed.

Surely, in some product cases this is true. However, in many high-level software instances, I defy you to successfully install and run the product without some help from your friendly neighborhood tech writer. I pose this challenge because developers think and behave like developers and users think and behave like users. There is a chasm as wide as the English Channel between developer and user, and only the talented technical writer can provide transport safely across.

It’s not that developers are incapable of writing well or that they cannot write documentation, and it is not that users cannot ferret their way through intricate software. Developers could write supporting documentation – IF they weren’t developing that particular product. But alas, developers are too close to the products they are developing. They lack adequate perspective when it comes to their fledgling software, and they have great difficulty seeing it from a user’s point of view. The software, to a developer, makes sense. Developers arrive at a use-stance with some assumptions about functionality and behavior already in hand. So they make lousy content writers because they can’t see it from a user standpoint.

A shift needs to occur in order to artfully create usable content. A developer’s view is, “this is the product, and here are its amazing features,” whereas a technical writer will approach the very same thing from a perch saying, “here is how to do some amazing stuff with this new product.”

Technical writing shifts the focus to a user-centric view that is very difficult for a developer to take. It’s also no small thing that technical writers have been trying to master language, grammar and syntax for the better part of their educations. It’s a sure bet that developers have taken English courses as part of their college education. There are no programmers out there who are illiterate, don’t get me wrong. I work with some really smart people, no doubt about it! But when I tell them that all of our documentation is better perceived in active voice rather than passive, I tend to get a room filled with glassy-eyed folks who really want to get back to their work creating dynamic rules instead of determining whether or not they need a helping verb.

Technical writing in the software field is far from dying. What it IS doing is merging – tightly – with user interaction. It is absolutely, inarguably true that users wish they did not have to read so much in order to get started when they have a new product in their hands. So when we design documentation, we had better design it to work well. Lean documentation is essential – Strunk and White and their mantra “omit needless words” were not kidding.

Working with developers is an art. Letting them do what they do best, and making way for what writers do best, is a science.

I’ve argued more than once that mastering a given tool, like Dita or Framemaker, is fruitful but only if the situation calls for it. I have a totally separate set of tools that I use in my job, and they may or may not prove to be portable, but the skill that is 100% portable is that I can talk to, work with, communicate with, and understand – developers. I let them do their jobs with great enthusiasm, and I encourage them to let me do mine. It’s a synergy that keeps us all smiling, and pushing software out the door at a high rate of success. I work on UX, I design good doc, I focus on usability, I listen to my data.  I look at those sills that simply crackle with career stability. I let the developers tell me everything else that is important. And…I don’t make them write too much. Why? Because they don’t really enjoy it anyway.

And developers make really bad tech writers.

Advertisement

Want The Very Best in UX? Hire a Writer

~ Susan Kelley ~ Leave a comment

Saying that all technical systems, website creation teams, and indeed software development companies can benefit from a User Experience Designer is like saying that all human bodies can benefit from water. It’s a simple assertion. We all know it, and yet some development groups assume that they know what is best for their customers, or worse yet, they assume their customers know what they want.
What they (the companies, not the customers) do not realize is that the easiest way to enhance the user experience is to hire a good writer. UX design encompasses art, yes, but it must essentially encompass understanding. This seems intuitive, and yet when we look to engage a User Experience professional we do not always assume that he or she is a talented writer.
How do I know this? Well, I used to teach within a professional seminar for the MA in Human-Computer Interaction at a highly-respected university where they were grooming tomorrow’s User Interaction Designers before I took this primo job writing amazing documentation for this crazy-talented company cranking out top-notch software. Surprisingly, though, when I landed here, we did not have a UX guru on our team. I was a bit taken aback that we didn’t have someone like that on the job, but I figured I was new, so I didn’t make waves. Besides, I knew all on my own that really, if there is no art involved, you don’t need interactiondesign, you need interaction writing. So UX talent is not required – a trusted relationship with your writing team is.
I’m not saying that a writer can replace a designer – that’s just bad math. A company that wants to succeed in designing good software, web interface, and more, needs to hire the people who have expertise in software development and web design. After all, writers can’t develop code! But what writers can do is parse the meanings of things. We have the highly developed talent for taking complex ideas of language and inference, metaphor and symbolism, and making meaning from them. And we can tell you when it just doesn’t work. And many of today’s writing programs require classes like Document Design, Communication Design, Visual Communication, and more – things that are akin to how users interact with the ways we are trying to reach them.

storytelling
Writers understand story. We tell stories. And in agile development, what do we call the very things that are on the table for development? Yes! Stories! In scrum meeting after scrum meeting, we task out stories for development, and the scrum master even relies on scenarios to help the team imagine how those jobs will be completed. It is proven in release after release that picturing how a certain element of the product will be used, valued, and consumed by the customer or end-user is a useful tool to the development team. Storytelling allows agile methodology to work, from start to finish. Good writers understand tension and pain, so writing a story or scenario helps to flesh out the documentation that will guide users through installation and troubleshooting. Writers are instrumental in sensing where and when the struggle points will hit for the team long before the software is released for general audiences.
Writers “get” emotion. We deal with it all the time in storytelling. Put a writer in the room in every scrum meeting and just watch how a talented one can help diffuse tense moments over hours invested in an idea that didn’t pan out. It isn’t foolproof, but a writer is also a good catalyst for humor, empathy, kindness and redirection in the heat of the moment. Many writers have a genuine interest in the investment of people, and writers can often help find a silver lining – if there is one to be found – and can redirect the energy. The User Experience is not always found on the outside of the room. Part of the experience is getting the product out the door without trauma.

traumaThe common argument against having a UX person on the team is cost, so often companies toss out the notion as a line-item veto in budget discussions. If there is a place for everyone at the table, that is fantastic, but in the current economy, often we are asked to develop multiple, portable talents. Those who can carry talents across the table are asked to do so. And they should.
The next time you are wondering how your customer might perceive something, I’d ask you to look across the table at your gifted technical writer, your talented copy editor, your incredible documentation specialist, and say, “How does this read to you? What do you think our customers will say? How does this look? What story does it tell?”
You might just be pleased with the answer. You may have found a user…with experience.