Book review: Enterprise Content Strategy

When I attended the Information Development World conference I picked up a copy of Val Swisher’s Global Content Strategy: A Primer. I had just been asked to figure out what it would take to translate our product documentation and UI text, so I needed to learn as much as possible about translation and localization, as quickly as possible.

Global Content Strategy fits that requirement perfectly. It’s concise and to the point, and after reading it I was able to pt together a viable strategy, and talk to localization contractors without sounding like an idiot (always a huge fear of mine).

But this is a review of a different book.

Continue reading “Book review: Enterprise Content Strategy”

The case for Minimum Viable Documentation

I attended the TCCamp conference…er…unconference last weekend. Short review: I enjoyed it (again!). I attended Tom Johnson’s great intro to API documentation, I talked to some interesting people, and I got some practical advice during the three discussion sessions.

And I won an iPad Air 2 (thanks to XMetaL/JustSystems), which is FREAKIN’ AWESOME.

But I want to focus on one topic that came up during the “Technical Communication in Agile” discussion: the concept of Minimum Viable Documentation.

Continue reading “The case for Minimum Viable Documentation”

Working well with others

A big part of a technical communicator’s job is research. The information we use to create content comes from a wide variety of sources: technical specs, product research documents, business proposals, white papers, internal wikis, customer support tickets…

And even from actual people. There’s lot of good info locked away in our coworkers’ heads. Getting to that info isn’t always easy, but I’m honestly surprised how often one question comes up both in interviews and in discussions with other tech writers: “How do you work with engineers?”

Continue reading “Working well with others”

Quick thoughts on useful skills for technical communicators

A question that comes up regularly on Linked in forums is “What are the most important skills for a technical communicator to have?” I used to have a quick answer for that, but I realize it was based on how I learned to technical writing. But now many people in techcomm won’t be using a complex desktop publishing program to write manuals designed for print. They won’t be relying on the work of editors, illustrators, and a production team.

Continue reading “Quick thoughts on useful skills for technical communicators”

What users are looking for (hint: FAQs)

I spent last week researching support and learning management systems, working on a documentation delivery schedule for the rest of the year, and responding to a few complex support cases.

Those support cases, along with some comments from other users, have made me rethink my opinion of FAQs. Maybe it’s more accurate to say that this feedback is pushing me in a direction that I’ve been trying to avoid, while I knew that I was fighting the inevitable.

Continue reading “What users are looking for (hint: FAQs)”

Responding to Craft vs. Commodity

Connie Giordano has an interesting take (and a reader poll) on technical writing as a craft vs. a commodity. She’s writing something of a rebuttal to my post about the same topic. When I checked before posting this, the results were tilting towards “Tech writing is a hybrid profession,” slightly ahead of “Heck yes we’re craftspeople!” I voted for “hybrid” even though I’m not entirely sure what that means. But I think it’s closer to my argument.
Continue reading “Responding to Craft vs. Commodity”

You should work for a (small||large) company because…

When I was talking to people at the Write the Docs conference, I had a couple of interesting conversations with people who were weighing the costs and benefits of moving from a large company to a small startup. I prefer working for smaller companies, but I’ve been through this decision process a few times, and I’ve seen the good and bad of both large and small companies.

I can’t tell you much about being a contractor, though. I’ve only dabbled in it, and all I can tell you is that it made my tax returns slightly more confusing.

Continue reading “You should work for a (small||large) company because…”