Folien zum Fachvortrag auf der tekom-Jahrestagung 2013 im Themenbereich Software-Dokumentation und User Assistance

1. tekom-Jahrestagung
Vortrag UA/SWD 4
Mit gutem Beispiel voran!
Demo-Inhalte als Bestandteil der User
Experience
Martin Häberle, Vorsicht Lesegefahr!

3. 3 Thesen
Was Sie hier erwartet
2 Prognosen
6 Demos
4 Tipps

4. Typologie des Beispiels
Blindtexte dienen als Platzhalter wie „Lorem ipsum“ oder „123“, „asdf“.
Beispieldaten sind Datensätze in SW-Anwendungen für Test, Demo etc.
Code-Beispiele sind unverzichtbar in Entwickler/API-Dokumentationen.
Anwendungsbeispiele sollen in sich „rund“ und Use-Case-orientiert sein.
Demosysteme verkaufen die Software mittels Anwendungsbeispielen.

5. These: Blindtexte machen blind
Lorem ipsum dolor
sit amet, consetetur
sadipscing elitr, sed
diam nonumy
eirmod tempor
invidunt ut labore et
dolore magna
aliquyam erat, sed
diam voluptua. At
vero eos et
accusam et justo
duo dolores et ea
rebum. Stet clita
kasd gubergren, no
sea takimata …

6. Empfehlung: Blindtext vermeiden!
Blindtexte sind oft (zu) unauffällig
Fordern zum Wegsehen geradezu auf
Layouter vergisst ggf. die Ersetzung
Wenn‘s sein muss: auffällig („Grantln“)
Lieber gleich „echte und gute“ Inhalte

7. Tipp: Blindtext erzeugen (1)
Microsoft Office (insbesondere Word):
=rand(n,m)
Deutschsprachigen Blindtext mit n Absätzen und
jeweils m Sätzen einfügen, z. B. rand(1,2):
Auf der Registerkarte 'Einfügen' enthalten die Kataloge Elemente, die mit
dem generellen Layout des Dokuments koordiniert werden sollten. Mithilfe
dieser Kataloge können Sie Tabellen, Kopfzeilen, Fußzeilen, Listen,
Deckblätter und sonstige Dokumentbausteine einfügen.
=lorem(n,m)
„Lorem ipsum“-Blindtext einfügen (analog zur
rand()-Funktion)
Voraussetzung: In den Autokorrektur-Optionen von Word ist
Während der Eingabe ersetzen aktiv

8. Tipp: Blindtext erzeugen (2)
Generator auf bavaria-ipsum.de
„Schmarrn“
oder „Grantln“
„Grantl“-Ergebnis:

9. Beispiele für Beispiele
„Um Rekursion
zu verstehen,
muss man
wissen, was
Rekursion ist.“

10. Einsteiger-Tutorial
Tutorial: ully.com/joomla
Blog: joomla-das-buch.de

11. Anwendungsbeispiel: Keynote

12. Confluence-Add-ons
von K15t für TD
Beispiel: Wiki-Funktionen

13. Confluence-Add-ons
von K15t für TD
Beispiel: Wiki-Funktionen

14. These: Beispiele sind Hilfe 2.0
Demodaten/-anwendungen als
User Assistance

15. Demoinhalte ersetzen Hilfetexte
Demo-Inhalte machen Anleitungen (beinahe) überflüssig
Demoinhalte/Beispiele sind eine (bzw. für viele die) Hilfe
Hilfetexte werden (wenn vermeidbar) nicht gelesen
Einschränkung: gilt insbesondere für
handlungsrelevante Informationen

16. Anforderungen an Showcases
… und Beispielanwendungen
Voraussetzung: funktional, vollständig, sinnvoll
Ohne komplexe Fachlichkeit
Anschaulich dargestellt, spielerisch aufbereitet
Als Demodaten erkennbar und
von Produktivdaten getrennt

17. Marketing-Instrument
These: Demos sind mehr als Doku!
Markenbildung
Kundenbindung
Identifikation

18. Als Marketing-Instrument
Dokumentation allein verkauft keine Software,
gute Demosysteme und nutzbare Beispiele schon!
Tipp: Optionale Komponenten im Demosystem „anfeaturen“

19. Beispiel: Wordpress-Theme
http://ow.ly/pYqa2

20. Wiedererkennung!
Vom Kunden zum Fan!
Beziehung zum Nutzer (=Kunden!)
aufbauen durch individuelle,
nützliche Demos/Beispiele

21. Beispiel „Angry Nerds“
Demoprojekt im Ticket-System
Atlassian JIRA®
Comic-Vögel à la „Angry Birds“
T-Shirts als Merchandising

22. Überall benötigt: Showcases
… und Beispielanwendungen
Dokumentation: Screenshots, Beispiele, Beispielcode
Entwicklungs-/Testabteilung: mit dem Demo-System
Schulungen: Übungen, Folien, WBTs etc.
Vertrieb/Marketing: Website, Produktvideos,
Präsentationen, Webcasts etc.
Consulting: als Basis für Kundenlösungen

23. Prognose 1: Mehr Beispiele, weniger Doku
Veränderte Nutzererwartungen an „Hilfe“
Anwendungsfall „Software ausprobieren“
Bedienwissen zukünftig komplett in GUI und Demo abgebildet
Tipp: Schrittanleitungen automatisch generieren, z.B. mit
„Dr. Explain“, siehe www.drexplain.de

24. Prognose 2: die neue TR-Rolle
Beispiele kommen besser nicht von Entwicklern!
Technische Redakteure sind optimale Ersteller
Synergie-Effekte nutzen
Weg mit dem Silodenken!

25. Zusammengefasst:
Bessere Demodaten, Anwendungsbeispiele für Software
Vorhandene Möglichkeiten konsequent nutzen
Mehr Mut zur Kreativität
Weniger Schrittanleitungen (die keiner liest)
Die Mühe zahlt sich für das Unternehmen aus
Die Zukunft der User Assistance für Software
Die Zukunft des Technischen Redakteurs

26. Fragen, Kommentare?
Weitere Fragen, Anregungen und Kritik gerne an
mail@lesegefahr.de

27. UA/SWD 4
Danke für die Aufmerksamkeit!
www.Lesegefahr.de
twitter.com/Lesegefahr