Profiling Tool
The multilingual competence framework is being made available as an interactive Profiling Tool by tekom to all users and interested persons.
With the Profiling Tool, you can make a targeted selection of the requirements specific to you on the levels of knowledge areas, competence fields, topic groups and learning contents and thus create a personal competence profile.
Using the "Professional" and "Expert" buttons, you can pre-select competence and qualification requirements for the respective level.
Select "Professional" if you have no or little professional experience in technical communication. Select "Expert" if you already have more than two years’ professional experience.
For a further individual summary of the contents, click on an area level to open it. Using a rating scale of five stars, you can enter a self-evaluation. Once you have made your selection, you can send your summary to your printer using the "Print" button, or save it in PDF format.
How to Use the Profiling Tool
Short Guide to Using the Profiling Tool (PDF)
The buttons "Show Teaching approaches" and "Show Learning objectives" switch to the teaching and exam-oriented views for the qualification consultation, the accredited training programs and the tekom certification examination. Further information can be found in the PDF 'The Teaching and Exam-Oriented Perspective of the tekom Competence Framework' (coming soon) and on the tekom website in the "Certification" area.
1. Context analysis
Before creating an information product, it is necessary to analyze the requirements which it must meet. Context analysis determines the underlying conditions and the requirements that are placed on an information product by its context.
Context analysis is a preparatory process phase. One distinctive feature is the fact that not only internal sources but mainly sources outside the company are evaluated. In doing so, overarching aspects such as legal and normative requirements, markets or target groups are investigated. Context analysis does not have to be performed for every documentation product but does need to be performed regularly at scheduled intervals or when modifications have been announced. The results of observing the information product are evaluated in the context analysis and their consequences for creating information products are deduced from these results. Context analysis and its results are interpreted specifically to the documentation, depending on the nature of the information product and the underlying conditions.
A context analysis examines:
- Legal requirements
- Normative requirements
- Target groups
- Country-specific requirements
- Products and technologies
- Media and information technology
- Results of observation of the information product
The results of the context analysis are fed into the concept for an information product and also into aspects such as media development, publication and distribution.
-
1.1 Legal requirements
The legal requirements placed on an information product affect, among other things, the risks and hazards associated with the product, product safety, duty to instruct or compliance. Only some of the legal requirements and obligations that apply when placing products on the market are a direct result of legal provisions. Court decisions continue to be hugely significant. The legal provisions for information products are derived from the legal provisions for the condition of products and are also designated as the “duty to instruct”.
All the legal requirements that apply to an information product are determined and documented as a result of an analysis. These requirements are stated in concrete terms during the concept development phase.
-
1.1.1 Risks and dangers associated with the product
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Risk assessment ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Legal significance of the risk assessment ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Risk categories and hazard classes (hazard levels) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning and executing a risk assessment ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.2 Product safety
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Basic principles of Product Safety ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Main features of Product Safety Law ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Characteristics of safe and unsafe products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Safety requirement-related regulations ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Requirements placed on information products in pursuance of Product Safety Law ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Manufacturer’s product observation obligations ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Organization and operating principle of market observation (e.g., at European level) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Methods of achieving or improving product safety (e.g., design measures, safety devices, safety notes and warning messages) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.3 Duty to instruct
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Requirements based on duty to instruct: Requirements stating which types of information products have to be supplied according to which particular specifications (e.g., Product Safety Law, EU Machinery Directive) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Documentation obligations pursuant to applicable legal provisions (laws and guidelines) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Possible ways of meeting documentation obligations ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.4 Legal consequences
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Main features of contractual liability ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Main features of legal product liability ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Liability in the field of Technical Communication (e.g., personal and entrepreneurial liability) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Requirements regarding content placed on information products as a result of product liability ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Formal requirements placed on information products as a result of product liability ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Possible legal consequences arising from defective information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Transposition of supranational law (e.g., EU Directives) into national law; significance for product liability ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.5 Copyright law and right of use
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Basic principles of copyright law and legal right of use (license law) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Relevance of copyright law and legal right of use in Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Potential conditions of use ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Copyright law in case of sources and requirements placed on legal use of sources (e.g., images, text, software licenses) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Use of materials protected by license rights (e.g., software, photographic material) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Legal situation where open source materials are used ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.6 Data protection
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Basic principles of data protection (data privacy) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Relevance of data protection to Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.7 Product compliance
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Basic principles of product compliance ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Declarations of Conformity in information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Allocation of tasks and roles with regard to ensuring product compliance ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Requirements placed on Technical Communication for product compliance and placing products on the market ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.8 Legal research
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Basic principles of legal research ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Laws that are relevant to Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Public information sources, sources of supply and information portals ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Legal research tools ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Archive searches ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.9 Data and IT security
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Data and IT security in relation to content of information product ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Data and IT security in the creation process ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Data and IT security in relation to delivering the information product ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.1.10 Legal requirements placed on Document Management
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Archiving of information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Audit reliability ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Retention periods ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Storage locations ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Consequences and liability in event of inadequate Document Management ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
1.2 Normative requirements
National and supranational standards specify further requirement placed on information products in concrete terms. A standard contains a definition of the requirements placed on technical equipment, components, system modules and technical interfaces, processes and procedures.
Standards do not have any legally binding status because they are produced by private standards bodies rather than by government legislation. They are essentially applied on a voluntary basis. Nevertheless, the application of standards may be made mandatory by legal regulations. The following requirements placed on Technical Documentation as a result of technical standards are liable to constant change at both national and international level.
All the normative requirements that apply to an information product are determined and documented as a result of analyzing applicable standards. These requirements are stated in concrete terms during the concept development phase.
-
1.2.1 Standards
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Relevance of standards to Technical Communication and requirements placed on information products as a result of normative requirements ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Standard for the preparation of Technical Documentation (IEC/EN 82079) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Interplay between standards, directives and laws ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Legally binding nature of standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Market relevance of standards (e.g., EU Standards, ISO Standards, DIN Standards) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Fields of application of standards (for products, e.g., Low-voltage directive, Pressure equipment directive, Medical equipment standard) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ International standards compared with European standards that regulate the same subject matter (e.g., standards in the ANSI series, IEC/EN 82079) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.2.2 Standardization
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Purposes and basic principles of standardization work ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ National and international standards bodies ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Horizontal and vertical standards (product standards) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Identification of type of standard by referring to the name of a standard ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Safety-related distinction between A, B and C standards according to ISO/IEC Guides ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ International Classification for Standards (ICS) as an international classification criterion for standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Establishing, organizing and cooperating on national and international standardization ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.2.3 In-house standardization in companies
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Purposes of factory standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Subject matter of factory standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Areas in which factory standards are applied ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Factory standards and Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.2.4 Compliance with standards
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Normative requirements of international markets ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Documentation requirements (e.g., in requirements specifications and functional specifications) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Checklists taken from standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Application and implementation of standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Seals of approval and certificates ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Accredited testing institutes ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Approval and testing of compliance with standards ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.2.5 Researching information on standards
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Information sources, sources of supply and information portals ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Standards repositories ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
1.3 Target groups
Target group descriptions characterize the users of an information product in a given usage situation. Every information product must be easily understandable and usable for its target group. One must know the information product’s target group and its requirements in order to achieve this. The characteristics of the information product can be determined and derived from this starting point.
Relevant features describe target groups and usage situations. Various methodological approaches make it possible to follow a systematic procedure when analyzing target groups and their usage situation.
A target group analysis produces specific guidance on how to develop a product.
-
1.3.1 Documentation-relevant target-group characteristics
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Target-group characteristics that have an impact on the use of an information product and consequences for creating an information product (e.g., age, level of expert knowledge, technological expertise, level of education, culture, language skills, media competence, color blindness, disabilities, users' technical equipment, rights of use, distribution channels) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ The target group’s usage environment (e.g., in order to determine the most suitable publication medium) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ The target group’s degree of familiarity with technologies ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.3.2 Characterization of target groups
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Objectives of characterizing target groups and target-group analysis ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Classification and characterization of target groups ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Target-group related data gathering, acquisition of “hard data” regarding the target group (e.g., from studies, the company’s customer contacts (e.g., from Service, Support) or from usability studies) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Methods of characterizing target groups, e.g. target group analysis (e.g., Persona method, who-does-what matrix) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.3.3 Target group analysis
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning, executing and assessing a target group analysis, basic principles and systematic problems ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Acquiring information using various target-group analysis methods (e.g., methods that aim to describe target-group features as opposed to methods that are geared towards the use of the product/usage situation) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Using results obtained from target group analyses, user profiles and “hard data” for the information product concept ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Dovetailing target group analyses with other methods (e.g., analysis of product usage, such as use cases, task analysis) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.3.4 Trends in users’ behaviors
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Developments and trends in use of media, expectations and requirements placed on media and presentations ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
1.4 Country-specific requirements
Information products for different countries and markets must meet country-specific requirements. These include:
- Technical requirements
- Culturally-specific aspects of the target group
- Legal and normative requirements
Taking these requirements into account in the information product is relevant when it comes to placing the product on the market, product compliance and usability. Information on this can be obtained directly from destination countries, from technical requirements and product specifications, from contracts or by research.
The resulting requirements placed on information products must be taken into account during concept development and be implemented when the product is produced.
-
1.4.1 Technical requirements
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Country-specific technical requirements (e.g., materials, socket outlets, voltage) that must be taken into account when creating information products for international markets. ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.4.2 Culturally-specific aspects of the target group
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Culturally-specific differences in the way that information is processed (e.g., characters, colors, images, reading direction) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Cultural aspects of pictorial and symbolic language ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Culturally-specific differences regarding expected ways in which information is presented ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Cultural and country-specific aspects of the target group when using the information product and when using media ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Cultural and country-specific aspects of the target group which might impact use of the product ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Culturally-specific methods of working ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Country-specific aspects and requirements (e.g., linguistic, terminological, technical, organizational) that must be taken into account when creating information products for international markets. ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.4.3 Legal and normative requirements
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Country-specific legal and normative requirements placed on information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
1.5 Products and technologies
Before developing an information product, the characteristics of the product and the resulting requirements placed on the information product must be determined. Conversely, the information product may result in requirements being placed on the product.
An information product must describe all relevant functions and conditions for users. The product structure and possible versions which must be taken into account in the information product are determined when analyzing the product. The use of a product in every phase of the product’s life-cycle is another aspect of product analysis. The product technology that is used is also investigated and conclusions are drawn regarding its degree of familiarity and the expected knowledge of users. Allowance must be made for possible interactions between the information product and the product. The features of the product, such as a display, have, for instance, an influence on how an information product can be provided.
The results of this process step must be taken into account during concept development and be implemented when the product is produced.
-
1.5.1 Product analysis
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Acquisition of product knowledge (technologies, application, risks, safety aspects etc.) in order to develop information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Analysis of product structure, controls, product features, functions and product usage (including accessories and spare parts) in every phase of the product life-cycle (e.g., commissioning, operation, control, maintenance, service, repair, disposal) and of relevant information for this purpose (e.g., compatibility with previous/subsequent products, modifications, development) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Analysis of product versions ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Analysis of interfaces and integration into systems (plant manufacturing) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.5.2 Analysis of use of product
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Analysis of use of product (e.g., use-case analysis, task analysis, observation, context interviews) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning, executing and evaluating a specific method of analyzing product usage; basic principles and systematic problems ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Use results obtained by analyzing product usage for the information product concept ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.5.3 Product features and information product
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Features of the product (e.g., controls, display) and resulting requirements, restrictions and options for the information product (e.g., data transfer, operation and control using apps, interfaces) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Requirements placed on the product by virtue of the information product (e.g., how must the product be constructed in order to provide the information product, e.g., storage of information, codes) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specific requirements in the case of electronic information products (e.g., integration of context-sensitive Help and/or embedded Help in software user interfaces) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.5.4 Product technology
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Analysis of technologies used and their degree of familiarity to the target group (e.g., whether a familiar or unfamiliar technology) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Deducing, from such analysis, the consequences of technologies used on the information product’s concept (e.g., whether familiar or unfamiliar technology, whether market launch or already established on the market) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.5.5 Competitor analysis
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Competitor analysis and its use in the field of Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Comparing information products with corresponding products from competitors (e.g., benchmarking) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
1.6 Media
Information products can be made available to the user using various media. When creating an information product, a decision must be made as to which types of media are most suitable under the given underlying conditions. Use by the target group, the product that is to be described, how the information product can be displayed on the various output devices and which media standards can be used are all factors that are relevant to this decision.
The results of this process step are used for media planning.
-
1.6.1 Types of media
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Types of media that are inherently representational (e.g., text, image, graphic, 3D model, film, audio) or inherently interactive (e.g., hypertext, interactive image, interactive graphic, interactive 3D model, interactive film, animation, simulation) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Classification of media types (e.g., categorization according to type of representation) and use of classification (e.g., as meta data and attributes) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.6.2 Publication media and output devices
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Publication media (e.g., print, Internet browsers, viewers, audio, sensors) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Output devices (e.g., PC screen, smartphone, tablet, data medium, loudspeaker, projector, glasses, headset, paper) and their characteristics for integrating information products, e.g., in terms of storage, archivability, readers, mobility, availability, usage environment (e.g., dust, temperature, soiling, humidity, mobility, online connection) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.6.3 Media standards
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Technical source and output formats and standards for encoding content (e.g., PDF, HTML5, EPUB, XML, JSON, 3D-PDF, U3D, WebGL, 3D-XML, MPEG4, MPEG3, web apps, hybrid apps, native apps) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Restrictions imposed by media standards with regard to their use for information products and dependence on publication media, output devices or operating systems ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
1.7 Results of observation of information product
As part of the context analysis, the way in which information products that have already been successfully developed and placed on the market and what scope there is for potential improvements are investigated. The results of monitoring the market for the information product must therefore be analyzed and taken into account when planning, designing and creating new information products.
-
1.7.1 Analysis of observation of the information product
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Analysis and assessment of feedback and observations ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Error culture in the company ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
1.7.2 Continuous improvement process
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Continuous improvement processes (e.g., Deming Cycle, Lessons Learned, Kaizen) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Remedial and precautionary measures (including planning, responsibility, deadlines, implementation and monitoring) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
2. Planning
The entire information development process must be planned in advance. Information products are created, as a rule, through workflows that are organized in a project-like manner. Because no two information products are the same, although there are standard processes for information development, the creation of information products must be planned as a project.
The project engineering process, which is itself organized as a project, is the trigger for information creation as a rule. In this case the information product development project is a subproject in a higher-level product development project. Modifications to products that have already been launched or changes to underlying conditions may also make it necessary to adapt to information products.
In every case, planning must take into account necessary resources such as funds, personnel and time as well as workflows and relevant interfaces, e.g. with suppliers.
Planning involves:
- Product life-cycle support
- Information creation planning
- Project Management
Information from various sources, e.g., from context analysis but also from internal documents e.g., product specifications, requirements specifications, functional specifications and empirical values from previous projects, have an impact on planning. Fundamental content and design-related definitions are also fed into planning.
The planning phase results in a specific schedule and milestone plan for creating information products which also provides information about capacity, costs and interfaces.
-
2.1 Product life-cycle support
Information products offer the user assistance in various phases of a product’s life-cycle, e.g. installation, commissioning, use, maintenance and disposal.
Distinctions are made between planning the creation of an information product based on product development, product changes and the need to modify an information product without modifying the product.
The content of an information product is inextricably linked to information from other business units, e.g., Development, Marketing, Training and Customer Service. In order to create information products effectively and efficiently, the need to coordinate timings with these other business units must also be taken into account.
Project planning results are used in the next phases.
-
2.1.1 Basic principles of product life-cycle
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Presentation and workflow description of the product’s life-cycle ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Interrelationship and interplay between product life-cycle and creating information products (e.g., documentation needs, necessity, development processes and delivery of information products) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.1.2 Dovetailing the development of information products with product development
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Product development processes and development of information products having industry-specific differences (e.g., processes in mechanical engineering, plant construction, automotive engineering or software development) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Integration of requirements placed on information products (e.g., necessity of a display) into the product specification (e.g., availability of a display) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Dovetailing the process of developing information products with the process of product development (e.g., by setting milestones) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Information flows between Technical Communication and Product Development ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.1.3 Planning information products when products are launched
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning the necessary information products for a product ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning the information architecture ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Change Management during product development ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.1.4 Planning information products in the event of product changes
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Determining the information products and contents affected by a modification (e.g., content modules, tables) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Determining the scope of a modification (e.g., additional information or inventory change) and extent of modification (e.g., minimal change, alterations or complete overhaul, e.g., terminology) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Determining change histories and versions ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Change Management in the event of product changes after completion of product development ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning translation in the event of changes ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.1.5 Planning the correction of information products (without any modifications to the product)
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Determining the extent of corrections or additions and contents that are to be corrected ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Prioritizing and evaluating the urgency of corrections ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Informing the target group about corrections ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Distribution of corrections ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Replacement of corrected information product and ensuring delivery (e.g., updates via the Internet, downloads) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Arranging recalls ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning translation in the event of corrections ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.1.6 Dovetailing the development of information products with other business units
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Dovetailing Technical Communication with other business units (e.g., Marketing, Product Management, Sales, Training) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Distribution channels and resulting requirements placed on technical documentation (e.g., formats, media, data formats) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Differences in distribution channels (e.g., B2B, B2C, C2C) and their relevance to Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ E-commerce and its relevance to Technical Communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
2.2 Information creation planning
The requirements placed on every information product differ in each project. This is why planning the creation of information for individual detailed tasks must be set up specifically. This includes defining how the process is organized and which resources are needed in order to achieve implementation.
It includes defining how the process is organized, which resources are needed in order to achieve implementation, what knowledge the executing employees must have, which interfaces must be taken into account and which requirements have to be met in order for all the individual substeps in the information development process to run smoothly. The basis of planning is usually provided by empirical values obtained from previous projects.
The entire information development process (time, tasks, contents and workflow) is devised in advance during information creation planning.
-
2.2.1 Basic principles of information planning
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Presentation of the information development process and detailed description of phases and work packages when developing information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Different variants of the information development process with individual phases or phase-related tasks (e.g., industry-dependent, product-dependent, depending on Project Management method) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Options for organizing general and specific processes for creating information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.2.2 Content planning
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specifying and selecting information products (for the various phases of a product’s life-cycle) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specifying and selecting media for the target group ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specifying all the information that accompanies a product (e.g., for documentation summary, for delivery list) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specifying information products for product variants ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Creating a content plan (e.g., list, structure) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specifying and selecting presentation mode and degree of detail ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Defining the concrete requirements placed on external information products (e.g., supplier’s documentation) and contract design ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning contents of product information that can be created in-house ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Integration planning for various internal (possibly external) content or information products (e.g., integration of supplier’s documentation) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Taking requisite explanations, certificates and approvals into account ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.2.3 Implementation planning
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning the implementation of the individual results of a context analysis ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Defining the concrete content concept ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Defining the concrete media concept ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Media-specific production planning (e.g., illustrations, films, animations) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning the implementation of international requirements ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.2.4 Creation planning
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Specifying the volumes created and resource planning ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Production planning for information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning of procurement and commissioning of service providers (e.g., media developers, terminology translators, graphic artists, TD service providers) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Time and task scheduling (e.g., work packages, schedule for, e.g., authoring tasks, supplier’s documentation, service provider’s documentation, creating graphics and media, translation tasks) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Process design, interfaces and task coordination ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning liaison with support processes (e.g., translation, terminology) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Handling confidential information ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning the use of tools ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.2.5 Information procurement planning
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning procurement of information (e.g., objectives, questionnaire, location, interlocutors, materials, preparation) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Planning the information procurement process: Process steps and planning variables (e.g., scheduling, effort planning) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Defining the requirements placed on sources within the company (e.g., on data formats, template) and documents ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Determining requirements resulting from open-source software ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
2.3 Project Management
Project Management involves organizing, executing and monitoring the information product’s development process and process steps, working tasks and resources.
This is where project details are specified and planned. The required Project Management techniques and tools are also described.
The result of Project Management highlights the scope and effort required for the information product creation project and is implemented in subsequent phases.
-
2.3.1 Basic principles of Project Management
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Projects and project features (typical project phases, setup and workflow organization in projects, differences and shared features of projects and processes, Technical Communication projects) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Tasks, objectives and need for Project Management ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project communication tasks and objectives ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Creating requirement specifications, functional specifications, specifications ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Organizational roles in projects, competence requirements placed on a Project Manager and the project team ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.3.2 Project planning
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project context analysis and definition ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Task and performance planning ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Estimated effort and resource planning ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Cost planning ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Defining and monitoring key project figures ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project risk planning ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project documentation ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Workflow, deadline and resource planning ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.3.3 Project execution and controlling
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project controlling tasks, methods and procedures ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Assessment and prioritization ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Determining and managing critical paths ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Time management in products and typical “time guzzlers” ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Measures in the event of deviation from plans ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Coordinating tasks and activities and information management within the project and with the world outside the project ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project communication ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Change Management methods ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Risk Management methods ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Methods of managing interfaces and deliveries ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.3.4 Project reporting
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Defining and monitoring key project figures ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Target/actual analysis ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Preparing status reports ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project presentation (e.g., to Steering Committee and outsiders) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
2.3.5 Project Management tools and techniques
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project Management models (e.g., waterfall model, agile models, V-model) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project Management techniques (e.g., Gantt chart) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Requirements placed on a project management tool ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Project Management tools (e.g., MS Excel®, MS Project®, Mindjet MindManager®) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
3. Concept development
Concepts that overarch several information products are defined during the process phase of concept development. These include, for instance, which information products are produced with which functions and which information architecture.
A concept is intended to ensure the consistency and uniform quality of information products. This is especially important if several people are involved in creating information products.
Concepts must be reviewed routinely at appropriate intervals. A review is also required in case of special events such as, e.g., launching new products, new variants or new media.
Concepts have a direct impact on content creation and on subsequent process phases.
-
3.1 Information products
Different information products may differ fundamentally in terms of their characteristics and function. The first task when developing a concept is, at the highest level, to define which type of documentation is involved, which type of information product is being created and what its communicative function is. The product life-cycle is an important starting point for this purpose. For each phase of the product life-cycle, the user needs different information that has to be documented for the user.
The concept for information products defines the features and characteristics of the information products.
-
3.1.1 Internal and external documentation
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ External documentation ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Internal documentation ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Special types of documentation (e.g., API (Application Programming Interface) documentation during software development) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
3.1.2 Types of information products
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Classification and types of information products (e.g., installation instructions, operating instructions, maintenance instructions) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Connection between product life-cycle and information products ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ -
3.1.3 Function of information products
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Communicative functions (e.g., instructions, information) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Design principles for information products that fulfill specific communicative functions (e.g., depending how the information product is used, e.g., for installing, operating, training, e-learning) ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆
-
-
3.2 Information architecture
The information architecture specifies which contents are incorporated in the information product with which structure, which function and at what depth. The fundamental principles for the information architecture, such as target group analysis and usage situation, are evident from the context analysis. <br/>The way in which other contents are to be integrated, e.g., into supplier’s documentation, must also be defined. Necessary meta data for managing contents must be defined.
The information architecture provides the structural and content-related concept for developing information products.
-
3.2.1 Developing the information architecture
★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Information architecture ★ ☆ ★ ☆ ★ ☆ ★ ☆ ★ ☆ Content-related aspects for defining the information architecture (e.g., target groups, for which information products, media, structure, information types, communicative function) ★ ☆ ★ ☆ ★ ☆ ★
-