How to Create and Deliver Intelligent Information

Gotcha – Stumbling Blocks during Research

Great opportunities open up thanks to intelligent information. However, before information can become intelligent, it must first be researched. There are many methods and tools for managing, distributing and querying intelligent information, but not for researching it.

The following story, which has actually taken place, shows how the examination of intelligent information request and delivery can help you with your research.

Research case

I had prepared myself thoroughly for a research appointment for a new device: I had read the documentation of the predecessor device, the risk assessment and the specifications, worked out a checklist with research questions and obtained written permission to record the research with a video camera so I didn’t have to write extensive notes.

The product manager met me with a friendly greeting and led me directly to the developer and the specially provided device. We immediately started a variant of intelligent information request and delivery – the research interview. The developer presented a masterpiece of technology, explained in detail all the connections, operating elements, setting and adjustment options and demonstrated the configuration and execution of the various functions.

Hour after hour passed while I filmed everything exactly and gradually checked research questions off my checklist. The developer explained every detail down to a button on the touch screen that could be used to deactivate the user interface for thirty seconds. In my mind’s eye, the who-does-what matrix completed itself with the user group “cleaning staff” and the activity “cleans the touch screen”. It ran perfectly.

Finally – the low-battery symbol had just started flashing on the video camera display – the developer proudly announced:

“Everything I showed you today on this old device will no longer be available in the next generation of devices. The new device is completely operated with client software that we are currently having programmed externally. You’re supposed to create the software instructions, right?”

I had a problem.

Research traps

I fell into several traps at once that a technical writer must absolutely avoid during research:

  • I misinterpreted the documents received in advance. Because no client software was mentioned in the documentation of the predecessor device, I did not ask in advance whether a device or software manual should be created.
  • I left too much initiative up to the developer. This caused me to receive key information too late.
  • My video camera allowed the developer to feel challenged to present something cinematic.
  • My main mistake, however, was that I adopted the developer’s perspective, which always focuses on the product and its features and characteristics. This error is particularly serious because pure product research material is then all too easily turned into a product description – and not into a user-friendly manual that is structured according to activities, tasks and roles.

Back to the beginning

Nevertheless, I was still able to produce good instructions, as follows:

  • I was tired by now, had only half an hour left and was not prepared for software research. So I took out my smartphone and used the iiRDS specification I had read on the train as a checklist for my research.
  • I scrolled down to the software domain classes and asked the developer questions about each label, which gave me all the software-relevant information.
  • The iiRDS main class InformationType reminded me to ask for the planned roles, rights and releases of the software users.
  • The functional metadata section prompted me to request a list of the software’s status, warning, and error messages.

With this information – and the screenshots sent later by email – I was able to create complete and user-friendly activity-by activity instructions because I hadn’t forgotten a single aspect in my research.


iiRDS is an ingenious concept because the metadata standardized for intelligent information request and delivery also provide a structured template for research. The information type metadata in particular help in asking research questions concerning not the product, but its users and their tasks, roles and rights. From the developer’s perspective, the product is at the center. The technical writer who, however, needs to see the big picture, can be guided by the universal approach of iiRDS.

Like it? Share it! Spread the Word...

Sag uns jetzt deine Meinung per Kommentar!