Computersoftware

Sie haben ein nahezu perfektes Produkt entwickelt oder eine großartige Software erstellt. Und um Nutzungsprobleme zu lösen, haben Sie dann einige der besten technischen Redakteure damit beauftragt, ein benutzerfreundliches Handbuch zu schreiben. Sie wollen, dass Ihre Produktbenutzer von der ersten Minute an Freude an Ihrem Produkt haben. Wie Ihr User-Experience-Team bestätigt hat, haben die technischen Redakteure eine tolle Arbeit geleistet.
Aber nach der Markteinführung Ihres Produkts oder der Veröffentlichung eines Updates scheinen Sie deutlich mehr für die Kundenbetreuung auszugeben. In vielen Fällen sind die Antworten, die Ihre Benutzer suchen, direkt in dem Handbuch zu finden. Sodass Sie sich jetzt dieselbe Frage stellen, die sich bereits viele Hersteller und Entwickler gefragt haben: Lesen die Produktbenutzer die Handbücher überhaupt?

Die Auswahl des richtigen Formats zum Veröffentlichen Ihrer Hilfedateien kann tückisch sein, besonders wenn Sie Ihr erstes Handbuch erstellen und die größten Fehler, die erstmalige Autoren von Handbüchern machen, vermeiden wollen. Das richtige Format bestimmt, ob Ihre Benutzer auf Ihre Hilfedateien genau so zugreifen können, wie sie sie brauchen und genau dann, wenn sie sie brauchen.
Wenn Sie ein Hilfe-Entwicklungstool anwenden (und das sollten Sie, denn es ermöglicht Ihnen, bessere Hilfedokumente in der Hälfte der Zeit zu schreiben), dann sollte das Veröffentlichen in mehreren Formaten gar kein Problem sein.
Die große Frage, die wir heute beantworten, lautet: Sollten Sie eine gedruckte Anleitung (Hardcopy) oder ein Bildschirmhandbuch (PDF-, CHM-, webbasiertes HTML-, E-Book-Format...) herausgeben?

Viele Autoren von Handbüchern haben festgestellt, dass Hilfe-Entwicklungstools oder HET-Softwareprogramme eine gute Möglichkeit darstellen, um Handbücher und andere Hilfedokumente schnell und einfach zu schreiben. Weniger Leute machen sich jedoch Gedanken darüber, auf welche Weise die Anwendung von HET-Softwareprogrammen auch allen anderen Beteiligten Vorteile bringt, einschließlich des Herstellers, der für das Handbuch zahlt, und des Endbenutzers des Produkts.

Microsoft Word ist eine tolle Software. Mit Microsoft Word können Benutzer mehr oder weniger alles schnell und einfach schreiben, von einem Schulbericht bis zu einem Geschäftsbrief. Der größte Vorteil von Microsoft Word ist der hohe Bekanntheitsgrad: Es ist eine Software, mit der die meisten von uns in der Schulzeit und im Büro aufgewachsen sind. Für viele Leute ist Microsoft Word noch immer die natürliche Wahl, wenn sie im Berufsleben etwas schreiben müssen. Und für die meisten Zwecke ist Microsoft Word ideal, es gibt jedoch einige Anwendungen, einschließlich des Schreibens von Produktdokumentationen, für die es nicht so gut geeignet ist.
Es gibt viele Gründe, warum Microsoft Word nicht das richtige Tool ist, um Ihnen beim Schreiben einer Produktdokumentation zu helfen; hier sind nur fünf dieser Gründe:

Das Verfassen von Hilfedokumentationen bedeutet harte Arbeit; ein technischer Redakteur muss jede Funktion eines Produkts auf verständliche Weise beschreiben. Die Dokumentation muss für eine große Bandbreite an Produktanwendern mit unterschiedlich ausgeprägter technischer Fachkenntnis oder verschiedenen Erwartungen geschrieben werden.
Trotz dieser Voraussetzung finden viele technische Redakteure, dass das Schreiben der Hilfedokumentation der einfache Teil des Prozesses ist. Nachdem sie alles aufgeschrieben haben, was notwendig ist, um das Thema ordentlich abzudecken, müssen sie die Dokumentation so formatieren, dass sie in einer Vielzahl an Formaten zugänglich und einfach lesbar ist. Eventuell erforderliche Formate umfassen PDF, Word, Online-HTML, vielleicht HLP oder auch CHM. Der ganze Formatierungsprozess kann sehr zeitaufwendig sein, vor allem da die meisten technischen Redakteure sich darauf konzentrieren wollen, wirklich gute Hilfedokumentationen zu schreiben, anstatt sich ewig darum zu kümmern, wie ihre Seiten auf verschiedenen Geräten angezeigt werden.
Wenn die Dokumentation schließlich fertig ist, bedeutet das häufig noch immer nicht das Ende des Prozesses, denn jedes Mal, wenn das Produkt abgeändert wird, muss die Dokumentation revidiert werden, um die neuen oder aktualisierten Funktionen widerzuspiegeln.