It’s the time of year for technical communication industry predictions, but that’s not my speciality. I don’t have my finger on the pulse of techcomm; in fact, I’ve been feeling like I’m in an isolated backwater. When people learn that I’m using ZenDesk for documentation they think that I’m either very brave or very masochistic.
As Luke Skywalker would have told me, “Well, if there’s a bright center to the [technical communications] universe, you’re on the planet that it’s farthest from.”
[Speaking of, what sort of help system would you write for a lightsaber? “Point shiny end away from face and good luck”?]
Getting back on target…
I’m picking this list because it’s short and I agree with it. But I’m going to examine why I agree, and what it means for my job.
Improved user assistance
The first prediction is:
“User Churn” will lead to SaaS providers looking to assist users in better ways
This is a great one. Although it’s not related to any churn issues, I’m responsible for
overall user assistance for a complex product. I’ve been pushing for more in-product help for a long time, and I think I’m finally gaining some traction. After spending years creating online knowledge centers, my new goal is to move as much as possible into the product itself. If I’m really successful, I’ll make the knowledge center obsolete.
I want to keep my customers as close to their workflow as possible. Forcing a busy customer to open a new web page and navigate to the right location breaks their workflow. This leads to frustrated users. Even if they end up better informed, they’ve still been pulled away from what they were doing. Or trying to do.
I’ve been busy leading a training development project, and now that we’ll have a solid training course the next step is to reinforce that with help content that focuses on the first-use experience. I’m imagining guided tutorials, written help content, and video pop-ups.
Organisations will take a more holistic approach to communication with users
This one is too easy. The goal is to make sure that there’s a consistent style, tone, and message for “the training emails sent out to new users, the User Interface text, the Help and the training videos.”
This is easy because I create all of those. But this is only part of the communication that a company creates, and I need to be sure that there isn’t a drastic shift between content created by my team (i.e., me) and that created by marketing (which is an actual team). So far, we nod in each others’ direction, but we don’t do much collaboration. Definitely room for improvement there.
Help as part of the product
Software developers will see Help as part of the product design, as first user Help grows in popularity
This is directly related to the first point. Most of my work this year will focus on first user (or first-use) content, and it’s going to require a lot of help from the engineering team to make that possible. The product management team is pushing me to develop a list of requirements for this, so now we’ll work together to convince engineering that this is vital to the overall user experience and will boost user adoption of our product.
Microsoft’s greater level of informality in its Help will be copied by others
In my experience, many smaller companies are already doing this. My help text is still a little formal and old school, but I’m moving to a more casual style. Something like “casual consistent”: writing in a way that makes translation easier (and less expensive), but moving towards a writing style that’s closer to my speaking style. Or somewhere between old school tech writing and blogging. Admittedly, that’s a pretty wide range.
I thought this shift started a few years ago when the Microsoft style guide endorsed contractions, but informal language hasn’t been adopted consistently. I assume that the larger the company, the longer it will take to change.
DITA will make slow progress
Unless I hire someone who happens to be a DITA expert, I know this will be true for me. Maybe Lightweight DITA will change that, but another lightweight tool that offers content reuse will do just as well.
And since I’m working with developers who don’t want to deal with XML, there’s no compelling reason to use DITA. I’m more interested in this process used at GitHub, although I’ll need to spend more time exploring that option.
The perils of predictions
So that’s five predictions that I agree with. I’m not sure how closely they’ll be true for the technical communications area as a whole, but they do map well to my current plans.
The only question is whether I can get away from firefighting mode long enough to put these plans info action.