Stoff reduzieren

Ist weniger mehr? – Lehrstoff sinnvoll reduzieren

Titelseite: Ritter-Mamczak "Stoff reduzieren"

Titelseite: Ritter-Mamczak „Stoff reduzieren“

Vor mir liegt nun also ein Arbeitsbuch für die Lehrpraxis an Hochschulen. „Stoff reduzieren“ von Bettina Ritter-Mamczek war der Auftakt zur Reihe „Kompetent lehren“ des UTB-und Budrich-Verlages, in der mittlerweile 8 Bücher erschienen sind. Im Mittelpunkt steht – ganz dem Zeitgeist entsprechend – der Lernende. Wie kann ich Wissen so aufbereiten, dass der Lernende den größtmöglichen Nutzen daraus zieht?
Die Autorin ist selbst seit 19 Jahren als Dozentin und Moderatorin tätig. Sie liefert einen Überblick über Lehrkonzepte und gibt zahlreiche Tipps zur Planung von Lehrveranstaltungen.  Dabei geht es nicht nur um Stoffreduzierung sondern auch um durchdachte Lehrorganisation. Das Buch startet mit einer notwendigen Begriffserklärung als Schnelleinstieg und versammelt dann Konzepte zur Veranstaltungsplanung, insbesondere sog. Fachlandkarten. Zur Veranschaulichung fließen immer wieder Beispiele aus der Praxis ein. Aufgelockert wird das Ganze mit Handzeichnungen.

Hält sich das Buch an seine eigenen Regeln?

Stellenweise fällt es schwierig, sich einen endgültigen Masterplan herauszufiltern. Die Autorin nennt so viele Konzepte und teils sich überschneidende Fragelisten zur Planung, dass ich mich frage, wo ich am besten anfangen soll. Hier liegt es dann doch am Leser selbst, sich daraus einen geeigneten Plan zurechtzubasteln. Aber genau das muss nicht immer ein Nachteil sein. Die Autorin beschränkt sich nämlich nicht nur auf klassische Lehrmethoden, sondern bedient sich auch beim Projektmanagement (s. SMART-Konzept). Die Stärke des Buchs liegt dabei klar in den praxisrelevanten Beispielen und Übungen. Der Leser wird dazu angehalten, die eigene Arbeit im Hinblick auf das Beschriebene zu überdenken oder in Übungen zu erproben. Dadurch stellt sich schnell eine gewisse Routine in der Aufbereitung von Lehrinhalten ein.

Und was nützt das im Unternehmen?

Schön und gut, jetzt habe ich gelernt, wie ich Studenten und Schülern sinnvoll Wissen vermittle. Aber kann ich dieses Wissen auch in anderen Bereichen anwenden? Ein Blick über den Tellerrand lohnt sich. Die vorgestellten Konzepte lassen sich ganz klar auf die Arbeit im Unternehmen und den Redaktionsalltag übertragen. Immer wieder muss ich mich beim Schreiben eines Artikels fragen: Wer sind meine Leser, was meine Ziele, und was ist das zentrale Thema? Das letzte Kapitel widmet sich dieser Problematik und liefert Vorschläge für auftauchende Fragen. Außerdem sind Workshops und Seminare auch bei uns im Unternehmen immer ein Thema. Dafür kann man sich hier bedenkenlos bedienen.

Ein Nachschlagewerk für Wissensvermittlung

Der Tatsache geschuldet, dass das Buch in einer Reihe erschienen ist, werden einige Aspekte nicht behandelt. Es geht nicht darauf ein, wie man Inhalte veranstaltungsübergreifend vorbereitet, was bei heterogenen Gruppen zu beachten ist oder  welcher Medieneinsatz sinnvoll ist. Hier liegen dann auch die Grenzen für mich als Redakteurin im Unternehmen oder Leiterin von Workshops, wo eine homogene Zielgruppe doch eher die Ausnahme ist. Nichtsdestotrotz liefert das Buch einen hervorragenden Einstieg in das Thema. Es richtet sich an Einsteiger und Geübte gleichermaßen, wobei letztere dabei vor allem zur Reflexion ihrer bisherigen Lehrgestaltung angeregt werden. Sollte ich mal vergessen haben, worauf es ankommt, kann ich mich mit diesem Buch immer wieder daran erinnern.

Literatur:  Bettina Ritter-Mamczek [2016; 2. Aufl.]: Stoff reduzieren. Methoden für die Lehrpraxis. Verlag Barbara Budrich, Opladen und Toronto. ISBN 978-3-8252-4462-0
Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als elektronisches Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

Gehörige Horizonterweiterung – Wie Bürger- und Kundenkommunikation gelingen kann

Die Qualität eines Textes kann nicht losgelöst von der kommunikativen Funktion bestimmt werden. Während ich in diesen Wochen ein kommunales Serviceunternehmen dabei unterstütze, seine Kundenanschreiben hinsichtlich Verständlichkeit, Prägnanz und Leserbezug einer Generalüberholung zu unterziehen, liegt das „Handbuch Bürgerkommunikation“ griffbereit neben mir auf dem Schreibtisch. Aus ihm stammt der eingangs zitierte Satz. Ihn kann ich aus meiner Erfahrung in der Beratung von Kommunen, Banken, Krankenkassen und Versicherungen nur unterschreiben. Und er spielt auch in meinem aktuellen Projekt eine Rolle.

Wesentlich mehr als ein Ratgeber

Das Handbuch Bürgerkommunikation: Es fasst die Erfahrungen und fachlichen Grundlagen eines großangelegten Projekts der Stadt Arnsberg zusammen, die schon vor über zehn Jahren zusammen mit einem linguistisch kompetenten Beratungsteam daran ging, ihren Sprach- und Schreibstil systematisch auf größtmögliche Bürgernähe hin auszurichten. Und das mit Erfolg. Das Handbuch Bürgerkommunikation ist damit ein gutes Beispiel dafür, wie sprachwissenschaftlich fundierte Kommunikationskonzepte einen entscheidenden Unterschied machen.

Dieses Attribut „wissenschaftlich“ ist es auch, das für mich den großen Mehrwert dieses Buches gegenüber anderer Literatur im Bereich Textoptimierung ausmacht – vor allem gegenüber der klassischen Ratgeberliteratur. Es geht nicht um ein bisschen mehr „Pfiff“ oder einen „lockeren Stil“ – sondern alles, was gefordert und geraten wird (und das passiert durchaus mit ganz konkreten Beispielen und Empfehlungen), steht auf soliden fachlichen Füßen. Und so bilden die Basis dieses Buches und seiner insgesamt neun Module (Kapitel) auch nicht die erwartbaren Stilblüten und Schenkelklopfer aus dem Fundus deutscher Behördenpublikationen, sondern Themen wie „Modelle der Textverständlichkeit“ (Modul 1), „Soziale Klugheit“ (Modul 3) oder „Instrumente der Identitätskommunikation“ (Modul 7).

Sparringspartner für harte Nüsse

Das zeigt schon: Ganz einfache Kost ist dieses Buch nicht. Es geht um Sprachwissenschaftliches, Kommunikationswissenschaftliches, Soziologisches und auch (Staats-)Philosophisches. Und es gibt Nebentöne, die in der mitunter stark auf Effizienz getrimmten Debatte um die Optimierung von Kommunikation eher ungewöhnlich sind, z. B. wenn es um die gesellschaftliche Verantwortung von Kommunizierenden geht.

Mein Fazit: Wer mehr als bloß ein paar Tipps zur Bürger- und Kundenkommunikation sucht, wer als Profi einen weiten Horizont benötigt und tiefer verstehen möchte, weil er nur so zu wirklich passenden Lösungen findet: Dem kann ich dieses Buch nur empfehlen.

Ich werde es auf jeden Fall noch einmal intensiv durcharbeiten. Und es dabei auch befragen zu Innovationsthemen, die in unseren Projekten zunehmend wichtig werden. Zum Beispiel wie sich das Konzept der Leichten Sprache noch wirkungsvoller in die Bürger- und Kundenkommunikation integrieren lässt.

Literatur: Ebert, Helmut/Fisiak, Iryna [2016]: Handbuch Bürgerkommunikation: Moderne Schreib- und Kommunikationskultur in der Dienstleistungsverwaltung. LIT Verlag, Berlin, 331 Seiten. 978-3825887575

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

API-Dokumentation – Was brauchen und wollen Entwickler?

Code ist undokumentiert schwer zugänglich
(c) Markus Vogelbacher via pixelio.de

Heute freuen wir uns, wieder einmal eine Gastautorin im doctima-Blog zu begrüßen. Stephanie Steinhardt ist Dipl. Technik-Redakteur (FH) und wissenschaftliche Mitarbeiterin an der Hochschule Merseburg. Als freiberufliche Technik-Redakteurin betreut sie außerdem verschiedene Kunden z. B. aus dem Automobilbereich. In ihrem Post zeigt Sie uns erste Ergebnisse aus einer gemeinsamen Forschungsarbeit mit Prof. Dr. Michael Meng und Andreas Schubert (MA) an der HS Merseburg. Doctima ist an diesem Projekt als Vernetzungspartner beteiligt.

Die Sicht von Entwicklern auf API- Dokumentation ist oftmals sehr verschieden. Während die einen davon überzeugt sind, dass guter Code keiner Dokumentation bedarf, schreiben die anderen selbst gern Dokumentation und konsultieren sie auch häufig. Die Meinungen darüber, wie sie denn aussehen soll, die perfekte API-Dokumentation, gehen ebenfalls auseinander. Es existieren unterschiedliche Ansätze zu Aussehen, Darreichung und Inhalt einer solchen.

An der Hochschule Merseburg widmet sich seit zwei Jahren ein kleines Team von Technik-Redakteuren in einem Forschungsprojekt der Optimierung von API-Dokumentation. Die Fragen nach Struktur und Inhalt der perfekten API-Dokumentation sowie nach dem Leseverhalten der Entwickler stehen dabei im Mittelpunkt der Untersuchungen. Auf Basis von 23 durchgeführten Interviews, der Erhebung von Daten aus rund 100 Fragebögen und einer Beobachtungsreihe, bei der genau verfolgt wurde, wie Entwickler Programmieraufgaben lösen, sowie unter Berücksichtigung der bereits existierenden Studien im Umfeld von Entwicklerdokumentation können wir Empfehlungen geben, die API-Dokumentationen deutlich besser und effizienter nutzbar machen.

Nicht jeder Entwickler ist wie der andere.

Entwickler unterscheiden sich nicht nur in ihrer Einstellung zur Dokumentation, in den Jahren ihrer Programmiererfahrung oder bezüglich der Systemwelt, in welcher sie zu Hause sind. Sie unterscheiden sich vor allem in ihrer Arbeitsweise. So konnten wir in unseren erhobenen Daten zwei verschiedene Ansätze identifizieren, welche vor allem bei der Einarbeitung in eine neue API deutlich hervortreten. So gibt es Entwickler, die einen eher codegetriebenen Ansatz verfolgen und nach eigener Aussage gern direkt mit einem Code-Beispiel einsteigen. Sie erarbeiten sich den Umfang einer API eher intuitiv von unten nach oben. Es gibt aber auch Entwickler, die konzeptorientiert arbeiten und sich vor der Nutzung einer neuen API zunächst einen Überblick verschaffen. Entwickler, die der Meinung sind, dass es nützlich ist, das Konzept der API in Gänze zu verstehen, auch wenn nur ein Teil der API tatsächlich zur Problemlösung genutzt wird.

Abb.: 1 – Absolute Zeitwerte: Recherchezeit (farbig) vs. Bearbeitungszeit (grau) der Probanden 01-11

Besonders deutlich traten diese Verhaltensmuster in der von uns durchgeführten Beobachtungsreihe hervor. So haben 6 der 11 beobachteten Probanden im Konzeptbereich der API-Dokumentation unserer Test-API gelesen, wohingegen die anderen 5 kaum einen Blick hinein warfen und vorrangig auf Beispielcode fixiert waren.

Lesen ist nicht gleich lesen.

Trotz der gegensätzlichen Sichtweisen der Entwickler auf API-Dokumentation hat die Beobachtung gezeigt, dass im Beobachtungszeitraum von jeweils einer Stunde alle Probanden nahezu die Hälfte der Zeit mit der Recherche in der API-Dokumentation zubrachten, während die andere Hälfte für die tatsächliche Programmierung zur Lösung der Aufgaben verwendet wurde.

Wie die Analyse der entstandenen Eyetracking-Aufnahmen zeigte, scannten und überflogen die Entwickler die einzelnen Inhalte mehr, als dass sie tatsächlich Zeile für Zeile lasen. Dabei fokussierten Sie vorrangig auf die visuell hervorgehobenen Elemente, wie Hyperlinks, die Navigation und Beispielcode. Der erklärende Fließtext wurde meist nur dann gelesen, wenn aus dem Beispielcode allein keine Lösung abzuleiten war.

Das Leseverhalten schien darüber hinaus nicht nur beeinflusst von der individuellen Arbeitsweise, sondern war auch geprägt von der Einschätzung zum Schwierigkeitsgrad der gestellten Aufgabe. Bei Aufgaben, die schwieriger zu lösen schienen, waren die Probanden eher geneigt zu lesen, als bei Aufgaben, die einfacher wirkten.

Wer die Prozesse kennt, ist klar im Vorteil.

Bereits in den Interviews und in existierenden Studien kam zum Vorschein, dass mitunter alleinige Programmiererfahrung kein Garant ist für die schnelle Einarbeitung in eine neue API. Vielmehr entscheidend ist das vorhandene Domainwissen. Wer mit den zugrunde liegenden Prozessen vertraut ist, welche die API abbildet und dazu das Fachvokabular kennt, ist deutlich schneller bei der Einarbeitung und Lösung von Programmieraufgaben. Das zeigte auch unsere Beobachtungsreihe sehr eindrücklich (vgl. Abbildung 1 – Probanden 03, 04, 05,06 und 10 besaßen Domainwissen).

Demnach kommt der Vermittlung von Domainwissen in einer API-Dokumentation eine wichtige Rolle zu. Die Platzierung dieser Informationen ist mit Hinblick auf Leseverhalten und Arbeitsweise der Entwickler elementar.

Abb.: 2 – Beispiellayout für Codekommentare im Beispielcode (adaptierter Inhalt, basierend auf https://developers.shipcloud.io/reference/)

Der beste Ort für wichtige Informationen in einer API-Dokumentation ist einer, den alle Entwickler tatsächlich anschauen. Auf Basis der Interviews, den Fragebögen und der Beobachtung können nur Codebeispiele dieser Anforderung genügen. Sie werden von allen Entwicklern angesehen und als Basis der eigenen Programmierung verwendet. „Verkleidet“ man wichtige Informationen als Codekommentar und setzt diese deutlich vom restlichen Codebeispiel ab, kann man sicher sein, dass sie gesehen und, wenn kurz, auch gelesen werden. Auf ausführlichere Beschreibungen sollte zugunsten der eher konzeptorientierten Entwickler aber dennoch nicht verzichtet werden.

Dieser konkrete Optimierungsvorschlag und die zuvor genannten Erkenntnisse sind natürlich nur ein kleiner Teil der bisher gewonnenen Forschungsergebnisse. Unsere Untersuchungen dauern im Moment noch an. Daher sind wir auch sehr interessiert an Unternehmen, die bereit sind, sich an ähnlichen Studien zu beteiligen und damit die Zahl der möglichen Probanden vergrößern.

Kontakt: stephanie.steinhardt@hs-merseburg.de

Türkische Kulturwissenschaft für Technische Redakteure?

Fachbuch für Übersetzer. Und für Technische Redakteure?

Fachbuch für Übersetzer. Und für Technische Redakteure?

An dieser Stelle haben wir bereits von der Bedeutung interkultureller Kompetenz bei Technischen Redakteuren gesprochen. Heute liegt ein Buch (Mehmet Tahir Öncü: Kulturspezifische Aspekte in technischen Texten) zur Rezension auf unserem Schreibtisch, das eigentlich für (Fach-)Übersetzer gedacht ist. Mit seiner kulturvergleichenden Analyse von Gebrauchsanleitungen könnte es aber auch eine interessante Quelle für die Technische Redaktion sein.

Fachübersetzer müssen neben fremdsprachlichem Wissen in einem fachlichen Bereich auch über ein Bewusstsein für die kulturellen Besonderheiten der Sprachgemeinschaft verfügen. Wer Land und Leute, Sprache und Kultur kennt, kann Übersetzungsfehler vermeiden.

Eine Hilfestellung für den türkischsprachigen Raum möchte Mehmet Tahir Öncü mit seiner Habilitationsschrift vor allem Übersetzern bieten. Doch auch für Technische Redakteure ist sie ein nützliches Nachschlagewerk, und zwar nicht nur in Bezug auf  türkischsprachige Anleitungen.

Worum geht es?

Öncü setzt sich mit seinem Werk „Kulturspezifische Aspekte in technischen Texten“ zwei ehrgeizige Ziele – gleichzeitig kommt seine Arbeit, laut seinen Worten, einer Pionierarbeit gleich, da es noch kein ähnliches Unterfangen im Bereich des Fachübersetzens gibt:

  • Er möchte neue  Ergebnisse für die systematische Analyse mono- und multilingualer Gebrauchsanleitungen liefern.
  • Er will spezifische Eigenschaften auf Text- und Satzebene von deutsch- und türkischsprachigen Anleitungen aufzeigen.

Öncü richtet sich damit in erster Linie an Fachübersetzer, die für den türkischsprachigen Raum deutsche Gebrauchsanleitungen übersetzen. Dazu untersucht er Gebrauchsanleitungen der beiden Sprachen von nationalen und internationalen Herstellern von Haushaltsgeräten.

Kurzer Vergleich  der deutschen und türkischen Kultur

Das Buch besteht wie jede gute wissenschaftliche Arbeit aus einem Theorie- und einem darauf aufbauenden Empirieteil. Nachdem er den Begriff „Kultur“ im Theorieteil kurz umrissen hat, vergleicht Öncü die deutsche und türkische Kultur mithilfe des häufig für  Analysen zugrunde gelegten Fünf-Dimensionen-Modells nach Hofstede, das (bis dahin) als einziges die türkische Kultur einbezieht.  Die fünf Dimensionen umfassen:

  1. Machtdistanz/Soziale Distanz
  2. Kollektivismus vs. Individualismus
  3. Unsicherheitsvermeidung
  4. Maskulinität vs. Feminität
  5. Langfristige vs. kurzfristige Orientierung

Öncü stellt in seinen Vergleichen fest, dass in nahezu allen Dimensionen Unterschiede in den beiden Kulturen bestehen. Um dem Thema „Übersetzen“ treu zu bleiben, erklärt er danach die Eigenheiten der Übersetzungsmechanismen in Deutschland und in der Türkei. So zeigt er zum Beispiel die unterschiedlichen Einflüsse für Übersetzungen, die durch verschiedene Wahrnehmung von Zeit oder Machtdistanzen entstehen und wie diese die Kommunikation prägen. Nach diesem Einblick in die deutsch- und türkischsprachige Kulturwissenschaft geht Öncü kurz auf universelle und kulturspezifische Eigenschaften von Gebrauchsanweisungen ein. Um seinen Untersuchungsgegenstand „Gebrauchsanleitungen“ definieren zu können, erläutert er Fachtextsorten und deren Konventionen. Öncü definiert die Textsorte „Gebrauchsanleitung“  als Mittel der Massenkommunikation und grenzt sie als Textsorte unter der Sammelbezeichnung „Technische Dokumentation“ ab. Er attestiert dieser Textsorte eine „Kulturgebundenheit“, also eine Abhängigkeit zur jeweiligen Kulturgemeinschaft, für bzw. in der sie verfasst wurde.

Praktische Erkenntnisse für Übersetzer und Technische Redakteure?

Seine Analysen im Empirieteil konzentrieren sich auf die Bereiche der Text- und Satzebene. Vor allem für Übersetzer, aber auch für Redakteure,  sind die Ergebnisse auf Textebene interessant. Hier legt er den Schwerpunkt auf die Makrostruktur, Sprechakte und den Personeneinbezug. Ein beispielhafter Einblick in seine Ergebnisse zum Bereich der Sprechakte:

Es mag manch einen erstaunen, dass die deutschsprachigen Anleitungen der Untersuchung mehr Direktive (Aufforderungen, Befehle, Bitten) aufweisen als die türkischsprachigen. Diese verwenden im Vergleich zu den deutschsprachigen Anleitungen verhältnismäßig mehr Repräsentative, die ja Feststellungen, Beschreibungen, Behauptungen und Vermutungen beinhalten. Öncü deutet dies als Zeichen einer hohen Machtdistanz,  da mit den Repräsentativen eine Art Entwicklerperspektive eingenommen wird und der Anwender den „Entwicklern“ scheinbar weniger dominant gegenübersteht. Die deutschsprachigen Anleitungen stellen analog eine „Anwenderperspektive“ dar.

Fazit: Querschnitt für Übersetzer und Technische Redakteure

Das Buch eignet sich durchaus für Übersetzer bzw. Technische Redakteure, die für den türkischsprachigen Raum arbeiten. Der Leser kann wertvolle Hinweise für die Übersetzung finden – allerdings muss man diese tatsächlich suchen, da sie leider – dem Ziel des wissenschaftlichen Schreibens erliegend – nur schwer im Text aufzufinden sind. Unter den Ergebnissen im Empirieteil finden sich immer wieder nützliche Informationen zu kulturspezifischen Eigenheiten türkischsprachiger Anleitungen. Diese Informationen können auch herangezogen werden, wenn ein Konzept für eine Gebrauchsanleitung für den türkischsprachigen Raum erstellt werden soll.

In diesem Sinne ist das Buch auch Technischen Redakteuren dienlich, die nichts mit der Übersetzung zu tun haben und nicht speziell für den türkischsprachigen Raum Anleitungen erstellen – denn der kleine Rundumschlag Öncüs zu textuellen und sprachlichen Eigenschaften deutschsprachiger Anleitungen kann auch der eigenen Arbeit nützen.

Also: Kein Thema für eine breite Masse; aber hilfreiche Ergebnisse sowohl für deutsch- als auch türkischsprachige Gebrauchsanleitungen. Inwiefern man im Arbeitsalltag darauf zurückgreift, bleibt offen. Im Sinne nutzerorientierter Anleitungen wäre ein belegbarer Zusammenhang zwischen Direktiven und Verständlichkeit interessant; dies war aber nicht im Fokus der Arbeit und verlangt eine andere Zielstellung und Methodik.

Literatur: Öncü, Mehmet Tahir: Kulturspezifische Aspekte in technischen Texten. FFF – Forum Fachsprachen Forschung, Bd. 109. Verlag Franck & Timme, Berlin, 212 Seiten. ISBN 978-3-86596-517-2

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

Wachsende Kritik…

Wir wachsen an der Kritik, nicht am Applaus. (c) Refe http://getrefe.tumblr.com/

Wir wachsen an der Kritik, nicht am Applaus.
(c) Refe http://getrefe.tumblr.com/

Zum zweiten Mal beteiligen wir uns an einer Blog-Parade der PR-Doktorin Kerstin Hoffmann. Diesmal zu einem Thema, das uns Herzen liegt, gerade weil es oft nicht einfach ist.

Angebot und Nachfrage

„Kritik“ habe ich einmal gelesen „ist die einzige Sache, die jeder gerne gibt und niemand bekommen will.“ Das klingt im ersten Moment überzeugend. Ist es aber nicht. Tatsächlich habe ich die Erfahrung gemacht, dass es sehr schwierig ist, gute Kritik zu bekommen (und genauso sehr schwer gute Kritik zu geben). Kritik – und ich spreche hier von wirklicher Kritik und nicht von irgendwelchen Meckereien – ist ein rares Gut, das man gezielt suchen sollte. Denn Kritik ist – wie man im Englischen sagt – ein „acquired taste“.

Kritiker finden

Die meisten Leute kritisieren meiner Erfahrung nach nicht gerne. Ein Beispiel: Bei doctima lasse ich Texte gerne von unseren Praktikanten und Praktikantinnen gegenlesen. Das hilft mir bei der Überarbeitung der Texte und schärft den Blick bei Einsteigern in der Redaktion. In diesen Situationen habe ich dann folgendes oft erlebt. Einen Text, den ich selbst als eher vorläufig eingeschätzt habe, bekomme ich mit lediglich ein paar Kommakorrekturen und stilistischen Anmerkungen zurück. Frage ich dann konkret nach, wie die Korrektoren eine (eher schwache) Stelle fanden, kommt als Antwort: „Das habe ich nicht kapiert, aber das liegt an mir.“ – Nein, liegt es nicht! Wenn ein Text nicht verstanden wird, und er ist für diese Zielgruppe gedacht, dann liegt es nie am Leser, wenn er oder sie ihn nicht versteht.

Kritik fördern

Mittlerweile gebe ich unseren Praktikanten vor ihren ersten Textkorrekturen ein kleines Briefing. Da sage ich dann ganz deutlich, dass ich natürlich auch Bescheid wissen will, wenn mein Text Rechtschreibfehler aufweist oder stilistisch schwach ist. Viel wichtiger  ist mir aber, ob er nachvollziehbar gegliedert ist, ob meine Argumente stichhaltig sind und ob ich sie verständlich rübergebracht habe.

Kritik sollte man ermuntern, nicht verhindern. Letzten Endes sollte man sich und andere zu guten Kritikern erziehen. Und: Gute Kritiker sollte man sich merken. Ich weiß mittlerweile sehr genau, wen ich frage, wenn es bei einem Text darauf ankommt, wenn ein Seminarkonzept noch den letzten Schliff braucht oder wenn eine Social Media Strategie wirklich rund laufen muss.

Kritik schätzen

Kritik wird zu wenig geschätzt. Das merke ich auch immer wieder in unseren Social Media Trainings. Gerade Marketing-Experten fragen dort z. B. oft: „Wie gehe ich mit negativen Beiträgen im Blog um?“ „Ernst nehmen, als Dialoganlass wertschätzen, auf seine Berechtigung prüfen und – wenn nötig umsetzen.“ antworte ich dann meistens. Denn jeder, der kritisiert, sucht immer noch den Dialog und gibt uns eine Chance an der Kritik zu wachsen. Schlimm ist die Kritik, die uns nicht mehr erreicht.

Viele Social Media Manager verbuchen Kritik am eigenen Produkt als „negative sentiment“ und damit als schlecht. Das hat sicher seine Berechtigung, denn Kritik ist nun mal kein Lob. Aber: Kaum ein Social Media Manager erfasst in seinem Controlling negative Kritik als „Innovation“ oder „Idee zur Produktverbesserung“. Das ist aber, was Kritik eigentlich ist. Etwas, das wir wertschätzen sollten.

Feedback, bitte! – Warum Technische Redaktion keine Einbahnstraße sein sollte

Martin Häberle arbeitet als Technischer Redakteur für ein mittelständisches Software-Unternehmen und ist Lehrbeauftragter an der Hochschule Gießen im Studiengang „Technische Redaktion und Multimediale Dokumentation“ für Wiki-basierte Dokumentation. Zu diesem Thema ist er auch als Berater, Trainer und Autor u.a. für die K15t Software GmbH tätig.

(c) K15t Software

(c) K15t Software

Lange Zeit war Technische Redaktion eine Einbahnstraße. Wir schickten Informationen in die eine Richtung, und aus der anderen kam nichts zurück. Doch in Zeiten des Web 2.0 ist das zu wenig. Technische Redakteure müssen heute kommunizieren und interagieren können – auch mit ihren Lesern. Feedback hilft ihnen dabei, Technische Inhalte nutzergerecht zu erstellen und kontinuierlich zu verbessern. Anstelle der Einbahnstraße ist Technik-Kommunikation heute ein iterativer Prozess, funktioniert also eher wie ein Kreisverkehr.  Für diese neuen Redaktionsprozesse benötigen wir neue Werkzeuge – weg von Redaktionssystemen oder DTP-Werkzeugen, hin zu kollaborativen Plattformen.

Lesen Sie in diesem Artikel, warum Feedback so wichtig ist, um hilfreiche Inhalte zu erstellen und wie Web-basierte Kollaborationswerkzeuge sowohl internes Feedback als auch Kundenrückmeldungen für Technische Dokumentation ermöglichen.

Gutes Feedback ist mehr als Lob

Feedback hat hier im Südwesten Deutschlands wenig Tradition. Denn in meinem Heimatland Baden-Württemberg heißt es „Net g’schimpft isch genug g’lobt“ und das bedeutet in der Praxis, dass man sehr wenig Feedback bekommt – sei es nun Lob oder Kritik. Dabei ist Rückmeldung wichtig, um besser zu werden! Gerade als Technischer Redakteure sind wir auf Feedback angewiesen. Nur so können wir hilfreiche Inhalte erstellen, die unsere Leser erwarten und den Nutzern Informationen bereitstellen, die sie wirklich benötigen.

Üblicherweise erhalten Technische Redakteure aber nur selten (nützliches) Feedback zu ihren Inhalten. Vielleicht kommen während der ohnehin viel zu kurzen Review-Phase ein paar handschriftliche Korrekturen von den Fachexperten hereingeflattert, und manchmal werden uns die Kollegen sogar mit ein paar erhellenden Erkenntnissen beglücken. Doch fast nie erhalten wir in der Technikkommunikation eine Rückmeldung von denjenigen, mit denen wir wirklich kommunizieren möchten: von den Leserinnen und Lesern.

Doch warum kommuniziert die Leserschaft nicht mit uns? Ein Grund für ausbleibendes Feedback ist, dass eine Beteiligung der Leserschaft in traditionellen Redaktionsprozessen entweder nicht vorgesehen ist oder nicht einfach und zuverlässig möglich ist. Erst die Web-2.0-Bewegung brachte entsprechende Web-basierte kollaborative Werkzeuge (z.B. Wikis) hervor – digitale Plattformen, auf denen Inhalte nicht nur konsumiert, sondern auch selbst erstellt werden können.

Moderne Web-basierte Plattformen gehen neue Wege, um Inhalte kollaborativ zu erstellen, zu überarbeiten und zu veröffentlichen. Dokumentation bereitzustellen ist damit nicht mehr länger ein Monolog gegenüber den Lesern, sondern wird zum Dialog. Der Technikredakteur wird endlich zum Technik-Kommunikator!

Der Content-Lebenszyklus „2.0“

In typischen Dokumentationserstellungs-Prozessen planen Technische Redakteure zunächst ihre Informationsprodukte, erstellen eine Struktur und recherchieren, bevor sie mit dem Erstellen der einzelnen Inhaltsbausteine loslegen. Die Entwürfe werden so lange angepasst und Überarbeitungen werden abgestimmt und zusammengeführt, bis jemand eine Freigabe erteilt und die Inhalte ins gewünschte Zielformat ausgegeben werden. Und schließlich gelangt die Dokumentation zu ihren Lesern.

(c) K15t Software

(c) K15t Software

Wenn wir einen kollaborativen Ansatz verfolgen, können wir noch eine fünfte Phase zu diesem Prozess hinzufügen: das aktive Einbeziehen unserer Leser („Engage“). Indem wir es ihnen ermöglichen etwas Inhaltliches beizutragen, schließt sich die Feedback-Schleife und wir beginnen miteinander zu kommunizieren. Auf Basis der Anregungen, Fragen und Wünschen ihrer Leser können Technische Redakteure ihre Dokumentation so kontinuierlich verbessern, wie dies beispielsweise in der agilen Software-Entwicklung praktiziert wird.

Im Wiki lässt sich jede Änderung nachverfolgen – der gesamte Prozess von der Erstellung bis zum Review wird transparent für alle Beteiligten. Und wenn wir Feedback sowohl beim internen Review als auch während der Nutzung der bereitgestellten Inhalte erhalten, dann wirkt sich das positiv auf die Qualität der Inhalte aus (entgegen einiger unhaltbarer Wiki-Mythen).

Feedback zu Inhalten im Entwurfsstadium

Während des internen Lektorats prüfen die eingeladenen Fachexperten unsere Inhalte. Sie kommentieren hier und dort, schließen ein paar Wissenslücken und klären inhaltliche Fehler und Missverständnisse mit den Technischen Redakteuren. Außerdem gibt es möglicherweise einen Schlussredakteur, der den Entwurf auch auf Sprache, Stil und Struktur prüft und dadurch eine gewisse Konsistenz und formale Richtigkeit sicherstellt. Schließlich wird der Entwurf freigegeben und publiziert.

In einer kollaborativen Plattform sind alle, die am Redaktionsprozess beteiligt sind, sprichwörtlich auf der gleichen (Wiki-)Seite. Soziale Funktionen wie Kommentare, ein „Gefällt mir“-Button oder die Möglichkeit, Inhalte einfach zu teilen, helfen den Nutzern, miteinander effizient zu kommunizieren und mit den Inhalten zu interagieren – sogar wenn die Beteiligten über verschiedene Standorte oder sogar Zeitzonen hinweg verteilt arbeiten.

Abhängig von der gewünschten Arbeitsweise ist die letzte Inhaltsversion entweder sofort online für die Nutzer verfügbar, oder es wird ein Freigabeschritt zwischengeschaltet.

Mit der Kollaborationsplattform Atlassian Confluence lassen sich beispielsweise Inhaltsfragmente aller Arten und Größen kommentieren, Überarbeitungen anregen und schließlich als gelöst markieren – und das mit wenigen Klicks und ohne das Browserfenster zu wechseln. Nutzer können Inhalte bei Bedarf hinzufügen, bearbeiten oder löschen. Dabei bleibt jede Änderung transparent und kann bei Bedarf auf eine vorherige Fassung der Seitenhistorie zurückgesetzt werden.

(c) K15t Software

(c) K15t Software

Über Erweiterungen, sogenannte Add-ons, können in diesem Unternehmens-Wiki Entwurfsversionen und freigegebene Versionen für Inhalte definiert werden. So ermöglicht beispielsweise die Erweiterung Comala Workflows, den Seiten einen Status zuzuweisen. Oder mit Hilfe des Add-ons Scroll Versions lassen sich freigegebene Inhalte bei Bedarf sogar in einen separaten Wiki-Bereich publizieren, der auf Wunsch öffentlich zugänglich ist. Darüber hinaus verwaltet dieses Add-on auf Wunsch auch mehrere Versionen und Varianten der Dokumentationsinhalte in einem zentralen Autorenbereich.

Diese Vorgehensweise ist an die Versionsverwaltung von Quellcode in der Software-Entwicklung angelehnt, wo in Entwicklungszweigen und Releases gedacht wird. Zunehmend verfolgen aber auch Technische Redakteure anderer Branchen diesen Ansatz, um Dokumentation agil erstellen und bereitstellen zu können.

Wege, wie wir von unseren Lesern lernen können

Die zweite (und spannendere) Art des Feedbacks kommt von den Leserinnen und Lesern, also all denen, welche die bereitgestellte Dokumentation auch tatsächlich nutzen um etwas zu lernen und um ein bestimmtes Problem zu lösen. Um deren Rückmeldungen effizient einzuholen, führt praktisch kein Weg an einer Web-basierten Plattform vorbei. Als Technische Redakteure können wir hier Bewertungs- und Kommentarfunktionen sowie Web-Analysewerkzeuge zu unseren Gunsten einsetzen.

Bewertungsfunktion für hilfreiche Inhalte
Am Naheliegendsten ist wohl die Verwendung einer Bewertungsmöglichkeit für die Nutzer der Dokumentationsinhalte. Technische Redakteure können über die Summe der Bewertungen eine Aussage über die Nützlichkeit der dargebotenen Inhalte erhalten – etwa auf einer Skala von 1–5 Sternen. In Confluence gibt es hierzu das Rate Macro, welches diese Funktion bietet.

Kommentare und Diskussionen
Manche Leser würden ausführlicheres Feedback in Form von Kommentaren hinterlassen – wenn wir es ihnen erlauben. Fehlt etwas, ist eine Information veraltet oder irreführend? Unsere Nutzer möchten vielleicht weiterführende Fragen stellen oder haben sogar selbst Antworten und Problemlösungen gefunden, die sie mit anderen Nutzern teilen wollen. Dies bereichert in vielen Fällen die von uns Technischen Redakteuren bereitgestellten Dokumentationsinhalte erheblich.

Die PHP-Dokumentation gewinnt beispielsweise erheblichen Nutzwert durch sogenannte „User-contributed notes“, also von Nutzern beigesteuerte Anmerkungen.

(c) K15t Software

(c) K15t Software

Andererseits können Nutzerbeiträge in großer Zahl auch eine echte Herausforderung für Technische Redakteure darstellen. Beim Software-Hersteller Atlassian, der seine Produktdokumentation im öffentlichen Confluence-Wiki bereitstellt, zeigte sich kürzlich, dass sich nur rund 20 % der Kommentare auf den Hilfeseiten direkt auf die Inhalte bezogen – der größte Anteil beinhaltete Support-Anfragen, Funktionswünsche etc. Dies führte dazu, dass das kollaborationsbegeisterte australische Unternehmen sich dazu entschied, dort die Kommentarfunktion vorerst zu deaktivieren.

Der zugehörige Blogpost, in dem Atlassian diese Entscheidung ankündigte, zeigt uns aber auch, wie gut Nutzerkommentare funktionieren und welchen Mehrwert sie bieten können. Mehr als 60 Personen kommentierten den Beitrag und diskutierten ihre Bedenken und Ideen mit den Atlassian-Verantwortlichen, die nicht nur in den Kommentarspalten den Dialog suchten.
In manchen Fällen mögen Kommentare also zu viel des Guten sein, aber sie sind definitiv etwas Gutes!

Detaillierte Webseiten-Zugriffsanalysen
Der dritte Weg, um an Feedback zu kommen führt über die Erhebung von Nutzerdaten. Mittels Web-Analysewerkzeugen wie Google Analytics können wir Technischen Redakteure beispielsweise schnell herausfinden, wie viele Nutzer unsere Web-basierte Dokumentation nach bestimmten Stichwörtern durchsuchen und wie lange Besucher auf den einzelnen Seiten verweilen. Web-Analysewerkzeuge sind wohl der leiseste Weg, um mehr über das Verhalten unserer „Kunden“ zu lernen.

Fazit

Erfolgreiche Technische Kommunikation ist mehr als Technische Redaktion. Dabei kommt es in hohem Maß auf das Nutzerfeedback an, damit wir passgenaue Inhalte für unsere Leserschaft erstellen können und um deren Informationsbedarf gemäß ihrer Erwartungen zu decken. Der beste Weg dorthin führt über kollaborative Methoden, die wir sowohl im internen Review-Prozess als auch zum Einholen von Kundenfeedback anwenden.

Viele Organisationen haben ein Enterprise-Wikis als optimale Plattform identifiziert, die beide Aspekte in einem Web-basierten Kollaborationswerkzeug vereint. Wenn wir Nutzer beim Erstellen und Optimieren von Inhalten beteiligen, so erhalten wir viel mehr ist als die Summe der einzelnen Bestandteile. Das gilt nicht nur fürs Web 2.0 allgemein, sondern auch für Technische Dokumentation.

Und wenn wir Technischen Redakteure aufmerksam in unseren Feedback-Kanal hineinhören, dann können wir möglicherweise sogar das eine oder andere Lob darin finden … 😉

Dieser Beitrag ist der erste Teil einer Artikelreihe im englischsprachigen Blog von K15t Software. Im nächsten Teil werden dort Lösungen vorgestellt, wie sich kollaborative Hilfeplattformen im Web bereitstellen lassen, damit wir als Technische Redakteure unsere Dokumentation auf die nächste Stufe bringen können.

Ergänzung doctima: Die deutsche Seite von Atlassian Confluence findet sich unter  https://de.atlassian.com/software/confluence.

Leseliste: Zielgruppen und Personatechnik

Die Zielgruppe im Fokus - mit der Personatechnik (c) patrisyu via http://www.freedigitalphotos.net/

Die Zielgruppe im Fokus – mit der Personatechnik
(c) patrisyu via http://www.freedigitalphotos.net/

Vorbemerkung: Mit diesem Post stellen wir unser neues Format „Leseliste“ vor. Die Leselisten sind kommentierte Linksammlungen, bei denen wir die – unserer Ansicht nach – interessantesten Internetressourcen zu einem Thema versammeln und kommentieren.

Und weil in der digitalen Welt alles im Fluss ist, werden wir die Leselisten regelmäßig überarbeiten und ergänzen. Dabei sind natürlich auch Ihre Links und Anregungen willkommen. Jeder Linktipp, den wir aufnehmen, wird selbstverständlich mit dem Namen des Tippgebers genannt. Starten wollen wir die Leselisten mit einer Sammlung zum Thema Personas als Zielgruppeninstrument.

Kritisch mit Personas (und Zielgruppen ganz allgemein) setzt sich Weiterlesen

Personas – ein Segen und ein Fluch

© Ruth Rudolph / pixelio.deEnde Februar haben Kyra Edeker und Jan Moorman im UXMagazin einen Beitrag gepostet, den ich aus zwei Gründen interessant finde. Die Autorinnen beleuchten in knapper Form die mittlerweile 30-jährige Geschichte der Personas und verlinken dazu – quasi als Bonus – eine ansprechende Infographik. Zum anderen setzen sie sich im Detail mit der zunehmenden Kritik zu Personas auseinander, die in der UX-Gemeinde in letzter Zeit laut wird. Was bedeutet die Kritik für die Zielgruppenarbeit in der Technischen Redaktion? Weiterlesen