Eine Produkttour, die auf Englisch geschrieben ist und einem Nutzer angezeigt wird, der auf Deutsch arbeitet, ist keine halbwegs hilfreiche Tour. Sie ist eine Unterbrechung. Der Nutzer schließt sie, und weil die meisten Onboarding-Flows nur einmal ausgelöst werden, sieht er diese Hilfe nie wieder, in keiner Sprache.
Die meisten SaaS-Produkte lokalisieren ihre Oberfläche lange bevor sie die Onboarding-Ebene lokalisieren. Das Ergebnis ist kurios: eine vollständig übersetzte Anwendung, umhüllt von englischen Tooltips. Diese Lücke lässt sich günstig schließen und kommt teuer zu stehen, wenn man sie offen lässt, denn das Onboarding ist der eine Teil des Produkts, in dem Verständnis nicht optional ist.
Dieser Leitfaden zeigt, wie Sie entscheiden, welche Sprachen Sie unterstützen, wie Sie die richtige erkennen, welche konkreten UI-Probleme Übersetzungen in Tooltips und Modals verursachen und wie Sie verhindern, dass lokalisierte Hilfe veraltet.
Textexpansion ist der Fehler, der erst in Produktion auffällt und nicht schon im Review.
Das Wichtigste in Kürze
- Unübersetztes Onboarding ist schlechter als gar keins. Eine geschlossene Tour kommt meist nie zurück, ein schlechter erster Eindruck kostet Sie also den ganzen Flow.
- Folgen Sie der Einstellung des Nutzers, nicht der des Browsers. Eine ausdrücklich gewählte Produktsprache schlägt eine abgeleitete Spracheinstellung jedes Mal.
- Planen Sie 35 % mehr Breite als im Englischen ein. Deutsch und Finnisch sprengen regelmäßig Layouts, die für englische Texte entworfen wurden.
- Übersetzen Sie auch die Auslöselogik. Element-Selektoren und Seiten-URLs unterscheiden sich oft zwischen Sprachversionen und lassen Touren unbemerkt scheitern.
- Auch Screenshots müssen lokalisiert werden. Ein übersetzter Tooltip, der auf einen englischen Screenshot zeigt, verwirrt mehr als jedes der beiden für sich.
- Versionieren Sie den Ausgangstext, nicht die Übersetzungen. Jede Änderung am englischen Text muss seine Übersetzungen ungültig machen, sonst laufen Ihre Sprachversionen still auseinander.
Warum lokalisiertes Onboarding wichtiger ist als eine lokalisierte Oberfläche
Erfahrene Nutzer finden sich in einer teilweise englischen Oberfläche zurecht, indem sie Layout und Icons wiedererkennen. Ganz neue Nutzer können das nicht, weil sie noch kein mentales Modell des Produkts haben, und genau beim Onboarding trägt jedes Wort die ganze Last.
Daraus ergeben sich drei Folgen, die sich gegenseitig verstärken:
- Wegklicken ist endgültig. Onboarding-Flows werden in der Regel einmal angezeigt. Wer eine unverständliche Tour schließt, hat sie nicht aufgeschoben, sondern verloren.
- Die Support-Last verlagert sich. Fragen, die In-App-Hilfe beantwortet hätte, landen in einem Kanal, in dem sie echtes Geld kosten, und oft in einer Sprache, die Ihr Support-Team ebenfalls nicht abdeckt.
- Ihre Aktivierungsdaten führen Sie in die Irre. Regionale Aktivierungslücken werden dem Market Fit oder der Preisgestaltung zugeschrieben, obwohl die eigentliche Ursache ist, dass der halbe Markt in einer Sprache onboardet wurde, in der er nicht arbeitet.
Die Analyse, die sich vor allem anderen lohnt: Segmentieren Sie Aktivierungs- und Onboarding-Abschlussraten nach Nutzersprache. Liegen Ihre nicht-englischen Segmente deutlich zurück, während ihr Engagement im Kernprodukt vergleichbar ist, haben Sie ein Lokalisierungsproblem und kein Marktproblem, und das lässt sich wesentlich günstiger beheben.
Welche Sprachen Sie unterstützen sollten
Onboarding zu lokalisieren ist nicht kostenlos: Jede Sprache vervielfacht den Pflegeaufwand jedes einzelnen Flows. Die Entscheidung sollte sich an Daten orientieren, nicht an Ambitionen.
| Signal | Worauf Sie achten sollten | Warum es zählt |
|---|---|---|
| Bestehende Nutzerbasis | Sprachverteilung der aktiven Accounts | Die günstigsten Erfolge sind Nutzer, die Sie bereits haben und bisher unzureichend bedienen. |
| Aktivierungslücke | Abschlussraten je Sprachsegment | Zeigt die Sprache, in der Lokalisierung das Verhalten am stärksten verändert. |
| Umsatzkonzentration | ARR nach Region | Wenige Nutzer können überproportional viel Umsatz tragen. |
| Support-Last | Ticketvolumen pro Account nach Region | Viele Tickets bei geringer Nutzung der In-App-Hilfe deuten auf Übersetzungsbedarf hin. |
| Sales-Pipeline | Deals, die an Sprachanforderungen hängen | Enterprise-Käufer in manchen Märkten behandeln die Sprache als Beschaffungsanforderung. |
Eine pragmatische Reihenfolge: Beginnen Sie mit den zwei Sprachen, in denen Sie bereits Nutzer haben, nicht mit den zehn, in denen Sie sich welche erhoffen. Der Pflegeaufwand für lokalisiertes Onboarding wächst mit jeder Sprache, und ein gut gepflegtes Paar ist besser als sechs Sprachversionen, die innerhalb eines Quartals veralten.
So erkennen Sie die richtige Sprache
Wenn die Spracherkennung danebenliegt, ist die ganze Übersetzungsarbeit umsonst; eine französische Nutzerin, der deutsche Hilfe angezeigt wird, ist schlechter dran als eine, die englische sieht. Halten Sie sich an diese Rangfolge:
Eine ausdrücklich gewählte Sprache im Nutzerprofil
Die Sprache, in der die Anwendungsoberfläche gerade angezeigt wird
Ein Standard auf Account- oder Workspace-Ebene
Die Browsersprache, als letztes Mittel
Eine festgelegte Fallback-Sprache, niemals ein leerer Bildschirm
Warum die Browsersprache ein schwaches Hauptsignal ist
Die Spracheinstellung des Browsers zeigt, wo das Gerät eingerichtet wurde, nicht wie die Person arbeitet. Entwickler und Mitarbeitende internationaler Unternehmen nutzen häufig ein englisches Betriebssystem, arbeiten aber in einer anderen Sprache, und gemeinsam genutzte oder zentral aufgesetzte Firmengeräte melden eine Sprache, die niemand gewählt hat. Wenn Ihr Produkt bereits eine Spracheinstellung hat, ist diese Einstellung die Antwort: Sie ist eine ausdrückliche Präferenz und keine Vermutung.
Legen Sie immer einen Fallback fest
Ein Nutzer, für dessen Sprache es keine Übersetzung gibt, muss die Fallback-Sprache sehen, keinen leeren Tooltip und keinen rohen Übersetzungsschlüssel. Wählen Sie den Fallback bewusst und stellen Sie sicher, dass ein fehlender Text nie als Leere erscheint; eine stille Lücke fällt beim Testen viel schwerer auf als ein sichtbar englischer Text in einem französischen Flow.
Die UI-Probleme, die Übersetzungen verursachen
Onboarding zu lokalisieren ist nicht nur eine inhaltliche Aufgabe. Hilfe-Overlays sind an eine lebende Oberfläche gekoppelt, und die Übersetzung verändert diese Oberfläche.
1. Textexpansion sprengt feste Layouts
Aus dem Englischen übersetzt sind deutsche und finnische Texte häufig 30–35 % länger, französische etwa 20–25 %. Ein Tooltip, der genau für „Save changes“ bemessen ist, schneidet „Änderungen speichern“ ab.
Gestalten Sie Onboarding-Texte für Ihre längste Sprache, lassen Sie Container in der Höhe wachsen und fixieren Sie nie die Höhe eines Tooltips. Die zugehörige Disziplin besteht schlicht darin, kürzere Ausgangstexte zu schreiben: Dieselben Microcopy-Regeln, die englische Hilfetexte gut machen, machen sie auch übersetzungsfest.
2. Elementpositionen und Selektoren verschieben sich
Das ist der Fehler, der am häufigsten unbemerkt bleibt. Touren sind an bestimmte Elemente gekoppelt, und wenn ein Selektor von sichtbarem Text abhängt (einer Button-Beschriftung, einem ARIA-Label, einem aus dem Text abgeleiteten Data-Attribut), greift er in einer anderen Sprache nicht mehr. Die Tour zeigt dann ins Leere oder startet stillschweigend gar nicht.
Verankern Sie Touren an stabilen, sprachunabhängigen Attributen wie IDs oder eigens dafür angelegten Data-Attributen, und testen Sie jede Tour in jeder Sprache, statt davon auszugehen, dass sich nur der übersetzte Text unterscheidet.
Jeder Schritt einer Tour ist an ein lebendes Element gekoppelt, und genau das verschiebt die Übersetzung.
3. Auch Screenshots und Videos müssen lokalisiert werden
Ein übersetzter Tooltip, der auf einen englischen Screenshot zeigt, verwirrt mehr als ein englischer Tooltip, der auf einen englischen Screenshot zeigt, weil sich die beiden jetzt widersprechen. Lokalisieren Sie entweder die Bilder oder gestalten Sie Hilfe, die nicht auf sie angewiesen ist; bei Aufgaben, die Nutzer zum ersten Mal erledigen, umgeht ein interaktiver Walkthrough durch die echte, bereits übersetzte Oberfläche das Problem komplett.
4. Formate und Konventionen unterscheiden sich
Datumsangaben, Zahlen, Währungen und die Reihenfolge von Namen variieren. Ein Onboarding-Text, der sagt „Geben Sie das Datum als MM/TT/JJJJ ein“, ist im größten Teil der Welt falsch. Verweisen Sie auf das Format, das das Produkt in dieser Sprache tatsächlich anzeigt, statt ein Beispiel fest einzutragen.
5. Rechts-nach-links ist eine Layoutänderung, keine Übersetzung
Arabisch und Hebräisch spiegeln das gesamte Layout: Tooltip-Anker, Pfeilrichtungen, Fortschrittsanzeigen und die Bedeutung von „weiter“. Wenn RTL auf Ihrer Roadmap steht, prüfen Sie vor der Festlegung, ob Ihre Hilfeebene einen Richtungswechsel unterstützt; das nachträglich einzubauen ist deutlich aufwendiger als das Übersetzen.
So verhindern Sie, dass übersetztes Onboarding verrottet
Das vorhersehbare Scheitern liegt nicht in der ersten Übersetzung. Es kommt in Monat sieben, wenn der englische Flow viermal überarbeitet wurde und die deutsche Version noch einen Bildschirm beschreibt, den es nicht mehr gibt.
Die vier Gewohnheiten, die Abweichungen verhindern
- Behandeln Sie eine Sprache als einzige Quelle der Wahrheit. Alle Änderungen finden dort statt; die Übersetzungen leiten sich davon ab. Wer Sprachversionen unabhängig voneinander bearbeitet, garantiert Abweichungen.
- Versionieren Sie den Ausgangstext. Ändert sich der Ausgangstext, werden seine Übersetzungen automatisch als veraltet markiert; dieser eine Mechanismus verhindert die meisten Abweichungen.
- Machen Sie die Lokalisierung zum Teil der Release-Checkliste. Ein Feature ist nicht ausgeliefert, wenn die englische Tour live ist, sondern wenn jede unterstützte Sprache live ist.
- Prüfen Sie in der echten Oberfläche, nicht in einer Tabelle. Wer mit einer Textliste übersetzt, sieht nicht, dass ein Button jetzt 40 Pixel zu schmal ist.
Was Sie übersetzen sollten und was nicht
✅ Übersetzen
- Alle Texte in Tooltips, Modals und Checklisten
- Button- und CTA-Beschriftungen
- Umfragefragen und Antwortoptionen
- Titel und Texte von Ankündigungen
- Texte für Empty States
- Fehler- und Validierungsmeldungen in geführten Flows
❌ Nicht anfassen
- Produkt- und Featurenamen, die Sie in der Oberfläche nicht lokalisiert haben
- Element-Selektoren und interne Kennungen
- Segmentnamen und interne Flow-Bezeichnungen
- Alles, was sich auf einen unübersetzten UI-Text bezieht
- Codebeispiele und API-Referenzen
Die Konsistenzregel: Hilfetexte müssen genau die Wörter verwenden, die die Oberfläche in dieser Sprache verwendet. Wenn Ihre deutsche Oberfläche einen Button mit „Speichern“ beschriftet, muss der deutsche Tooltip „Speichern“ sagen und kein Synonym, das ein Übersetzer bevorzugt hat. Hilfe, die ein Bedienelement anders benennt als das Element selbst, ist schlechter als gar keine, weil der Nutzer nun nach etwas sucht, das es nicht gibt.
Mehrsprachiges Onboarding mit Kompassify umsetzen
Die Lokalisierung des Onboardings wird meist aufgeschoben, weil sie ein weiteres Entwicklungsprojekt bedeutet. Eine No-Code-Hilfeebene ändert das: Die Flows und ihre Übersetzungen liegen außerhalb der Codebasis, eine neue Sprache erfordert also kein Release.
- Ein Flow, mehrere Sprachen. Erstellen Sie eine Produkttour einmal und pflegen Sie ihre Übersetzungen direkt daneben, damit die Logik zwischen den Sprachversionen nie auseinanderläuft.
- Sprachbewusstes Targeting. Spielen Sie die richtige Version anhand der Produktsprache des Nutzers aus, statt aus dem Browser zu raten.
- Lokalisierte Checklisten und Tooltips, damit die gesamte Onboarding-Ebene eine Sprache spricht und nicht nur der größte Teil davon.
- Übersetzte Ankündigungen, damit Feature-Launches in allen Märkten gleichzeitig ankommen.
- Analytics pro Sprache, um zu bestätigen, dass der lokalisierte Flow die Lücke bei den Abschlussraten tatsächlich geschlossen hat.
Kompassify ist eine No-Code-Digital-Adoption-Plattform für SaaS-Teams. Kostenlos bis 100 monatlich aktive Nutzer, kostenpflichtige Pläne ab $129/Monat, DSGVO-konform mit Hosting in der EU.
Onboarden Sie jeden Nutzer in seiner eigenen Sprache
Erstellen Sie den Flow einmal, pflegen Sie seine Übersetzungen direkt daneben und spielen Sie automatisch die richtige Version aus, ohne Release.
Kostenlos starten →Häufig gestellte Fragen
Warum muss das Onboarding lokalisiert werden, wenn die Oberfläche es schon ist?
Weil beim Onboarding jedes Wort die ganze Last trägt. Erfahrene Nutzer finden sich in einer teilweise englischen Oberfläche zurecht, indem sie Layout und Icons wiedererkennen. Ganz neue Nutzer haben dagegen noch kein mentales Modell des Produkts. Hinzu kommt: Onboarding-Flows werden meist nur einmal angezeigt. Wer eine unverständliche Tour schließt, hat sie nicht aufgeschoben, sondern für immer verloren.
In welche Sprachen sollte ich mein Onboarding zuerst lokalisieren?
Beginnen Sie mit den Sprachen, in denen Sie bereits Nutzer haben, nicht mit den Märkten, die Sie erobern möchten. Betrachten Sie die Sprachverteilung der aktiven Accounts, die Aktivierungslücke je Sprachsegment, die Umsatzkonzentration nach Region und das Support-Ticketvolumen. Jede zusätzliche Sprache vervielfacht den Pflegeaufwand. Zwei gut gepflegte Sprachversionen sind deshalb besser als sechs, die innerhalb eines Quartals veralten.
Wie erkenne ich, welche Sprache angezeigt werden soll?
Halten Sie sich an diese Rangfolge: zuerst eine ausdrücklich gewählte Sprache im Nutzerprofil, dann die Sprache, in der die Anwendungsoberfläche gerade angezeigt wird, dann ein Standard auf Account- oder Workspace-Ebene und erst danach die Browsersprache. Die Browsersprache ist ein schwaches Hauptsignal, weil sie widerspiegelt, wie das Gerät eingerichtet wurde, nicht wie die Person arbeitet. Legen Sie immer eine Fallback-Sprache fest, damit eine fehlende Übersetzung als lesbarer Text erscheint statt als leerer Tooltip oder roher Schlüssel.
Was geht kaputt, wenn man In-App-Hilfe übersetzt?
Fünf Dinge. Die Textexpansion, denn deutsche und finnische Texte sind typischerweise 30 bis 35 % länger als englische und werden in Tooltips mit fester Breite abgeschnitten. Element-Selektoren, die von sichtbarem Text abhängen: Sie greifen in anderen Sprachen nicht mehr und lassen Touren unbemerkt scheitern. Screenshots, die noch die englische Oberfläche zeigen. Datums-, Zahlen- und Währungsformate, auf die sich Texte beziehen. Und rechts-nach-links-Sprachen, die das gesamte Layout spiegeln, statt nur die Wörter zu ändern.
Wie viel zusätzlichen Platz sollte ich für übersetzte Onboarding-Texte einplanen?
Planen Sie rund 35 % mehr Breite ein als für die englische Version. Das deckt Deutsch und Finnisch ab, die Sprachen mit der stärksten Expansion. Französisch ist typischerweise 20 bis 25 % länger. Gestalten Sie die Texte für Ihre längste unterstützte Sprache, lassen Sie Container in der Höhe wachsen und fixieren Sie nie die Höhe eines Tooltips. Kürzere Ausgangstexte zu schreiben ist die günstigste Gegenmaßnahme überhaupt.
Wie verhindert man, dass übersetztes Onboarding veraltet?
Vier Gewohnheiten verhindern fast jede Abweichung. Behandeln Sie eine Sprache als einzige Quelle der Wahrheit, sodass alle Änderungen dort stattfinden. Versionieren Sie den Ausgangstext, damit seine Übersetzungen bei jeder Änderung automatisch als veraltet markiert werden. Machen Sie die Lokalisierung zum Teil der Release-Checkliste, sodass ein Feature erst als ausgeliefert gilt, wenn jede unterstützte Sprache live ist. Und prüfen Sie Übersetzungen in der echten Oberfläche statt in einer Tabelle, denn wer mit einer Textliste arbeitet, sieht nicht, dass ein Button inzwischen zu schmal ist.
Was sollte in Onboarding-Flows nicht übersetzt werden?
Produkt- und Featurenamen, die Sie in der Oberfläche nicht lokalisiert haben, Element-Selektoren und interne Kennungen, Segmentnamen und interne Flow-Bezeichnungen, Codebeispiele und API-Referenzen sowie alles, was sich auf einen UI-Text bezieht, der selbst unübersetzt bleibt. Die maßgebliche Regel ist Konsistenz: Hilfetexte müssen genau die Wörter verwenden, die die Oberfläche in dieser Sprache verwendet. Ein Tooltip, der ein Bedienelement anders benennt als das Element selbst, schickt Nutzer auf die Suche nach etwas, das es nicht gibt.
Brauche ich Entwicklungsarbeit, um Produkttouren zu lokalisieren?
Nicht, wenn die Hilfeebene außerhalb Ihrer Codebasis liegt. Die Lokalisierung des Onboardings wird meist aufgeschoben, weil sie als weiteres Entwicklungsprojekt gilt. Mit einer No-Code-Digital-Adoption-Plattform werden die Flows und ihre Übersetzungen nebeneinander gepflegt. Eine neue Sprache erfordert dann kein Release, und die Logik kann zwischen den Sprachversionen nicht auseinanderlaufen.