"Technical communications" is, let's be honest, quite a vague term. I think this is fantastic. More than that, I think it's important. Some folks don't agree. I'm deeply baffled as to why.

What a technical communicator isn't

In a discussion about what constitutes technical communications experience, the phrase "Ergonomics is not technical communication" popped up. It's an assertion you could probably argue with. But I'm not convinced it would serve any more purpose than asserting it in the first place. That a dog is not a duck utterly fails to help me if I have a problem that requires more than or subsets of dogness or duckness.

The - not unreasonable - rationale was that ergonomics doesn't typically share much by way of output with something like technical authoring or illustration.

The equally reasonable rejoinder is that an ergonomist with enough interest in technical communications to want to call themselves a technical communicator might well have something to contribute. They might be experiencing a creep/overlap/expansion of role comparable to the shift from all-paper tech author to online information designer.

I've always felt it's this very vagueness that the term "technical communicator" was coined to handle. It's an umbrella term. It's deliberately not "technical author", though it may have evolved from there. It's inclusive with plenty of space to spare, because technical authors (or illustrators, or information architects, or oh, I don't know, gibbons that really like graphs) are evolving into plenty of spaces.

So what do we do, really?

By that, I don't mean to ask what our "deliverables" are. Paper manuals, web pages, pop-up books, video tutorials, or a subtly nuanced aria reflecting the intricacies of a database schema - none of these are more or less valid, and all are broadly irrelevant.

What we do, when we get down to it, is produce user-optimised information to meet business needs.

That's pretty vague, but it needs to be.

It needs to be vague because the best combination of user and business needs might well be served by a quick-start flashcard in one case and a twenty minute mime in another. Now, it happens that lots of us do this by writing, but our professional body isn't the Accredited Technical Authors Club. The ISTC (UK) and STC (International) are a wee bit broader than that. Professionally, we enable people to understand and do things. And we're a long way from being alone. Technical communication, information architecture, user interaction design, marketing, content strategy, and any number of other disciplines are ways of labelling aspects of this process.

There goes the neighbourhood

Interestingly, the ISTC rule book says "technical communications" can ".also include visual, aural, tactile or other means of conveying the said information".

So it's, umm, communications, then. And there's a much, much more sensible discussion of that on Rachel Potts' blog

To have such a wide definition is to accept that, for example, should I produce a felt collage that attempted, by texture, to fully evoke the feeling and process of installing Apache on a server, it would, if it succeeded, be an acceptable act of technical communication.

This is not merely silly, it's controversial.

To me, the disagreement feels a bit like the tired old "is it art?" argument: a sniffy and patrician red herring. It's in a gallery: it's art. That wasn't ever a meaningful question, and the definition isn't where the value lies. The useful questions are: What are its meanings? Does it add anything to the culture? Is it interesting? Does it provoke powerful reactions? Early critics of Duchamp's Fountain more or less became part of its meanings by bickering about its validity. They are not widely remembered as noble guardians of cultural integrity.

So what are we doing by trying to define a technical communicator? Are we trying to get better at making information, or are we chalking "no girls" on the side of the tree-house?

I asked Twitter. My favourite response came from John Ellam: "Title's not important. I did not have to buy a license to do my job. Work produced is key"

I agree. A rigorous definition seems to serve little purpose unless you've some peculiar vested interest in issuing that license. Doing technical communications is increasingly about doing whatever your organisation needs done to the information it presents to its users. As those organisations wake up and smell the content strategy, the role is only going to get fuzzier and more important.

Is there a case for a license? Yes. The exact same case as for requiring a spelling and grammar test before letting people post on an internet forum, and with comparable practicality and odds of success. Robust accreditation is one heck of a proposition.

My solution: we take a cue from IBM and re-brand as "Information developers". Then have a whip-around to fund some bus ads: "There is probably no such thing as a technical communicator; stop worrying and get on with your lives."