tekom Frühjahrstagung 2012 – Experience Design

So, bevor ich in mein wohlverdientes Wochenende bei 26°C entschwinde, hier noch schnell die ersten Eindrücke, so lange sie noch frisch sind 😉

Ich war bisher noch auf keiner Frühjahrstagung, aber da sie diesmal in meiner schönen Heimatstadt Karlsruhe stattfand, gab es keine Ausrede. Erster Eindruck: sehr familiär im Vergleich zur riesigen Jahrestagung. Die Frühjahrstagung ist einige Nummern kleiner. Den bleibendsten Eindruck des ersten Tages hat die Keynote gemacht:

Marc Hassenzahl „Freude durch Technik? Vom Vermeiden von Problemen zum freudvollen Erlebnis“ 

Die Tagung begann mit einem „Exoten“ unter all den  Redakteuren, wie er sich selbst nannte: Marc Hassenzahl, Psychologe und Professor  im Industrial Design an der Folkwang Universität der Künste in Essen.

Die Keynote hat mir sehr gut gefallen: es dreht sich rund um das Gestalten von Erlebnissen. Die zentrale Erkenntnis ist, dass in der heutigen Gesellschaft kein besitzorientiertes Denken mehr herrscht („Ich bin so toll, ich fahre nen Mercedes.“), sondern dass Erlebnisse in den Vordergrund rücken („Ich habe den Yeti am Mount Everest gesehen.“). Wir wollen also ein Produkt, das Spaß macht, uns positive Erlebnisse verschafft. Die wahnwitzigsten und ausgefeiltesten Funktionen helfen nicht, wenn das Ding keinen Spaß macht! Als Beispiel für ein gelungenes erlebnisorientiertes Produkt nannte Hassenzahl u.a. das Wake-Up Light von Philipps, das einen sanft mit immer heller werdendem Licht weckt. Es sei kein besonders hübsch designtes Produkt und auch die Funktion wäre im Endeffekt nur eine Zeitschaltuhr mit Glühbirne – aber es verschafft dem Benutzer ein gutes Erlebnis, wenn er jeden Morgen sanft davon geweckt wird. Und das kann ich auch aus ganz eigener Erfahrung bestätigen 🙂

Im Fokus der Produktentwicklung muss also eigentlich erst die Erlebnisentwicklung stehen: man muss sich überlegen, was für ein Erlebnis man schaffen will und dann das zugehörige Produkt bzw. dessen Funktionen designen. Plakativ gesagt: Form follows fun.

Ich fand diesen nicht direkt redaktionsbezogenen Vortrag sehr erfrischend – und  exotisch war er für die Welt der technischen Redakteure ganz uns gar nicht. Das hätte ich Marc Hassenzahl noch gerne gesagt 🙂  Schließlich sind wir ja federführend an der Erstellung von Produkten beteiligt, und zwar: Informationsprodukten. Diese gehören zum eigentlichen Produkt und müssen genauso Teil eines positiven Produkterlebnisses sein. Der Vortrag hat auf jeden Fall Spaß gemacht und mir einige neue Perspektiven gezeigt. Gerne mehr davon!

 


 

tekom 2011 – Content Strategy

Auf der Jahrestagung 2011 gab es die so genannten Trendthemen, welchen dann jeweils ein gesamter Vortragsstrang an einem Tag gewidmet wurde: „Mobile Dokumentation“ und „Content Strategy“. Von ersterem Thema habe ich leider gar nichts mitbekommen, weil ich zum Einen auf  einem 1,5stündigen Workshop war und zum Anderen dann parallel stattfindende Vorträge vom Thema her bevorzugen musste. Sehr schade, aber das war mein persönliches Pech.

Dafür habe ich dann mehrere Vorträge der „Content Strategy“-Reihe mitgenommen, die von Scott Abel moderiert wurde, der im Übrigen auch eine sehr tolle Keynote zur Tagung gehalten hat, die auch sehr in Richtung Content Strategy ging.

Ich habe mal ein paar Schnipsel zu dem Thema festgehalten, die sich mir eingeprägt haben.

„Technical communication IS marketing even if it doesn’t know it’s marketing.“ (Scott Abel)

Der Satz hat mir unheimlich gut gefallen. Das Hilfeangebot ist ab dem Produktkauf DIE eine Kommunikationsschnittstelle zum Kunden. Ab diesem Zeitpunkt sind im Marketingunterlagen und die Webseite egal, denn nun geht es an die Produktnutzung. Und es ist fatal, dass diese Kommunikation häufig vernachlässigt wird, weil es „nur die Doku ist“, denn sie hat die Chance den Kunden in einer negativen Situation mit dem Produkt eventuell nochmal positiv zu stimmen. Und wir alle lieben doch zufriedene Kunden 😉

„The user doesn’t care about your org chart.“ (Noz Urbina)

Der Nutzer hat immer eine ganzheitliche Produktsicht – im Gegensatz zu den Firmen selbst, die sich häufig in historisch gewachsenen Strukturen verstricken und darüber vergessen, wie es dem Nutzer eigentlich so geht. Dem ist es egal wie eine Firma organisiert ist, am Ende braucht und will der Kunde eine Produkterfahrung aus einem Guss. Das heißt z.B., dass überall dieselben Informationen erhältlich sein müssen.

„Software does not only act on content – it provides content.“ (Ray Gallon)

Ray zielt hier darauf ab, dass heutzutage eine größere Verschmelzung zwischen der Software- und der Content-Welt besteht. Software ist heutzutage eben auch Informationslieferant und auch diese Informationen müssen geplant, erstellt und verwaltet werden.

Content ist nicht gleich Content

Eine Sache ist mir  besonders aufgefallen: der Content-Begriff wurde hier weit gefasst und nicht nur auf technische Kommunikation im Sinne von Anleitungen begrenzt. Bei „Content Strategy“ geht es darum, eine ganzheitliche Produktkommunikation aufzubauen, oder wie es Noz Urbina sagte: „Breaking down information silos.“

Technische Kommunikation ist dann eigentlich „nur“ ein Teilaspekt, aber das Know-How, dass die technischen Redaktionen vielfach im Bereich des Single-Source-Publishing besitzen, macht sie sicherlich zu denjenigen in einer Firma, die prädestiniert sind, eine solche Produktkommunikation mit umzusetzen. In der TR hat man sich einfach schon mit allen Fragen des Contents beschäftigt, die bei den anderen Abteilungen vielleicht jetzt erst zum Thema werden.

Zum Blogpost von techwriterkai gab es hierzu auch einen umfassenden Kommentar von Scott Abel, der auch nochmal herausstellt, dass es für ein tatsächliches Umsetzen von einer „Content Strategy“ fast noch wichtiger ist, z.B. supergut präsentieren zu können, sich in Manager hineindenken zu können, sich mit Dingen wie ROI etc. auseinander setzen zu können.

Nur: Wo lernt man solche Dinge eigentlich? Kann man sie lernen? Sollten solche Aspekte stärker im TR-Studium berücksichtigt werden? Im Aufbaustudium zur Führungskraft Technische Redaktion der tecom.ch ist z.B. ein Block „Kommunikation im Unternehmen“ drin, was ich sehr interessant finde. Ich hatte das z.B. gar nicht im Studium und habe da dann eher von Kollegen lernen müssen, die schon länger im Spiel sind.

Fazit

Ich mag meinen Beruf, weil er mir so viele Entwicklungsmöglichkeiten bietet (ok, manchmal verdamme ich das auch, denn man muss sich ja doch auch für etwas entscheiden 😉 ). Deswegen finde ich es immer spannend, neue Möglichkeiten aufgezeigt zu bekommen. Und hier ist es eben der Fakt, dass es vielleicht in Zukunft nicht mehr nur bei der technischen Kommunikation bleiben wird.

Oder wie Scott Abel bei Kai kommentierte:

It’s an exciting time to be in the content industry.

Redakteuse live „DITA – Grundlagen und Tipps für Einsteiger“

Im Rahmen der Abendveranstaltungen der tekom-Regionalgruppe Baden halte ich am 23.02. in Karlsruhe einen kleinen Vortrag zu meinem Lieblingsthema 🙂

Für alle DITA-Interessierten mit Grundkenntnissen in XML und Standardisierung gibt es einen kleinen Rundblick mit folgenden Punkten:

* Was ist DITA?

* Für welche Einsatzzwecke ist DITA geeignet?

* Was sind die Vor- und Nachteile?

* Was kann man alles mit DITA anstellen?

* Wie steigt man am besten in die DITA-Welt ein?

Weitere Informationen zu Anmeldung und Ort finden sich direkt auf der Webseite der Regionalgruppe. Ich freue mich über zahlreiche Zuhörer 😉

EDIT: Hier ein Bericht zum Termin 🙂

tekom 2010: Documentation for Software Engineers

In meinem ersten Job wurde ich zur Betreuung der internen Dokumentation und des Firmen-Wikis eingestellt. Die Vision damals war, dass ich mal tüchtig aufräume und danach alle Abteilungen in der Firma tolle Dokumentation haben. Nun, das wäre super gewesen 🙂 Aber ich musste feststellen, dass das so einfach nicht ist. Es kommt zum einen darauf an, um was es sich für eine Abteilung handelt ( PR? Marketing?Personal? Entwicklung? Wenn ja, welche Richtung? etc), denn die Anforderungen sind dann natürlich unterschiedlich. Dazu hätte ich mich im Detail mit jeder Abteilung und ihrer Dokumentation auseinander setzen müssen. Eine Person alleine kann das für eine große Firma nicht schaffen – und: die Abteilungen müssen am Ende trotzdem auch immer noch selbst Dokumentation schreiben. Das war für die meisten die größte Überraschung damals 😉

In dem Vortrag „Documentation for Software Engineers“ von Ulrike Parson habe ich nun einiges erfahren, wie man das Thema interne Dokumentation angehen kann. Und es hat meine oben erwähnten Erfahrungen bestätigt.

Zielgruppen
Auch bei interner Dokumentation ist es wichtig sich über die Zielgruppe Gedanken zu machen. Das wird bei diesem Thema oft vergessen – es ist ja „nur“ für intern. Die Zielgruppe ist hier der Software-Entwickler und seine verschiedenenen Ausprägungen. Frei übersetzt teilte Ulrike Parson sie wie folgt auf:

  • Den Praktiker:
    • will loslegen
    • benötigt Code-Kommentare, Code-Beispiele
  • Den Gründlichen:
    • liest zuerst einmal die Grundlagen
    • benötigt Hintergrundinfo zu API/Framework, Beschreibung allgemeiner Programmieraufgaben (Error handling, Lokalisierung &Co.)
  • Bedarfsleser
    • Liest bei konkreten Fragen nach
    • Benötigt Code-Kommentare, Hintergrundinformationen und Code-Beispiele

Anhand dieser Zielgruppenanalyse schlüsselt sie dann auf, welche Dokumenttyen geliefert werden müssen, um diesen Anforderungen gerecht zu werden. Und auch wie sie geliefert werden müssen, z.B. als PDF oder Wiki mit Feedback-Funktion, Index etc.

Die Rolle des technischen Redakteurs
Ich habe von Entwicklern schon so oft gehört, dass sie endlich mal dokumentieren müssten oder endlich mal „gescheit dokumentieren“ müssten. Gleichzeitig hab ich mich immer gefragt: wie könnte ich dabei helfen? Immerhin heißt es doch auch „technische Dokumentation“, was ich studiert habe 😉

Inwieweit der technische Redakteur die Entwickler beim tatsächlichen Dokumentieren unterstützen kann, hängt natürlich stark davon ab, wieviel Programmierwissen und -erfahrung er selbst hat. Aber es ist ununmgänglich, dass die Entwickler auch selbst dokumentieren – wer etwas selbst macht, weiß einfach am besten darüber Bescheid. Frau Parson hat sehr schön gezeigt, dass der Redakteur auch ohne selbst viel zu schreiben, doch sehr viel hier mitarbeiten kann.

So können die Aufgaben des Redakteurs aussehen:

  • Zielgruppen- und Bedarfsanalyse
  • Dokumentationsworkflows erstellen
  • Terminologie erarbeiten, pflegen und bereitstellen
    • gerade in der Entwicklung lebt so manch uralter produktname ewig weiter
    • Missverständnisse untereinander werden vermieden
  • Neue Texte redigieren/korrigieren
  • Neue Texte evtl. schreiben
  • Strukur der Dokumentation entwickeln und überwachen
  • Dokumentvorlagen bereitstellen

Und wenn man sich das mal genau anschaut, sieht man wieder, dass das ganz klassische Redakteursaufgaben sind. Nur ist der Fokus nicht so sehr darauf alles auch selbst zu schreiben, sondern viel mehr zu recherchieren, strukturieren, den Entwicklern eine Basis zu geben.

Als praktisches Beispiel wurde abschließend noch ein Wiki gezeigt, das vor allem von den Entwicklern befüllt wird. Von der Redakteursseite wurde eine Grundstruktur angelegt und auch verschiedene Templates, damit die Entwickler nicht vor einer weißen Seite stehen und nicht wissen wo sie anfangen sollen. Der Redakteur überwachte nun die Entwicklung der Dokumentation und greift hier und da korrigierend ein. Zudem gibt es einen Freigabeprozess, so dass man auch wirklich nur qualitativ hochwertige Dokumentation publiziert.

Für den einen oder anderen Software-Entwickler klingt das ganze vielleicht nach zu viel Reglement, aber ich habe schon zuviel schlechte und veraltete SW-Dokumentation gesehen und das klingt für mich nach einem plausiblen Weg aus der Misere.

Fazit

Ein hochinteressanter Vortrag (als PDF), der auch mal neue Wege für Redakteure aufgezeigt hat, die nicht in der klassischen Schiene liegen, aber am Ende doch perfekt auf das Skillset passen. Vielen Dank dafür! 🙂

tekom Jahrestagung 2010 – Rückblick

So, es ist geschafft 🙂

Ich habe den Beinahe-Laptopausfall und die Vor-Vortrags-Nervosität halbwegs überstanden und ich denke, mein Vortrag ist ganz gut angekommen. Aber Genaueres weiß ich erst, wenn die Feedback-Bögen eintreffen. Und da bin ich äußerst gespannt! Meine Folien werde ich demnächst hier veröffentlichen sind nun unter Downloads erhältlich.

Nun, wie sah es mit dem Rest der Tagung aus?

Das Zielgruppen-Problem

Bei mir und bei vielen anderen (u.a. auch im neuentdeckten Blog von Jason A. Nichols), herrschte ein wenig Unmut darüber, dass man in vielen Fortgeschrittenen- oder Experten-Vorträgen dann doch wieder mit sehr vielen Basics konfrontiert wurde. Ich weiß schon gar nicht mehr in welchem Vortrag das war, aber als man anfing uns zu erklären, dass Standards gut sind, da kam ich mir etwas veräppelt vor (das gehört für mich zur Grundausstattung des Redakteurs!). Vielen fiel es sichtlich schwer, den Vortrag zielgruppengerecht aufzubereiten. Vielleicht fehlt aber auch ein genaue Beschreibung der Klassifikationen „Einsteiger – Fortgeschrittene -Experten“? Ich habe mir rückblickend nämlich überlegt, dass ich meinen Vortrag wohl besser als „Für Experten“ eingestuft hätte, aber so richtig sicher bin ich mir nicht. Daher mein Vorschlag an die tekom, da vielleicht mal den Versuch einer detaillierten Klassifikation zu starten. Als Zuhörer ist es wirklich sehr ärgerlich, wenn man sich in einem Vortrag wiederfindet, der einfach gar nicht passt. Ich kann mir gut vorstellen, dass sich viele die Investition in die nächste Tagung nochmal gut überlegen.

Die Idee von Urs Klenke nicht mehr so viele verschiedene Vorträge anzubieten, aber dafür ausgewähltere und diese auch zu wiederholen, finde ich prinzipiell auch ganz gut, wobei es organistorisch bestimmt ziemlich kompliziert wäre…

iPad, iPhone, ePub

Das war definitiv der Hype in diesem Jahr. Vieles war hier noch recht theoretisch – ich hoffe im nächsten Jahr auf erste richtige echte Beispiele!

User assistance

Der Hype dauert immer noch an, wobei ich da weiterhin hoffe, dass es auch hier noch mehr echte Beispiele geben wird. Die Theorie ist so langsam bekannt – jetzt will ich sehen was andere machen 🙂

… und der Rest

Es war einfach mal wieder nett so komplett unter „seinesgleichen“ zu sein und sich über das Fach austauschen zu können – und auch so einige Leute mal „in echt“ zu treffen 😉 Zielgruppen hin oder her – es waren immer noch Vorträge dabei, die einem hier und da wieder einen neuen Denkanstoß gegeben haben. Ich werde mir zum Beispiel in nächster Zeit einige Gedanken dazu machen, wie ich eventuell eine Verknüpfung meiner Hilfedateien mit den Textdateien unserer Applikationen hinbekommen kann, so wie in dem Vortrag „User Interface-Texte in der Dokumentation„.

Und last but not least: endlich ist mir bei einem von Tony Selfs Vorträgen eine Frage eingefallen! Dafür wird man nämlich mit einem echten Aussie-Koala belohnt 😉

Tony-Self-Koala

EDIT: einen interessanten Rückblick bietet auch Sarah.