Du sitzt in der vierten Stunde eines Naming-Workshops. Fünf Personen, ein leeres Flipchart, und irgendwer schlägt wieder „Brandify“ vor. Bei einem White-Label-Unternehmen mit 30 neuen Produkten pro Quartal ist das nicht skalierbar – es ist ein Burnout-Generator. Also habe ich gebaut, was fehlte: ein internes Tool, das kreative Prozesse nicht ersetzt, sondern intelligent strukturiert.
Das Problem: Kreativität braucht Grenzen
Naming ist ein seltsames Handwerk. Es ist gleichzeitig künstlerisch und datengetrieben, intuitiv und methodisch. Der klassische Prozess sieht so aus: Briefingrunde, Brainstorming, manuelle Domain-Checks, parallele Markenrecherche, Diskussionen, Überarbeitungen. Bei großen Unternehmen mit mehreren Produktlinien wird das zur Zeitfalle.
Das Kernproblem war nicht die fehlende Kreativität im Team. Das Problem war die Struktur: Weder hatten wir klare Kriterien, noch konnten wir schnell iterieren. Jede neue Ideenrunde war ein Neustart statt eine Verfeinerung.
Dann kam die Frage: Was, wenn wir diesen Prozess strukturieren und in einen Vorgang mit intuitiver UI gießen könnten?
Entscheidung: Parameter statt Freitext-Prompts
Ich hätte zwei Wege gehen können. Der erste: Ein einfaches Interface, bei dem jede Person direkt einen Prompt schreiben kann – „gib mir kreative Tech-Namen“. Das wäre schnell gebaut, aber würde das Problem nicht lösen.
Der zweite Weg war aufwendiger, aber konzeptionell sauberer: Vor der KI-Generierung zwingt das System den Nutzende, sich selbst klar zu werden. Was genau wird benannt? Welche Werte soll der Name transportieren? Wie abstrakt darf es sein?
Ich entschied mich für den zweiten Weg – nicht weil es weniger Arbeit ist (das Gegenteil ist der Fall), sondern weil er das eigentliche Problem adressiert: schlechtes Briefing führt zu schlechten Namen, nicht mangelnde KI-Qualität.
Die Parameter wurden damit zur Struktur:
Produktbeschreibung: Was ist das Produkt wirklich? Bei „Heizungsservice für Ältere“ ist das anders als bei „Tech-Startup für Gebäudeautomation“ – obwohl beide mit Heizung zu tun haben.
Kreativitätslevel: Slider von „Kunstname“ (Zalando, Spotify – komplett abstrakt) bis „beschreibend“ (heizung24.de – funktional). Das gibt dem System vor, wie weit es abstrahieren soll.
Namenslänge: Ein Wort? Wortkombination? Diese Entscheidung hat massive Auswirkungen auf Merkbarkeit und spätere Domain-Verfügbarkeit.
Das Gegenstück zu dieser Struktur war: Keine freie Texteingabe. Kein „gib mir mal was Cooles“. Nur klare, parametrische Vorgaben.
Technische Umsetzung: Struktur trifft Iteration
Der Kern ist ein ausgeklügelter System-Prompt für die Claude API. Dieser Prompt ist nicht einfach eine Eingabe – er ist selbst das Produkt von 20+ Iterationen. Er enthält explizite Regeln für Namensgenerierung: phonetische Eigenschaften, kulturelle Kontexte, Suchmaschinen-Optimierung im Hinterkopf.
Das Interface ist absichtlich simpel. Nicht weil es leicht zu bauen war, sondern weil Komplexität nirgends hin sollte außer in die intelligente Parameter-Verarbeitung dahinter.
Der Workflow in der Praxis:
Nach der Generierung einer Namen-Liste kommt der entscheidende Moment: das Favoriten-System. Der Nutzende markiert Namen, die in die richtige Richtung gehen. Startet er eine neue Iteration, erhält die KI nicht nur die ursprünglichen Parameter zurück, sondern auch die Information „das waren die bisherigen Favoriten“.
Das System lernt Pattern. Es merkt sich: „Okay, wir bevorzugen konkrete Anker-Wörter“ oder „keine Kunstwörter unter drei Silben“. Die nächste Iteration wird präziser. Und die nächste noch mehr.
So entsteht ein fokussierter Arbeitsbereich, statt jedes Mal in der Breite zu generieren. Das ist der entscheidende Unterschied zu einzelnen KI-Anfragen.
Domain-Intelligenz als zweiter Layer:
Ein Name ist nur so gut wie seine Verfügbarkeit. Also wurde ein Domain-Check direkt in den Workflow integriert – nicht als Nachgedanke, sondern als gleichwertiger Prüfschritt neben der Kreativität.
Der Trick dabei: Das System erkennt den Kontext. Endet ein Name zufällig auf „-io“, wird auch die „.io“-Domain geprüft. Ist der Produktname regional bezogen, könnten „.berlin“ oder „.hamburg“ sinnvoller sein als „.com“. Diese Logik ist hard-coded – nicht weil KI-Prompts das nicht könnten, sondern weil dedizierter Code zuverlässiger ist.
So sieht ein Nutzender auf einen Blick: Welche Namen sind nicht nur kreativ stark, sondern auch praktisch verfügbar?
Kosten- und Nutzungs-Tracking:
Bei internen Tools ist einer der unterschätzten Aspekte: Transparenz über Kosten. Das System trackt Token-Verbrauch und Generierungen pro Person, pro Team, pro Monat. Das dient nicht der Kontrolle, sondern der Orientierung: Rentiert sich dieses Tool? Welche Teams nutzen es? Wo skaliert es?
Diese Daten sind für die Weiterentwicklung essentiell. Sie zeigen, ob die Parameter-Struktur tatsächlich Zeit spart oder ob Teams trotzdem zu viele Iterationen brauchen.
Was nicht funktioniert hat (und was ich gelernt habe)
Fehler 1: Zu viele Parameter am Start
Mein ursprünglicher Prompt für die Namensgenerierung war überambitioniert. Ich wollte, dass die KI gleichzeitig auf Phonetik, kulturelle Sensibilität und Markenverfügbarkeit achtet. Das Ergebnis: generische Namen, weil der Prompt zu viel zu gleichzeitig verarbeiten musste.
Die Lösung war, den Prompt zu reduzieren und einzelne Anforderungen in separate Layer zu verschieben – Domain-Check ist Automatisierung, nicht KI-Prompt. Das hat Qualität und Geschwindigkeit sofort verbessert.
Fehler 2: UX-Komplexität nach oben gedacht statt nach unten
Ich dachte: „Wenn ich alle Parameter visuell elegant gestalte, nutzen auch Nicht-Tech-Personen das Tool.“ Das ist naive gewesen. Was tatsächlich funktionierte, waren mehrere Dinge:
Sinnvolle Defaults (Namenslänge=mittel war für 80% der Cases richtig). Kontextuelle Hinweise direkt im Interface („Warum fragst du das?“). Und ein Tutorial, das nicht peinlich wirkt, sondern die erste Nutzung zeigt.
Fehler 3: Zu viel Automatisierung
Mein Plan war: Alles automatisieren, auch die Markenschecks. Die Realität: Markenrecherche ist rechtlich komplex. Die Integration der DPMA-API ist sinnvoll, aber sie ersetzt keine menschliche Prüfung – sie bereitet sie vor. Diese Unterscheidung habe ich zu spät verstanden.
Das Tool sollte Recherchezeit sparen, nicht rechtliche Prüfung ersetzen.
Was das Projekt zeigt
Es ist leicht, „ein Naming-Tool mit KI“ zu beschreiben. Es ist deutlich schwerer, eines zu bauen, das schneller ist als Brainstorming und bessere Ergebnisse liefert.
Der Schlüssel war nicht die KI-Integration. Der Schlüssel war: Kreative Prozesse brauchen Struktur, um skalierbar zu werden. Parameter erzwingen klares Denken. Iteratives Feedback macht Vagueness unmöglich. Automatisierte Recherche spart die echte Arbeitszeit.
Wenn ich das Projekt heute neu starten würde, würde ich nicht anders vorgehen – das Konzept funktioniert – aber ich würde drei Dinge von Anfang an einplanen:
Markenrecherche als Feature, nicht als Gimmick. Die DPMA-Integration sollte Teil des MVPs sein, nicht eine „nice-to-have“ für später.Bessere Fehlertoleranz in Prompts. Der Claude-Prompt brauchte zwei Überarbeitungen, bis er konsistent gute Namen generierte. Das hätte durch frühere QA vermieden werden können.
Das Tool ist heute in Nutzung, spart geschätzten 20-30 Stunden pro Monat bei der Naming-Recherche ein und hat sich innerhalb von drei Monaten selbst finanziert. Aber der echte Wert liegt nicht in der KI-Integration – er liegt darin, dass Menschen jetzt strukturiert kreativ sein können statt unstrukturiert zu brainstormen.