Bildquellen für Software-Dokumentation: Screenshot, Mockup oder KI?

Softwaredokumentation hat ein Bildproblem, das sich von dem des Maschinenbaus deutlich unterscheidet. Eine Maschine sieht in fünf Jahren noch aus wie heute; eine Bedienoberfläche kann sich mit dem nächsten Release ändern. Und während eine Explosionszeichnung aufwändig zu erstellen und danach lange gültig ist, verhält es sich beim Screenshot umgekehrt: in Sekunden gemacht, in Monaten veraltet.

Daraus folgt eine andere Kostenlogik. Der Aufwand steckt nicht in der Erstellung, sondern in der Pflege – und er multipliziert sich mit zwei Größen: der Zahl der Sprachen und der Zahl der Releases. Wer eine Anwendung in acht Sprachen dokumentiert und zweimal jährlich ein Release ausliefert, steht bei fünfzig Screenshots vor achthundert Bildaufnahmen im Jahr, wenn er alles von Hand macht.

Dieser Artikel sortiert die drei Bildquellen – Screenshot, Mockup und Generator –, zeigt den Entscheidungsbaum, beschreibt die Automatisierung von Screenshots und liefert sechs Regeln für einen pflegeleichten Bildbestand. Die wirksamste davon steht am Anfang: Der günstigste Screenshot ist der, den es nicht gibt.

★ Fakten kompakt Für Darstellungen der realen Oberfläche gibt es nur eine Quelle: den Screenshot aus der laufenden Software Mockups eignen sich für Oberflächen, die es noch nicht gibt – als erkennbarer Entwurf gekennzeichnet Bildgeneratoren erzeugen keine brauchbaren Oberflächendarstellungen – Beschriftungen werden verfremdet Screenshots lassen sich automatisiert erzeugen: definierte Testdaten, Skript, Durchlauf je Sprache Ab etwa drei Sprachen oder zwei Releases im Jahr rechnet sich die Automatisierung regelmäßig Markierungen gehören in eine eigene Ebene – dann überstehen sie den nächsten Aufnahmelauf

 

Der Entscheidungsbaum

Die Auswahl der Bildquelle ist einfacher, als sie wirkt, weil eine einzige Frage fast alles entscheidet: Zeigt das Bild die reale Oberfläche, und soll der Nutzer darin etwas wiederfinden? Lautet die Antwort ja, gibt es genau eine Quelle – den Screenshot aus der laufenden Software. Kein Mockup, keine Zeichnung, kein Generator kann das leisten, weil der Nutzer die Darstellung mit dem vergleicht, was er auf seinem Bildschirm sieht.

Lautet die Antwort nein, folgt die zweite Frage: Was zeigt das Bild dann? Bei Abläufen, Systemarchitekturen und Zusammenhängen ist eine Zeichnung oder ein Diagramm die richtige Wahl – als Vektorgrafik, textfrei mit Legende, wie es der Beitrag zu textfreien Grafiken beschreibt. Bei Oberflächen, die es noch nicht gibt, ist ein Mockup angebracht: für Konzeptdokumente, für Abstimmungen mit Fachbereichen, für Dokumentation, die parallel zur Entwicklung entsteht.

Und der Generator? Er hat in der Softwaredokumentation einen sehr schmalen Platz: Titel- und Stimmungsbilder, Konzeptillustrationen für Schulungsunterlagen. Für Oberflächendarstellungen scheidet er aus, und zwar aus einem handfesten technischen Grund – Bildgeneratoren erzeugen Text im Bild bislang unzuverlässig. Was als Menüpunkt oder Schaltflächenbeschriftung entsteht, sind oft verfremdete Wörter oder sinnlose Zeichenfolgen. Eine Oberfläche ohne lesbare Beschriftungen ist als Dokumentation wertlos.

Abb.: Eine Frage entscheidet, drei Wege bleiben – der Entscheidungsbaum ist erfreulich flach.

Ein weiterer Unterschied zum Maschinenbau gehört dazu, weil er das Bildkonzept prägt: Softwaredokumentation erscheint zunehmend als Online-Hilfe statt als PDF — und dort gelten andere Bedingungen. Bilder werden am Bildschirm betrachtet, oft in schmalen Fenstern neben der Anwendung, gelegentlich auf mobilen Geräten. Ein Screenshot, der auf einer A4-Seite funktioniert, ist in einem Hilfefenster von dreihundert Pixeln Breite unlesbar. Das spricht zusätzlich für Ausschnitte statt Vollbildern — nicht nur aus Pflegegründen, sondern aus Darstellungsgründen.

Umgekehrt eröffnet die Online-Ausgabe Möglichkeiten, die es im Druck nicht gibt: Bilder lassen sich vergrößern, mit interaktiven Markierungen versehen oder durch eine kurze Bildschirmaufzeichnung ersetzen. Für Abläufe, die schwer zu beschreiben sind, kann eine solche Aufzeichnung mehr leisten als eine Folge von Standbildern — sie hat allerdings dieselben Pflegeeigenschaften wie ein Screenshot, multipliziert mit Sprachen, und ist deutlich aufwändiger zu aktualisieren. Sparsamkeit gilt dort erst recht.

Warum Screenshots teuer sind

Die Kosten eines Screenshots entstehen nicht bei der Aufnahme, sondern danach. Jede Änderung an der Oberfläche kann ihn ungültig machen – ein umbenannter Menüpunkt, eine verschobene Schaltfläche, ein neues Element in der Symbolleiste. Und weil solche Änderungen mit jedem Release kommen, entsteht ein wiederkehrender Prüf- und Aktualisierungsaufwand, den niemand einplant, weil die Einzelaufnahme ja so schnell geht.

Dazu kommt der Sprachfaktor. Anders als beim Maschinenbau lässt sich die Beschriftung nicht durch eine Legende ersetzen: Menüpunkte und Schaltflächen sind Teil dessen, was gezeigt wird. Wer eine Anwendung in acht Sprachen dokumentiert, braucht acht Screenshot-Sätze – und zwar aus der jeweils lokalisierten Oberfläche, nicht durch nachträgliche Bildbearbeitung. Die Zahl der Bilder multipliziert sich also mit der Sprachenzahl, und dieser Faktor greift bei jedem Release erneut.

Der dritte Kostenfaktor ist die Prüfung. Ein veralteter Screenshot fällt nicht auf – er sieht aus wie ein Screenshot. Anders als bei Text, wo eine falsche Angabe im Review auffallen kann, muss jemand aktiv vergleichen: Sieht die Oberfläche noch so aus? In der Praxis unterbleibt dieser Vergleich regelmäßig, und Anleitungen zeigen Bildschirmzustände, die es seit drei Versionen nicht mehr gibt. Das untergräbt das Vertrauen in die gesamte Dokumentation.

Abb.: Drei Quellen im Vergleich – die zweite Zeile entscheidet über die Verwendbarkeit.

Bildzweck	Richtige Quelle	Wo die Grenze liegt
Wo finde ich diese Funktion?	Screenshot	Muss der aktuellen Version entsprechen
Wie ist die Anwendung aufgebaut?	Diagramm	Textfrei mit Legende, keine Oberfläche
Wie läuft der Prozess ab?	Ablaufdiagramm	Konzeptebene, keine Bildschirmzustände
Wie soll es später aussehen?	Mockup	Als Entwurf kennzeichnen
Titelbild, Kapiteleinstieg	Generator möglich	Keine Oberflächenanmutung erzeugen
Systemarchitektur	Diagramm	Vektorgrafik, textfrei

 

Screenshots automatisiert erzeugen

Der wirksamste Hebel gegen diese Kosten ist die Automatisierung – und sie ist bei Software erheblich einfacher als bei Maschinen, weil die Quelle ein laufendes Programm ist, das sich steuern lässt. Die Kette hat fünf Glieder. Erstens die Testdaten: ein definierter Datenstand, der jederzeit wiederherstellbar ist. Keine echten Kundendaten, keine zufällig entstandenen Beispielinhalte – sondern ein Bestand, der bei jedem Durchlauf identisch aussieht.

Zweitens das Skript: ein Ablauf, der die Anwendung öffnet, zur gewünschten Stelle navigiert und die Aufnahme auslöst – bei fester Fenstergröße und festem Ausschnitt. Drittens der Durchlauf je Sprache: Derselbe Ablauf läuft mit umgestellter Oberflächensprache erneut. Genau hier liegt der eigentliche Gewinn, denn dieser Schritt ist es, der von Hand so teuer wird. Achtmal durch dieselbe Anwendung zu klicken, ist die Art von Arbeit, für die niemand Zeit hat und bei der Fehler entstehen.

Viertens die Nachbereitung: zuschneiden, Ziffern setzen, Hervorhebungen ergänzen – ebenfalls skriptgesteuert. Und fünftens das Ablegen nach einem festen Namensschema, je Sprache, sodass die Dokumentation die Bilder automatisch findet. Ist die Kette gebaut, kostet ein kompletter Screenshot-Satz in allen Sprachen einen Durchlauf – bei jedem Release, ohne Handarbeit.

Zur technischen Seite der Aufnahme gehört noch ein Punkt, der später viel Ärger erspart: die Auflösung. Screenshots sollten in ausreichender Auflösung aufgenommen werden, um sowohl im Druck als auch am hochauflösenden Bildschirm scharf zu erscheinen — nachträgliches Hochskalieren funktioniert nicht. Praktisch heißt das, die Aufnahme mit erhöhter Skalierung durchzuführen und für die jeweilige Ausgabe herunterzurechnen. Wer das erst nach hundert Bildern merkt, nimmt sie ein zweites Mal auf.

Abb.: Fünf Glieder der Kette – der Aufwand liegt vorn, der Nutzen bei jedem Release.

Für Redaktionen mit Single-Source-Ansatz kommt ein Aspekt hinzu, der die Automatisierung besonders attraktiv macht: Wenn Bilder nach festem Namensschema je Sprache abgelegt werden, kann die Publishing-Kette sie automatisch einbinden — dasselbe Topic zieht in der deutschen Ausgabe das deutsche Bild und in der französischen das französische, ohne dass jemand Verweise pflegt. Damit wird der Screenshot behandelt wie jeder andere sprachabhängige Bestandteil, und die Sprachfrage verschwindet aus der redaktionellen Arbeit.

Diese Kopplung ist der eigentliche Grund, warum das Namensschema in der Kette an fünfter Stelle steht und nicht nebenbei erledigt wird. Ein Bestand, in dem Bilder nach dem Muster „Dialog_Einstellungen_de.png" abgelegt sind, lässt sich automatisch verarbeiten; einer mit gewachsenen Dateinamen nicht. Wer die Kette baut, legt deshalb zuerst das Schema fest — und hält sich daran, auch wenn es beim zehnten Bild noch überflüssig wirkt.

Wann sich das rechnet

Die ehrliche Antwort lautet: nicht immer. Die Kette aufzubauen kostet Tage, und sie muss gepflegt werden – ändert sich die Oberfläche grundlegend, ändern sich auch die Navigationsschritte im Skript. Für eine Anwendung mit einer Sprachfassung, zehn Screenshots und einem Release im Jahr lohnt der Aufwand nicht; da ist die Handarbeit schneller.

Die Schwelle liegt erfahrungsgemäß bei etwa drei Sprachen oder zwei Releases im Jahr – und wenn beides zusammenkommt, ist die Rechnung eindeutig. Entscheidend ist dabei nicht die Zahl der Screenshots allein, sondern ihr Produkt mit Sprachen und Releases: Zwanzig Bilder in vier Sprachen bei zwei Releases sind hundertsechzig Aufnahmen im Jahr, und das ist eine Arbeitswoche, die jährlich wiederkehrt.

Die wichtigere Frage ist allerdings eine andere, und sie wird selten zuerst gestellt: Was gibt es schon? In vielen Häusern laufen automatisierte Oberflächentests, die im Kern dasselbe tun – die Anwendung starten, navigieren, den Zustand prüfen. Wer dort ansetzt und die Testkette um eine Aufnahmefunktion ergänzt, spart den größten Teil des Aufbaus. Deshalb beginnt dieses Thema nicht in der Redaktion, sondern mit einem Gespräch in der Entwicklung.

⚠ Warnung: Der Screenshot mit echten Daten Ein Fehler, der regelmäßig auftritt und unangenehm werden kann: Screenshots werden aus einer produktiven Umgebung oder aus einem Kundensystem aufgenommen — mit echten Namen, echten Beträgen, echten Vorgangsnummern. In der Anleitung landen damit Daten, die dort nicht hingehören, und zwar dauerhaft und in jeder ausgelieferten Fassung. Die Gegenmaßnahme ist der definierte Testdatenbestand, und sie wirkt doppelt: Sie löst das Datenschutzproblem, und sie sorgt dafür, dass alle Screenshots konsistent aussehen. Wo Testdaten fehlen, entsteht eine Anleitung, in der die Beispielfirma von Bild zu Bild wechselt — was Leser irritiert, ohne dass sie sagen könnten, warum. Der Aufbau eines vernünftigen Testdatenbestands ist deshalb der erste Schritt, nicht der letzte.

 

Eine Zwischenstufe verdient Erwähnung, weil sie oft übersehen wird: die teilautomatisierte Aufnahme. Wer keine vollständige Kette bauen kann oder will, kommt mit einfacheren Mitteln schon weit — ein Werkzeug, das Fenstergröße und Ausschnitt festhält, eine Sammlung gespeicherter Aufnahmedefinitionen, ein Skript, das lediglich die Nachbereitung übernimmt. Diese Zwischenstufen kosten Stunden statt Tage und nehmen einen erheblichen Teil der Fehlerquellen weg, insbesondere die uneinheitliche Darstellung.

Sechs Regeln für pflegeleichte Screenshots

Unabhängig davon, ob automatisiert wird, senken sechs Regeln den Aufwand erheblich. Regel eins ist die wirksamste: sparsam einsetzen. Jeder Screenshot ist Pflegeaufwand, und viele stehen in Anleitungen, ohne etwas beizutragen – Abbildungen eines Dialogs, dessen Beschreibung im Text vollständig ist, oder Bilder zu jedem einzelnen Klick eines Ablaufs. Screenshots helfen bei der Orientierung: Wo finde ich diese Funktion, wie sieht der Bereich aus, in dem ich arbeite? Für die Schrittfolge selbst genügt Text.

Regel zwei: Ausschnitt statt Vollbild. Ein Bild, das nur den relevanten Bereich zeigt, veraltet langsamer – weil Änderungen an anderen Stellen der Oberfläche es nicht betreffen. Ein Vollbild dagegen wird von jeder Änderung irgendwo im Fenster ungültig. Regel drei: feste Testdaten, aus den genannten Gründen. Regel vier: feste Darstellung – gleiche Fenstergröße, gleiche Skalierung, gleiches Farbschema über alle Bilder hinweg. Sonst wirkt die Dokumentation zusammengestückelt, auch wenn jedes Bild für sich korrekt ist.

Regel fünf: Markierungen als eigene Ebene. Pfeile, Rahmen und Ziffern werden nicht ins Bild eingebrannt, sondern getrennt gehalten – dann überstehen sie den nächsten Aufnahmelauf und müssen nicht neu gesetzt werden. Diese Regel spart bei jedem Release Zeit und wird trotzdem selten befolgt, weil sie beim ersten Bild überflüssig wirkt. Und Regel sechs: Benennungen abgleichen. Was im Text „Einstellungen" heißt, muss in der Oberfläche auch so heißen – in jeder Sprache. Das erfordert Abstimmung mit der Softwarelokalisierung.

Abb.: Sechs Regeln – die erste wirkt stärker als alle übrigen zusammen.

Für die Zusammenarbeit mit der Entwicklung lohnt eine Beobachtung, die den Zugang erleichtert: Das Argument, das dort verfängt, ist selten „die Redaktion braucht Bilder". Wirksamer ist der Hinweis, dass eine Aufnahmekette auch der Entwicklung nützt — als visueller Nachweis über Releases hinweg, als Vergleichsmaterial bei Oberflächenänderungen, als Ergänzung zur Testdokumentation. Wer so einsteigt, bekommt eher Unterstützung als mit einer Anforderung, die nach zusätzlicher Arbeit für ein fremdes Team klingt.

Praktisch bewährt hat sich außerdem, klein anzufangen: nicht die komplette Anleitung automatisieren, sondern die zehn Screenshots, die sich am häufigsten ändern. Läuft das, wächst die Abdeckung von selbst, weil der Nutzen sichtbar ist. Ein Vorhaben, das mit dem vollständigen Bildsatz beginnt, scheitert dagegen oft an seinem Umfang — und hinterlässt den Eindruck, Automatisierung lohne sich hier nicht.

Für die Doku-Struktur folgt daraus eine Empfehlung, die über Bilder hinausgeht: Schrittfolgen gehören in Text, Orientierung in Bilder. Ein Ablauf, der als Reihe nummerierter Schritte beschrieben ist, bleibt bei Oberflächenänderungen weitgehend gültig — nur die Benennungen ändern sich, und die stehen im Text, wo sie mit Terminologie und Übersetzungsspeicher erfasst sind. Derselbe Ablauf als Bilderfolge dokumentiert ist bei jeder Änderung neu aufzunehmen, in jeder Sprache.

Diese Aufteilung ist deshalb nicht nur eine Kostenfrage, sondern auch eine der Verständlichkeit: Wer eine Anwendung bedient, liest den nächsten Schritt und führt ihn aus — er blättert nicht durch Bilder. Bildunterstützung braucht er dort, wo die Orientierung schwerfällt: beim ersten Einstieg in einen Bereich, bei ungewöhnlichen Bedienelementen, bei Stellen, an denen mehrere ähnliche Schaltflächen nebeneinanderliegen. Genau dort lohnt der Screenshot — und nur dort.

Mockups: wofür sie taugen

Mockups haben in der Softwaredokumentation einen klaren Platz, und er liegt zeitlich vor dem Screenshot. Wenn Dokumentation parallel zur Entwicklung entsteht – was in agilen Umgebungen der Normalfall ist –, existiert die Oberfläche zum Schreibzeitpunkt noch nicht oder nur teilweise. Ein Mockup aus dem Entwurfswerkzeug des Designteams schließt diese Lücke: Es zeigt, wie es aussehen soll, und erlaubt, die Beschreibung schon zu schreiben.

Zwei Bedingungen gehören dazu. Erstens muss ein Mockup als Entwurf erkennbar sein, solange es einen darstellt – entweder durch Kennzeichnung oder dadurch, dass es nur in internen Dokumenten erscheint. Ein Mockup, das ungekennzeichnet in einer ausgelieferten Anleitung landet, ist eine Produktdarstellung, die nicht stimmt. Zweitens braucht es einen Ablauf, der die Ersetzung sicherstellt: Sobald die Oberfläche fertig ist, wird das Mockup durch den echten Screenshot ersetzt.

Genau dieser zweite Punkt ist die Schwachstelle. Mockups, die in der Auslieferung überleben, sind ein verbreitetes Muster – niemand hat die Ersetzung nachgehalten, und das Bild sieht plausibel genug aus, um nicht aufzufallen. Die Gegenmaßnahme ist eine schlichte Liste der eingesetzten Mockups mit dem Vermerk, wann sie ersetzt werden – oder eine Kennzeichnung in der Bilddatei, die vor der Freigabe geprüft wird.

Ein Sonderfall betrifft Software, die beim Kunden individuell konfiguriert wird — Unternehmenssoftware mit anpassbaren Oberflächen, Branchenlösungen mit kundenspezifischen Feldern. Dort zeigt jeder Screenshot einen Zustand, den der einzelne Nutzer so womöglich nie sieht, weil seine Installation anders aussieht. Die Konsequenz ist nicht der Verzicht auf Bilder, sondern eine bewusste Entscheidung darüber, welchen Konfigurationsstand die Dokumentation abbildet — und ein Hinweis darauf, dass Abweichungen möglich sind.

In solchen Fällen verschiebt sich das Verhältnis zusätzlich zugunsten des Texts: Eine Beschreibung, die den Bereich und die Funktion benennt, trägt über Konfigurationen hinweg; ein Screenshot mit einer bestimmten Feldanordnung tut es nicht. Was hier hilft, sind Bilder, die auf das Unveränderliche zielen — Navigationsstruktur, Grundaufbau der Oberfläche — statt auf konfigurierbare Details.

Wo der Generator wirklich hilft

Nach so viel Abgrenzung die konstruktive Seite. In der Softwaredokumentation gibt es zwei Einsatzfelder, in denen Bildgeneratoren echten Nutzen bringen. Das erste sind Konzeptillustrationen: Bilder für Schulungsunterlagen, Kapiteleinstiege, Erklärungen abstrakter Zusammenhänge. Dort geht es nicht um die Oberfläche, und die üblichen Regeln für Konzeptdarstellungen gelten.

Das zweite Feld ist die Ideenfindung für Diagramme. Wer eine Systemarchitektur darstellen will und über die Bildaufteilung nachdenkt, kann sich Varianten erzeugen lassen – als Vorlage, nicht als Ergebnis. Das fertige Diagramm entsteht anschließend als Vektorgrafik, weil es beschriftet, textfrei mit Legende, aktualisierbar und in der Doku-Kette verwendbar sein muss. Der Generator liefert die Bildidee, nicht die Datei.

Was dagegen nicht funktioniert und regelmäßig versucht wird: eine Oberfläche generieren lassen, um sie als Illustration zu verwenden. Das Ergebnis sieht auf den ersten Blick nach Software aus und enthält bei genauerem Hinsehen unlesbare Beschriftungen, unlogische Bedienelemente und Anordnungen, die es so nicht gibt. Für ein Titelbild mag das genügen; sobald der Leser darin etwas erkennen soll, ist es unbrauchbar.

✓ Praxis-Tipp: Die Screenshot-Inventur Zähle in einer bestehenden Anleitung die Screenshots und markiere für jeden: Zeigt er etwas, das der Text nicht beschreibt? Braucht der Leser ihn zur Orientierung, oder illustriert er nur? Erfahrungsgemäß lässt sich ein erheblicher Teil ersatzlos streichen — und jeder gestrichene Screenshot muss nie wieder aktualisiert, übersetzt oder geprüft werden. Zähle im zweiten Schritt, wie viele der verbleibenden Vollbilder sind und sich auf einen Ausschnitt reduzieren ließen. Beide Maßnahmen zusammen senken den Pflegeaufwand oft deutlich, und sie kosten einen Nachmittag. Das ist der Einstieg, der sich lohnt, bevor über Automatisierung nachgedacht wird — denn was man automatisiert, sollte man vorher aufgeräumt haben.

 

ℹ Ein typischer Fall aus der Praxis Ein typischer Fall sieht so aus: Ein Softwarehersteller dokumentiert seine Anwendung in fünf Sprachen und liefert zweimal jährlich ein Release aus. Die Anleitung enthält rund achtzig Screenshots, die von Hand nachgezogen werden — eine Arbeit, die jedes Mal Tage bindet und regelmäßig unvollständig bleibt, weil unter Termindruck nur die auffälligsten aktualisiert werden. Die Umstellung erfolgte in zwei Schritten. Zuerst die Inventur: Von achtzig Screenshots blieben nach kritischer Prüfung knapp fünfzig übrig, und die Hälfte davon wurde auf Ausschnitte reduziert. Erst danach wurde die Aufnahme automatisiert — angedockt an die vorhandene Oberflächen-Testkette, was den Aufbau erheblich verkürzte. Seitdem entsteht der komplette Bildsatz in allen Sprachen in einem Durchlauf, und die Bilder in der Anleitung entsprechen zuverlässig der ausgelieferten Version.

 

Bleibt die Frage, wie sich das mit KI-Assistenten verträgt, die zunehmend auf Dokumentation zugreifen. Für sie gilt dasselbe wie im Beitrag zu KI-Agenten beschrieben: Was nur im Bild steht, ist unsichtbar. Ein Screenshot mit einer wichtigen Angabe im Bild — einem Wertebereich, einer Formatvorgabe, einer Fehlermeldung — kann von keinem Assistenten gelesen werden. Was der Nutzer dort sehen soll, gehört zusätzlich in den Text, und zwar nicht als Wiederholung, sondern als eigenständige Aussage.

Dieser Zusammenhang gibt der Sparsamkeitsregel einen zusätzlichen Grund. Wo ein Screenshot Text ersetzt, entsteht eine Lücke in allem, was auf Text angewiesen ist: Suche, Terminologieprüfung, Assistenten, Barrierefreiheit. Bilder ergänzen also den Text, statt ihn zu vertreten — und ein Alternativtext, der beschreibt, was zu sehen ist, gehört zu jeder Abbildung. Auch das ist keine neue Anforderung, sondern gute Praxis, die durch die digitale Nutzung dringlicher wird.

Der Zusammenhang mit der Lokalisierung

Ein Thema verdient zum Schluss besondere Aufmerksamkeit, weil es zwei Bereiche verbindet, die in vielen Häusern getrennt arbeiten: Softwarelokalisierung und Dokumentation. Wenn eine Anleitung beschreibt, dass man auf „Einstellungen" klicken soll, muss die Schaltfläche in der jeweiligen Sprachfassung genau so heißen. Weicht die Benennung ab – weil die Oberfläche anders übersetzt wurde als die Anleitung –, findet der Nutzer nichts.

Praktisch lösen lässt sich das nur über eine gemeinsame Terminologie: Die Oberflächenbegriffe gehören als feste Einträge in die Termbasis, mit ihren Entsprechungen in allen Zielsprachen, abgeglichen mit dem, was tatsächlich in der Software steht. Das ist Abstimmungsaufwand zwischen Entwicklung, Lokalisierung und Redaktion – und er ist unvermeidlich, weil sonst jede Sprachfassung der Anleitung an dieser Stelle Fehler enthält.

Screenshots machen diesen Zusammenhang sichtbar, weil sie beide Seiten zeigen: Was im Bild steht, kommt aus der Lokalisierung; was im Text steht, aus der Übersetzung der Anleitung. Stimmen beide nicht überein, fällt es sofort auf – und das ist ausnahmsweise ein Vorteil. In rein textlicher Dokumentation bleibt dieselbe Abweichung unbemerkt, bis ein Nutzer sich meldet.

Zum Schluss der Blick auf die Verankerung im Team, denn ohne sie halten diese Regeln nicht. Was hilft, ist eine knappe Bildkonvention — eine halbe Seite, die festhält: welche Bildquelle wofür, welche Fenstergröße und Skalierung, welches Namensschema, wie Markierungen gesetzt werden, wann ein Mockup ersetzt wird. Diese Seite gehört in den Styleguide und in die Einarbeitung; ohne sie entscheidet jeder für sich, und der Bestand franst über die Jahre aus.

Ergänzend lohnt ein fester Punkt in der Release-Vorbereitung: Welche Screenshots sind von den Oberflächenänderungen dieses Release betroffen? Diese Frage lässt sich beantworten, wenn die Entwicklung die Änderungen ohnehin dokumentiert — und sie verhindert genau das Muster, das Anleitungen unglaubwürdig macht: Bilder, die einen Zustand zeigen, den es seit drei Versionen nicht mehr gibt.

Fazit

Für Darstellungen der realen Oberfläche gibt es nur eine Quelle: den Screenshot aus der laufenden Software. Mockups gehören in die Phase davor und müssen ersetzt werden, sobald die Oberfläche existiert. Bildgeneratoren erzeugen keine brauchbaren Oberflächendarstellungen – ihr Platz sind Konzeptillustrationen und Bildvorlagen für Diagramme. Der Entscheidungsbaum ist damit flach, und die erste Frage entscheidet fast alles.

Die Kosten entstehen nicht bei der Aufnahme, sondern in der Pflege, multipliziert mit Sprachen und Releases. Dagegen helfen zwei Dinge: die Reduktion – der günstigste Screenshot ist der, den es nicht gibt – und die Automatisierung, die sich ab etwa drei Sprachen oder zwei Releases regelmäßig rechnet. Der beste erste Schritt ist die Screenshot-Inventur an einer bestehenden Anleitung. Wenn du bei Bildkonzept, Automatisierung oder der Abstimmung mit der Lokalisierung Unterstützung willst: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zu Bildern in der Software-Doku

Können wir Oberflächen von einer KI erzeugen lassen?

Für Darstellungen, in denen der Nutzer etwas wiederfinden soll, nicht. Der Grund ist zunächst technisch: Bildgeneratoren erzeugen Text im Bild unzuverlässig – Menüpunkte und Beschriftungen kommen häufig als verfremdete Wörter oder sinnlose Zeichenfolgen heraus. Der grundsätzlichere Grund ist derselbe wie bei Maschinenabbildungen: Ein Generator kennt die konkrete Anwendung nicht und erzeugt eine Oberfläche, die es geben könnte. Für Titelbilder und Konzeptillustrationen bleibt er nutzbar.

Wann lohnt sich die Automatisierung von Screenshots?

Als Faustregel ab etwa drei Sprachen oder zwei Releases im Jahr – und eindeutig, wenn beides zusammenkommt. Maßgeblich ist das Produkt aus Bildzahl, Sprachen und Releases: Zwanzig Bilder in vier Sprachen bei zwei Releases ergeben hundertsechzig Aufnahmen jährlich. Die wichtigere Vorfrage lautet allerdings, was schon existiert: Wo automatisierte Oberflächentests laufen, ist der Schritt klein, weil die Testkette im Kern dasselbe tut – Anwendung starten, navigieren, Zustand erfassen.

Wie halten wir Screenshots aktuell?

Am wirksamsten durch Reduktion: Jeder Screenshot, den es nicht gibt, muss nie aktualisiert werden. Danach durch Ausschnitte statt Vollbildern – ein Bild, das nur den relevanten Bereich zeigt, wird von Änderungen anderswo nicht ungültig. Und schließlich durch Automatisierung, sofern sich der Aufbau lohnt. Wichtig ist zusätzlich, Markierungen wie Pfeile und Ziffern in einer eigenen Ebene zu halten, damit sie den nächsten Aufnahmelauf überstehen und nicht jedes Mal neu gesetzt werden müssen.

Dürfen wir Mockups in ausgelieferter Dokumentation verwenden?

Nur gekennzeichnet und nur, solange die Oberfläche noch nicht existiert. Ein ungekennzeichnetes Mockup in einer ausgelieferten Anleitung ist eine Produktdarstellung, die nicht stimmt – der Nutzer sucht etwas, das anders aussieht. Wichtiger als die Kennzeichnung ist deshalb der Ablauf für die Ersetzung: eine Liste der eingesetzten Mockups mit Vermerk, wann sie ersetzt werden. Ohne diese Liste überleben Mockups regelmäßig bis in die Auslieferung, weil sie plausibel genug aussehen.

Was hat die Softwarelokalisierung damit zu tun?

Mehr, als in vielen Häusern beachtet wird. Wenn die Anleitung beschreibt, auf „Einstellungen" zu klicken, muss die Schaltfläche in jeder Sprachfassung genau so heißen – sonst findet der Nutzer nichts. Das gelingt nur über eine gemeinsame Terminologie: Oberflächenbegriffe als feste Einträge in der Termbasis, mit Entsprechungen in allen Zielsprachen, abgeglichen mit dem, was tatsächlich in der Software steht. Screenshots machen Abweichungen dabei sofort sichtbar – ein Vorteil, den rein textliche Dokumentation nicht hat.

 

Interne Links: Pillar (/technische-dokumentation/) · KI-Illustrationen in der Technischen Dokumentation (/ki-illustrationen-technische-dokumentation/) · Textfreie Grafiken und Übersetzungskosten (/textfreie-grafiken-uebersetzungskosten/) · Single-Source-Publishing (/single-source-publishing/) · Beratung (/technische-dokumentation-beratung/)