Deutsch in einfacher Sprache als eigener Ausgabekanal.

Eine mehrsprachige Plattform kann neben Englisch, Französisch oder Italienisch auch eine weitere deutsche Fassung anbieten: Deutsch in einfacher Sprache.

Technisch lässt sich diese Fassung wie eine zusätzliche Locale behandeln. Fachlich ist sie jedoch keine normale Übersetzung. Ausgangs- und Zielsprache sind beide Deutsch. Verändert werden Satzbau, Wortwahl, Informationsdichte und teilweise die Struktur der Darstellung.

Das Ziel ist nicht, Inhalte zu verkürzen oder zu verniedlichen. Das Ziel ist, dieselbe relevante Information für mehr Menschen verständlich und handlungsfähig zu machen.

Einfache Sprache und Leichte Sprache unterscheiden

„Einfache Sprache" ist ein vergleichsweise flexibler Ansatz für verständlichere Kommunikation. „Leichte Sprache" wird in vielen Kontexten mit deutlich strengeren Regelwerken, besonderen Darstellungsformen und spezifischen Prüfprozessen verbunden.

Eine Plattform sollte deshalb klar benennen, welches Ziel sie verfolgt. Wird eine formale oder zertifizierte Leichte-Sprache-Fassung benötigt, genügt ein automatisierter KI-Prozess allein nicht; dann sind die dafür vorgesehenen fachlichen Prüfungen und gegebenenfalls Prüfgruppen einzuplanen.

Dieser Insight bezieht sich auf einen eigenen digitalen Ausgabekanal „Deutsch – einfache Sprache", der nach definierten internen Qualitätsregeln betrieben wird.

Für wen einfache Sprache hilfreich sein kann

Verständlichere Texte können unter anderem helfen:

• Menschen mit geringer Lesesicherheit,
• Menschen, die Deutsch lernen,
• Nutzern mit kognitiven Einschränkungen,
• Menschen unter Stress oder Zeitdruck,
• älteren Nutzern,
• allen, die einen komplexen Prozess zum ersten Mal durchführen.

Einfache Sprache ist damit nicht nur ein Spezialmodus für eine kleine Gruppe. Klare Handlungsanweisungen und reduzierte Komplexität verbessern häufig das Produkt insgesamt.

Nicht jeden Text automatisch vereinfachen

Eine Plattform sollte priorisieren, welche Prozesse in einfacher Sprache angeboten werden.

Besonders relevant:

• Registrierung,
• Anmeldung und Passwortwiederherstellung,
• Suche und Auswahl,
• Buchung oder Bestellung,
• Zahlung,
• Storno und Kündigung,
• Fehlermeldungen,
• Datenschutz- und Einwilligungshinweise in ergänzender verständlicher Form,
• Support und Kontakt,
• Anbieterbeschreibungen mit hoher Nutzerrelevanz.

Weniger sinnvoll ist es, jede interne technische Bezeichnung oder jeden seltenen Administrationsbereich sofort vollständig umzuschreiben.

Sprachliche Prinzipien als maschinenlesbare Regeln

Die Pipeline benötigt klare Vorgaben. Mögliche Regeln:

• kurze Sätze,
• möglichst eine Hauptaussage pro Satz,
• aktive und direkte Verben,
• konkrete Subjekte statt unklarer Passivformen,
• bekannte Wörter bevorzugen,
• unvermeidbare Fachbegriffe erklären,
• Abkürzungen ausschreiben,
• Pronomen mit unklarem Bezug vermeiden,
• wichtige Handlung zuerst nennen,
• Listen für mehrere Schritte verwenden,
• Zahlen, Termine und Fristen eindeutig darstellen,
• negative oder doppelt negative Formulierungen vermeiden.

Beispiel:

Regulär:

Einfache Sprache:

Die Information bleibt vollständig, wird aber in zwei klare Handlungen zerlegt.

Bedeutung darf nicht verloren gehen

Sprachliche Vereinfachung darf Rechte, Pflichten, Bedingungen oder Einschränkungen nicht verändern.

Besonders kritisch sind:

• Preis und Zahlungswirkung,
• Vertragsabschluss,
• Kündigungs- und Stornofristen,
• Einwilligungen,
• Haftungs- und Sicherheitshinweise,
• Anspruchsvoraussetzungen,
• Zugangsbeschränkungen.

Für solche Inhalte kann die einfache Fassung ergänzend zur rechtlich maßgeblichen Originalfassung angezeigt werden. Die genaue Produkt- und Rechtsgestaltung muss zum jeweiligen Anwendungsfall passen.

Technisch sollte gespeichert sein:

• welche reguläre Version zugrunde liegt,
• wann die einfache Fassung erstellt wurde,
• ob sie fachlich geprüft ist,
• ob sie durch eine Quelländerung veraltet wurde.

Einfache Sprache kann mehr Platz benötigen

Ein verbreitetes Missverständnis lautet, einfache Sprache sei immer kürzer. Häufig werden Sätze zwar kürzer, aber zusätzliche Erklärungen benötigt.

Das beeinflusst die UI:

• Buttons dürfen nicht mit langen Erklärungen überladen werden.
• Hilfetext kann direkt unter der Aktion erscheinen.
• komplexe Absätze werden in mehrere Schritte zerlegt.
• Dialoge benötigen eventuell mehr Höhe.
• Tabellen oder kompakte Fachansichten brauchen ergänzende Erklärungen.
• mobile Layouts müssen längere Texte tragen.

Der Sprachmodus ist deshalb auch eine Design- und Komponentenanforderung.

Eine eigene Pipeline statt eines einzelnen Prompts

Ein sinnvoller Ablauf:

regulärer deutscher Quelltext + Kontext + Content Class
        ↓
KI erzeugt Fassung in einfacher Sprache
        ↓
formale Regeln prüfen
        ↓
semantische Vollständigkeit vergleichen
        ↓
abhängig vom Risiko: Review
        ↓
veröffentlichen und Feedback ermöglichen

Formale Prüfungen können beispielsweise Satzlänge, Abkürzungen, Passivhäufigkeit oder unerklärte Fachbegriffe markieren. Sie ersetzen keine fachliche Bewertung, machen aber Auffälligkeiten sichtbar.

UI-Texte und Inhaltsseiten unterschiedlich behandeln

UI-Texte

Ein kurzer regulärer Button bleibt möglicherweise gleich. Die Erklärung wird in einen Hilfetext ausgelagert.

Beispiel:

Button:    „Kostenpflichtig buchen"
Hilfetext: „Wenn Sie hier klicken, buchen Sie das Angebot.
            Danach müssen Sie den Preis bezahlen."

Längere Inhalte

Sie können in kleinere Abschnitte, Listen und direkte Fragen gegliedert werden.

Anbieterinhalte

Automatische Vereinfachung muss klar vom originalen Anbietertext getrennt bleiben. Bei unklaren Quellen darf die KI keine fehlenden Informationen erfinden.

Terminologie und Wiedererkennung

Einfache Sprache bedeutet nicht, für denselben Begriff ständig neue Umschreibungen zu verwenden. Konsistenz ist besonders wichtig.

Ein Glossar kann definieren:

• „Anbieter" statt wechselnd „Verkäufer", „Partner" oder „Veranstalter",
• „Buchung" für reservierte Leistungen,
• „Bestellung" für gekaufte Waren,
• Erklärung eines Fachbegriffs beim ersten Auftreten,
• danach gleiche Bezeichnung.

Auch Icons und Farben sollten dieselbe Bedeutung wie in der regulären Fassung behalten.

Qualität prüfen

Mögliche Prüfdimensionen:

• Ist die zentrale Aussage vollständig?
• Ist die Handlung klar?
• Sind Bedingungen und Fristen erhalten?
• Enthält der Text neue, nicht belegte Aussagen?
• Sind Sätze und Absätze angemessen kurz?
• Werden Begriffe konsistent verwendet?
• Ist der Text in der tatsächlichen UI verständlich?
• Kann ein Nutzer den Prozess ohne Rückgriff auf die reguläre Fassung abschließen?

Für zentrale Prozesse sind Tests mit Menschen aus den relevanten Nutzergruppen besonders wertvoll. Automatische Lesbarkeitswerte allein belegen keine Verständlichkeit.

Feedback als Teil des Kanals

Nutzer können melden:

• „Das Wort verstehe ich nicht"
• „Der nächste Schritt ist unklar"
• „Die einfache Fassung sagt etwas anderes"
• „Der Text ist noch zu kompliziert"
• „Eine wichtige Information fehlt"

Die Meldung wird direkt der einfachen Zielversion und ihrer regulären Quelle zugeordnet. Bestätigte Korrekturen fließen in Glossar und zukünftige Regeln ein.

Fallbacks

Wenn eine einfache Fassung fehlt oder veraltet ist, sollte die Plattform bewusst reagieren:

• reguläre deutsche Fassung mit Hinweis anzeigen,
• kritischen Prozess in einfacher Sprache vorübergehend blockieren,
• automatisch eine neue Fassung erzeugen und kennzeichnen,
• Review priorisieren.

Welche Option gilt, hängt von Risiko und Produktversprechen ab.