Typischerweise stimmt die Stimme von Marketinginhalten nicht mit der Stimme von technischen Inhalten überein – das Marketing versucht, Sie davon zu überzeugen, dass Sie etwas brauchen; Beim technischen Schreiben geht es im Allgemeinen darum, Ihnen beizubringen, wie man etwas benutzt. (Ich spreche speziell von Software.)
Ich habe traditionell einen Techcomm-Ansatz für Versionshinweise gewählt – neue Funktionen und Fehlerkorrekturen auf einfache Weise beschrieben, wobei der Fokus auf dem Benutzer liegt. Die Leute von marcomm beschreiben die Features oft mit einem ganz anderen Vokabular. Bei den meisten Inhalten ist diese Unterscheidung klarer – Softwaredokumentation ist techcomm; Websites, Blogs, Pressemitteilungen sind marcomm.
Es kann argumentiert werden, dass die Versionshinweise zusätzlich zu einem technischen Zweck auch Marketingzwecken dienen und neben technisch versierten Benutzern auch Entscheidungsträger in Unternehmen erreichen. Wie entscheiden Sie über die geeignete Stimme für die Release Notes?
Ich denke, es gibt sehr starke Argumente dafür, dass diese Unterscheidung zwischen Marketing-Stimme und Tech-Comm-Stimme vollständig vermieden werden sollte. Dafür gibt es zwei Hauptgründe:
In alten Zeiten, als Tech-Comm und Marketing auf Papier geliefert wurden, kam jedes zu einer anderen Zeit und über einen anderen Kanal zum Kunden. Im Allgemeinen waren sie mit der Verwendung von Marketinginhalten fertig, bevor sie überhaupt die Möglichkeit hatten, technische Inhalte zu sehen. Aber das Web hat all das geändert. Marketing- und technische Inhalte stehen dem Kunden online zur Verfügung. Da der Benutzer dieses Material jedoch größtenteils über die Suche findet, ist nicht abzusehen, ob seine Suche ihn zu einem technischen oder Marketingdokument führen wird. Ein deutlicher Stilunterschied zwischen den beiden ist für den Kunden irritierend.
Es gibt viele Hinweise darauf, dass der traditionelle Ra-Ra-Marketington einfach nicht mehr funktioniert. Das Internet ermöglicht es den Menschen, Informationen aus so vielen Quellen zu erhalten, dass sie sich keiner eklatanten Propaganda unterwerfen müssen, um Informationen über ein Produkt zu erhalten. Kluge Vermarkter haben darauf reagiert, indem sie zum Content-Marketing übergegangen sind, das sich darauf konzentriert, Inhalte zu produzieren, die die Leser tatsächlich wollen, um sie für die Inhalte Ihres Unternehmens zu gewinnen und den Ruf Ihres Unternehmens als Experten auf diesem Gebiet aufzubauen. Gutes Content-Marketing darf nicht den alten Marketing-Rara-Ton haben, sonst wird es einfach nicht gelesen. Tech comm hingegen kann sich nicht mehr darauf verlassen, dass der Kunde das Produkt bereits gekauft hat. Viele Kunden werden ihre Kaufentscheidung auf der Grundlage der Qualität und Verfügbarkeit der Dokumentation treffen. Sie können es sich nicht leisten, diesen Aspekt der Verwendung von Dokumentation zu vernachlässigen. (Außerdem, sobald das Unternehmen herausfindet, dass technische Dokumente Leads generieren, wird Ihre Aktie im Unternehmen erheblich steigen.)
Leider gibt es viele ungeduldige Marketingleute, denen es schwer fällt, Tiefe oder Substanz zu produzieren, und viele mürrische Technikschreiber aus alten Zeiten, die es schwer haben, zu akzeptieren, dass sie Dinge schreiben müssen, die die breite Öffentlichkeit lesen wird, während sie eine Kaufentscheidung treffen. Aber beide Gruppen leben in der Vergangenheit. Im Content-Marketing-Zeitalter sind alle Inhalte Marketing-Inhalte, einschließlich (und manchmal besonders) Tech-Comm-Inhalte. Es ist alles eine Sache. Es sollte alles den gleichen Ton haben.
Versionshinweise sollten beschreiben, was sich aus Sicht der Benutzer geändert hat . Das bedeutet jedoch nicht unbedingt „alle blutigen technischen Details“. Wie bei anderen technischen Texten möchten Sie dem Benutzer sagen, was er wissen muss (und vielleicht ein bisschen mehr), aber Sie möchten ihn nicht mit unnötigen Details überfordern.
Wenn eine Version größere Themen enthält, können Sie auch eine kurze Einführung dazu hinzufügen. Hauptversionen verwenden manchmal die Versionshinweise, um beispielsweise wichtige neue Funktionen hervorzuheben. Diese sind weniger funktional orientiert und können eher das sein, was Sie als "Marketing" bezeichnen, aber die besten verwenden meiner Erfahrung nach einen Stil, der dem ähnelt, den Sie in der Übersicht der technischen Dokumentation verwenden würden. Versionshinweise sind kein Verkaufsinstrument.
Sehen Sie sich als Beispiel diese aktuellen Versionshinweise für Firefox an . Sie gelten für eine Hauptversion (58.0) und beginnen mit einem allgemeinen Absatz. Dann kommen sie zu den einzelnen Notizen – neue Verhaltensweisen, behobene Fehler usw. Jede davon ist benutzerorientiert, wie zum Beispiel:
Neu: Verbesserungen an Firefox-Screenshots:
- Kopieren Sie Screenshots und fügen Sie sie direkt in Ihre Zwischenablage ein
- Firefox-Screenshots funktionieren jetzt im Modus "Privates Surfen".Behoben: Schriftarten, die in nicht standardmäßigen Verzeichnissen installiert sind, werden für Linux-Benutzer nicht mehr leer angezeigt
Entwickler: Implementierte die PerformanceNavigationTiming-API
Firefox hat auch Versionshinweise für Entwickler , die die Hinweise nach Komponenten aufteilen und mehr Details (und mehr Links) enthalten. Entwickler sind eine andere Zielgruppe als Endbenutzer; Wie bei Ihrer anderen Dokumentation müssen Sie den Inhalt auf das Publikum kalibrieren.
Wenn Ihre Versionshinweise digital sind (nicht auf Papier), können Sie auch auf verwandte Informationen verlinken. Im Firefox-Beispiel ist das über die PerformanceNavigationTiming-API ein Link. Die Versionshinweise meines Teams verweisen manchmal auf bestimmte Themen in unserer Dokumentation. Die Versionshinweise für Visual Studio Code veranschaulichen diesen Stil. (Danke an Bob für den Hinweis auf einige Beispiele in einem Kommentar.)
In einem Kommentar zu der Frage hat jemand Versionshinweise erhoben, die aus Kommentaren zum Einchecken des Codes generiert wurden. Solche Versionshinweise sind eher ein Änderungsprotokoll, da sie alle Änderungen "wie sie fielen" zeigen. Die Art von Veröffentlichungshinweisen, von denen ich spreche und nach denen Sie meiner Meinung nach fragen, sind höher als das und erfordern eine Destillation.
Schreiben Sie für das Publikum und verwenden Sie dabei die Stimme, die ihnen am besten hilft, die Bedeutung und Bedeutung der Versionshinweise zu verstehen.
Wenn es mehr als eine Zielgruppe gibt (z. B. Endbenutzer und API-Benutzer), schreiben Sie separat für sie.
Ich stimme Marks Argumenten zu, dass die Unterscheidung im aktuellen Modell, wie Ihr Publikum Ihre Inhalte findet, weniger wichtig wird. Secespitus spielt darauf an, wie wichtig es ist, sein technisches Publikum nicht zu verärgern, was meiner Meinung nach auch eine gute Sache ist, die man im Hinterkopf behalten sollte.
Ich würde Marks Ansatz übernehmen, keinen sprachlichen Unterschied zu machen und sicherzustellen, dass neue Benutzer, die bei der Suche auf die RNs stoßen, genügend kontextbezogene Informationen über das Produkt finden. Um Ihre bestehenden Benutzer nicht mit einführenden Informationen zu verärgern, die möglicherweise als „Flausch“ empfunden werden, sollten Sie dies in ein Einführungsthema unterteilen. Erfahrene Benutzer können es direkt überfliegen, um zu sehen, was sich in der letzten Version geändert hat, während neue (oder potenzielle) Benutzer den Kontext erhalten, den sie benötigen, um den Rest des Inhalts besser zu verstehen.
Meiner Meinung nach sollten Versionshinweise in einem technischen Stil geschrieben werden, der sich auf die technischen Auswirkungen der neuesten Änderungen konzentriert. Dies macht sie zu einer Art Mischung zwischen den beiden Welten - Sie möchten Entscheidungsträger und Techniker ansprechen und ihnen mitteilen, was sich im Vergleich zur älteren Version der Software geändert hat, und betonen, welche Probleme sich aus diesen Änderungen ergeben können oder welche Die Probleme sind, dass diese Änderungen behoben werden.
Sie wollen den Entscheidungsträgern nicht die neusten Features und das ganze Produkt verkaufen – sie haben das Produkt bereits gekauft und wollen wissen, ob ihnen der Umstieg auf die neue Version zu viel kostet oder ob die Fixes die Update-Kosten kompensieren.
Sie wollen das Produkt auch nicht an Techniker verkaufen – sie wollen wissen, was sich an ihrer täglichen Arbeit durch den Einsatz der neuen Version ändert.
Aber Sie möchten es für alle, die mit der alten Version der Software vertraut sind, einfach und schnell verständlich machen.
Dies hängt von der Art der Software ab, die Sie bereitstellen, und von Ihrem Publikum.
Ich habe mehr als 10 Jahre in der Embedded-Entwicklung verbracht und viele Versionshinweise geschrieben. In meinem Unternehmen haben wir die Release Notes für ein neues Software-Release direkt aus dem Ticket-Tool heraus erstellt. Der Inhalt sah also so aus:
Produktname
V1.2.3.4
V1.2.3.5
usw.
Meine Zielgruppe waren andere Entwickler, die auch die technischen Details kannten und sich von Marketing-Blabla nicht beeindrucken ließen.
Wenn Ihre Zielgruppe eher auf der Marketingseite liegt, überlassen Sie das „Design“ der Release Note dem Marketing und geben Sie nur die Daten an. Sie sind meistens besser darin, nicht technisch klingende Dokumente zu schreiben. Wir hatten eine separate Marketingabteilung. für diese Dokumente.
Versionshinweise sollten mit der gleichen Stimme geschrieben werden wie das Benutzerhandbuch, die Online-Hilfe und andere Dokumentationen – wenn sie dieselbe Zielgruppe haben – da der gesamte Dokumentationsinhalt (mehr als „Sprache“) auf den Bedürfnissen der Zielgruppe, dem Verständnisniveau, und Zweck.
Als ich Versionshinweise für die Citrix Metaframe-Software schrieb, enthielten die Hinweise Inhalt, Detailtiefe, Sprache und Terminologie, die für Netzwerkadministratoren geeignet waren, da sie die Zielgruppe waren. Als ich „Read Me“-Dateien für Mac-Grafiksoftware schrieb, verwendete ich Sprache, Details und Tonfall, die für Endbenutzer und Administratoren (von einem Ein-Personen-Grafikdesign-Shop bis zu Boeing-Ingenieuren) geeignet waren, denn das war derjenige, der lesen würde Sie.
„Technisch“ muss nicht dicht, flach und passiv sein. Präzision und Klarheit stehen nicht im Widerspruch zu einfach und verständlich; Sie sind gleich. Benutzerfreundlich muss nicht volkstümlich oder informell sein.
Ich denke, die eigentliche Antwort lautet: Scheuen Sie sich nicht, das Wort „Sie“ zu verwenden – sprechen Sie mit dem Leser – sogar in den technischen Versionshinweisen. Stellen Sie nur sicher, dass Sie wissen, wer „Sie“ ist.
Monika Cellio