An Innovation Specification

People have asked: How do you go about innovating in technical communication?

 

Should we willy-nilly adopt every fad? We all know that most fads fizzle out.

 

Ah, but then there are the revolutionary ideas that really take off and completely change the way we work, play, and think.

 

For example, almost every verb and noun in these sentences would have been meaningless a few years ago: I’m blogging on a laptop. I link to the blog, which has an RSS feed, on my social media site.

 

It is hard to tell what the next successful invention will be and how technical communicators should respond to it.

 

You may also ask: What about the progress we have made? For instance, should we throw out all the CMSs, XML, and structured chunks that we worked hard to produce? Clearly not.

 

But we are missing a set of requirements for how to innovate.

 

We need to refer to a spec that would provide innovation development guidelines, nudge us in the right direction, and build on the existing tech comms techniques that are most adaptable and promising.

 

It would also provide managers with a tool to assess the methods we advocate.

 

I don’t know of such a document. So let’s create the Great Technical Communications Innovation Specification. (Alternative titles will be gladly accepted!)

 

As with all good documentation, let’s start with a scope and an outline.

 

The spec’s scope would be to answer the following question: 

What is required to effectively convey information that users need about technology that exists or is being developed?

 

True, implementing the spec won’t give us a crystal ball to see into the future. But if we can come up with solid requirements for the stuff that’s out there and that’s currently under development, we’ll have a much better chance of handling the next generation of technology.

 

Here is an initial stab at some high-level requirement areas that the outline should include:

• Mobility
• Accessibility across platforms
• Usability
• Modes (audio, visual, tactile)
• Audience analysis
• Constraints  (such as time, display size, file format)
• Code documentation (Architecture, API, Design, Requirements, Test)
• User interface documentation
• Reuse
• Integrating documentation with source code
• Support of development environments, including Scrum/agile
• Social media

 This list was stream of consciousness. I need your help to:

• Comment on the proposed items.
• Prioritize the requirements.
• Fill in missing high-level requirements.
• Suggest ways to proceed.

Specifically, we’ll need to sort out:

• What’s the best way to maintain and develop the spec? (A Wiki?)
• Should we start by fleshing out only the highest priority requirements?
• Any ideas for a killer review process?

 Thanks for your cooperation. Let’s start specing!