«Kannst du das Beitragsbild noch anpassen?»
Klingt harmlos. Ist es auch, solange alle dasselbe meinen. In WordPress ist das Beitragsbild (Featured Image) ein klar definiertes Konzept: das eine Bild, das du einem Beitrag zuweist und das in Übersichten, Social-Media-Previews und im Header auftaucht. Punkt.
Aber in der Praxis? Da meint die eine Person das Beitragsbild, die andere meint ein Bild mitten im Beitragsinhalt. Oder umgekehrt: Jemand sagt «Header-Bild» und meint eigentlich das Beitragsbild. Und dann geht das Hin und Her los. «Nein, nicht das Bild oben, das andere.» – «Welches andere?» – «Na, das im Text.» – «Da sind drei Bilder im Text.»
Ich habe solche Gespräche dutzende Male erlebt. Und jedes Mal denke ich: Die eigentliche Aufgabe hätte fünf Minuten gedauert. Die Begriffsklärung hat zwanzig gekostet.
Ein altes Problem mit einem Namen
Was ich gerade beschrieben habe, ist kein Einzelfall. Es ist ein Muster, das in fast jedem Projekt auftaucht. Ob WordPress-Website, App-Entwicklung oder Buchproduktion. Verschiedene Leute verwenden verschiedene Begriffe für dasselbe Ding. Oder denselben Begriff für verschiedene Dinge. Das Ergebnis: Missverständnisse, die sich still und leise durch ein Projekt fressen.
Dieses Problem hat in der Softwareentwicklung längst einen Namen: Ubiquitous Language, also: allgegenwärtige Sprache. Der Begriff stammt aus dem Buch «Domain-Driven Design» von Eric Evans aus dem Jahr 2003. Die Kernidee ist simpel: Alle Beteiligten eines Projekts, also Entwickler, Designer, Auftraggeber und Fachexperten, verwenden dieselben Begriffe für dieselben Dinge. Nicht nur im Code, sondern auch in Meetings, E-Mails, Tickets und Dokumentation.
Klingt offensichtlich? Ist es auch. Und trotzdem macht es fast niemand konsequent.
Was fehlende Klarheit wirklich kostet
Ich bin überzeugt: Wer keine gemeinsame Sprache im Projekt hat, nimmt ein enormes Risiko auf sich. Missverständnisse summieren sich. Und sie kosten nicht nur Zeit. Sie kosten Vertrauen, Qualität und manchmal ganze Features.
Ein paar Szenarien, die ich aus meinem Alltag kenne:
- Falsch gebaute Features: Der Kunde sagt «Kategorie», meint aber eine Taxonomie, die im System als «Tag» abgebildet ist. Das Feature wird gebaut, funktioniert. Aber es löst das falsche Problem.
- Aufgeblähte Meetings: Die Hälfte der Meetingzeit geht drauf, aneinander vorbeizureden und dann mühsam herauszufinden, was eigentlich gemeint war.
- Technische Schulden: Im Code steht
category, in der Datenbanktag, im Frontend «Thema» und im Ticket «Label». Vier Begriffe, ein Konzept. Viel Spass beim Onboarding neuer Teammitglieder. - Stille Post im Team: Eine Information wandert durch drei Personen, und bei jeder Station verschiebt sich die Bedeutung ein kleines Stück, weil jeder seine eigenen Begriffe verwendet.
Meine Einschätzung: Teams ohne bewusste Begriffsklärung verschwenden locker ein Drittel ihrer Kommunikationszeit mit Rückfragen, Korrekturen und Missverständnissen. Nicht weil die Leute inkompetent sind, sondern weil sie nie einen gemeinsamen Moment investiert haben, um sich auf eine Sprache zu einigen.
Wie du eine gemeinsame Sprache aufbaust
Die gute Nachricht: Es braucht keine schwere Methodik. Ein paar einfache Massnahmen machen einen riesigen Unterschied.
Am Projektstart: Begriffe klären
Nimm dir in einem Kick-off oder einer frühen Projektsitzung bewusst Zeit, die wichtigsten Fachbegriffe zu definieren. Das muss kein stundenlanger Workshop sein. Oft reichen 20–30 Minuten, in denen ihr gemeinsam klärt:
- Was meinen wir mit «Beitrag»? Was mit «Seite»?
- Was ist ein «Beitragsbild» vs. ein «Bild im Inhalt»?
- Ist ein «Kunde» ein Endkunde oder ein Auftraggeber?
- Was heisst «veröffentlicht»? Live auf der Website oder freigegeben im CMS?
Ein Glossar führen
Schreib die Begriffe auf. Es muss kein schickes Dokument sein. Ein simples Glossar in eurem Wiki, in der README, im Projektboard oder sogar in einem geteilten Google Doc reicht völlig. Hauptsache, es ist für alle zugänglich und wird bei Bedarf ergänzt.
Beispiel:
| Begriff | Bedeutung |
|---|---|
| Beitragsbild | Das Featured Image eines Beitrags (in WordPress: das eine zugewiesene Bild, nicht Bilder im Content) |
| Teaser | Die Kurzvorschau eines Beitrags in Übersichtslisten (Titel + Auszug + Beitragsbild) |
| Landingpage | Eine eigenständige Seite mit konkretem Conversion-Ziel (kein regulärer Beitrag) |
Korrekturen sind kein Affront
Wenn jemand im Meeting «Header-Bild» sagt und «Beitragsbild» meint: freundlich korrigieren. Nicht um besserwisserisch zu wirken, sondern weil jede unkorrigierte Begriffsverwirrung sich fortpflanzt. Je früher und selbstverständlicher das passiert, desto weniger fühlt es sich nach Belehrung an.
Im Code konsistent sein
Variablennamen, Datenbankfelder, API-Endpunkte, CSS-Klassen: idealerweise verwenden sie dieselben Begriffe wie das Glossar. Wenn im Glossar «featured_image» steht, heisst die Variable nicht header_pic und das CSS nicht .hero-banner. Das klingt nach Detailarbeit, aber genau diese Konsistenz macht ein Projekt langfristig wartbar.
Der LLM-Faktor: Warum es jetzt noch wichtiger wird
Alles, was ich bisher beschrieben habe, gilt seit Jahrzehnten. Aber jetzt kommt ein neuer Mitspieler ins Team: KI-Sprachmodelle. Und die machen das Thema noch einmal deutlich relevanter.
Warum? Weil ein LLM im Grunde der ultimative «neue Kollege» ist. Jedes Mal, wenn du mit Claude, ChatGPT oder Copilot arbeitest, steigt jemand frisch in deinen Kontext ein. Kein Vorwissen, keine Projekthistorie, keine Erinnerung an das Gespräch vom letzten Monat. Das Einzige, was das Modell hat, ist der Text, den du ihm gibst.
Und genau hier entfaltet eine Ubiquitous Language ihre volle Wirkung:
Konsistente Begriffe = bessere Ergebnisse
LLMs sind im Grunde Verstärker. Gibst du ihnen mehrdeutige Begriffe, verstärken sie die Verwirrung: Der generierte Code spiegelt das Chaos wider. Gibst du ihnen eine klare, konsistente Sprache, verstärken sie die Klarheit.
Konkretes Beispiel: Wenn du in deinem Prompt «Beitragsbild» sagst, in deiner Codebase aber thumbnail, featured_image und hero_image abwechselnd auftauchen, muss das LLM raten, was du meinst. Und Raten führt zu Fehlern.
Das ist keine Vermutung. Forschung zeigt: Wenn Variablen beschreibende Namen tragen, erreichen LLMs eine deutlich höhere Code-Qualität als bei kryptischen oder inkonsistenten Bezeichnungen. Bei Python-Code bricht die Leistung um über 75 % ein, wenn alle Namen anonymisiert werden.
Projektdokumentation als KI-Onboarding
Viele Teams legen inzwischen eine Projektdatei an, die KI-Werkzeugen den Kontext gibt: eine CLAUDE.md, eine AGENTS.md oder eine eigene domain-terms.md. Ein Glossar mit klar definierten Fachbegriffen darin wird zum Onboarding-Dokument für jede KI, die am Projekt mitarbeitet. Es spart dir bei jeder Interaktion Erklärungszeit.
Code wird lesbarer: für Menschen und Maschinen
Wenn dein Code konsistente, sprechende Begriffe verwendet, können LLMs ihn besser verstehen, verständlicher erklären und bessere Änderungen vorschlagen. Eine Funktion namens get_featured_image() ist für ein LLM (und für dich in sechs Monaten) unendlich hilfreicher als get_fi() oder fetch_img_main().
Vom Prinzip zum Werkzeug
Inzwischen gibt es sogar Werkzeuge, die das systematisch unterstützen. In der Spec-Driven-Development-Bewegung, die 2025/2026 an Fahrt aufgenommen hat, pflegen KI-gestützte IDEs automatisch ein lebendes Glossar. Wenn du in einer Spezifikation «Bestellung» schreibst, fragt das System nach: Meinst du eine Kundenbestellung oder einen internen Auftrag? Die Begriffsklärung passiert also nicht mehr nur im Kick-off-Meeting, sondern direkt im Entwicklungsprozess.
Die Investition, die sich auszahlt
Ich weiss, was du jetzt vielleicht denkst: «Klingt sinnvoll, aber wer hat am Projektstart schon Zeit für Begriffsklärung?» Die ehrliche Antwort: Du hast keine Zeit, es nicht zu tun.
Jedes Projekt, bei dem ich am Anfang ein Glossar erstellt habe, lief merklich runder. Weniger Rückfragen, schnelleres Onboarding neuer Teammitglieder, weniger «Ach, das meintest du»-Momente. Und seit ich intensiv mit KI-Werkzeugen arbeite, merke ich den Effekt noch stärker: Meine Prompts sind präziser, die Ergebnisse brauchbarer, der Hin-und-her-Aufwand geringer.
Ubiquitous Language ist kein akademisches Konzept. Es ist eine Gewohnheit. Und eine, die sich in jedem Projekt lohnt. Ob du zu zweit eine WordPress-Site baust oder in einem grossen Team eine Plattform entwickelst.
Was meint ihr? Habt ihr schon mal erlebt, dass ein unklarer Begriff ein Projekt ausgebremst hat? Oder führt ihr in euren Projekten ein Glossar? Ich bin gespannt auf eure Geschichten. Schreibt sie mir in die Kommentare.
Quellen:
- Evans, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003
- Schleicher, Daniel: How Creating a Ubiquitous Language Ensures AI Builds What You Actually Want, danielschleicher.com, 2026
- Deng et al.: How Does Naming Affect LLMs on Code Analysis Tasks?, arxiv, 2023
Über mich
2 Kommentare
Guter Artikel. Und zur letzten Frage; seit dem ich ausschließlich für den Endkunden direkt arbeite, werden Projekte durch unklare Begriffe ständig ausgebremst, auch durch unklare Briefings. Das war früher während der Zusammenarbeit mit Agenturen so gut wie nie ein Problem. Vielleicht sollte ich wirklich ein Glossar einführen.
Danke, Achim! Und das ist ein richtig spannender Punkt, den du da ansprichst.
Wenn ich darüber nachdenke, ergibt das total Sinn: Agenturen arbeiten oft mit etablierten Prozessen und haben intern schon eine gemeinsame Fachsprache. Die Briefings sind strukturierter, die Begriffe klarer, weil das Team sie täglich benutzt. Beim Endkunden fehlt diese «eingespielte Sprache» naturgemäss. Der Kunde kennt sein Geschäft, du kennst dein Handwerk, aber die Schnittmenge der Begriffe ist erstmal klein.
Das Glossar würde ich an deiner Stelle wirklich ausprobieren. Es muss ja nichts Aufwändiges sein. Selbst ein kurzes Dokument mit zehn, fünfzehn Begriffen, das du am Projektstart gemeinsam mit dem Kunden durchgehst, kann schon viel bewirken. Und es hat einen schönen Nebeneffekt: Der Kunde fühlt sich abgeholt, weil du seine Sprache ernst nimmst.
Berichte gerne, falls du es umsetzt. Würde mich interessieren, wie es bei dir in der Praxis ankommt.