Was haben ein Hammer und ein LLM (nicht) gemeinsam?

Sicher habt ihr alle schon mal einen Hammer benutzt, oder? Ein einfaches, altes Werkzeug. Seine Zwecke sind begrenzt: Nägel in die Wand bekommen, im Notfall eine Scheibe einschlagen oder meinen Daumen zerstören. In allen drei Fällen nutzt man ihn auf dieselbe Art – und das Feedback ist in der Regel unmittelbar visuell erfassbar (oder spürbar).

Mit der Verbreitung von Computersystemen in den 80ern zog auch das Bewusstsein ein, dass man nun ein neues Werkzeug hatte, das den bisherigen ungleich war. Eine Maschine für dutzende Zwecke anstatt nur für einen – und mit deutlich komplexerem Feedback. Dies brachte eine neue wissenschaftliche Disziplin hervor: Human-Computer Interaction, kurz HCI.

Die Kernbotschaft von HCI

HCI ist ein interdisziplinäres Forschungsfeld. Es verbindet unter anderem Verhaltenswissenschaften mit der Informatik und versucht, die Besonderheiten der Arbeit an und mit Computersystemen herauszuarbeiten. Schon in den ersten Werken, die dieses Feld begründeten, wurde die Arbeit mit einem Computer eher wie die Kommunikation mit einem Menschen verglichen als wie die Nutzung eines Werkzeugs.

Man muss bewusst eine Aktion wählen, Daten eingeben und erhält hoffentlich ein Feedback – eine Reaktion, die bei mir als Nutzer wiederum eine neue Handlung auslöst.

Entsprechend muss ein Nutzer die Möglichkeit haben, klar zu formulieren, was der Computer tun soll – zum Beispiel eine Datei löschen. Und so hat sich das Markieren einer Datei und das Betätigen des Papierkorbsymbols für diese Aktion durchgesetzt. Eine semantisch äquivalente, aber rudimentärere Kommunikationsform ist die textbasierte Variante mittels Konsole:

rm langweiliger-blogbeitrag.doc

Überraschung: Im Mainstream hat sich Ersteres durchgesetzt. Wir holen ja unser Geld am Geldautomaten auch nicht ab, indem wir

./give-me-all-money.sh –iban DE…

in eine Konsole tippen, sondern werden durch ein intuitives Menü geführt.

In Entwicklerkreisen sieht das nicht immer so aus, doch auch hier haben sich spezialisierte Werkzeuge etabliert – etwa IDEs. Jede Disziplin hat ihre eigene Software, vom ETL-Datenschubser bis zum Game Designer. So entstanden über die Jahre viele Paradigmen, Best Practices und Tools, um gute User Interfaces zu bauen. Schließlich entstand daraus sogar das Berufsbild des UX-Designers.

Gängige Anforderungen an ein gutes Interface

• Usability First – Interfaces sollen leicht erlernbar, effizient und fehlerarm sein (Nielsen’s Usability Heuristics, 1990er).
• Affordances & Signifiers – Nutzer erkennen an der Gestaltung, wie man ein Interface bedienen kann (Norman, The Design of Everyday Things).
• Consistency & Standards – vertraute Muster (z. B. „Save“-Icon) erleichtern Interaktion.
• Feedback & Visibility – Systeme sollen jederzeit zeigen, was gerade passiert (z. B. Ladebalken, Statusmeldungen).
• Minimierung der kognitiven Last – Systeme sollen Informationen so präsentieren, dass sie leicht verarbeitet werden können.
• User-Centered Design – Entwicklung orientiert sich an den Bedürfnissen, Fähigkeiten und Kontexten der Nutzer:innen.

Und doch … alles, was wir hier tun, sind Krücken. Grafiken visualisieren Datenflüsse oder Prozesse, Buttons visualisieren Aktionen. Mit Baukästen versuchen wir, Low-Code- oder No-Code-Ansätze zu erreichen. Animationen, Warnungen oder auch Geräusche sollen uns Feedback geben.

Barrierefreiheit

Ein kurzer Abschweif ins Thema Barrierefreiheit, weil er mir wichtig ist. Einfach ist das Thema nicht – im Gegenteil, es ist komplex und schwer. Wo Standards Wiedererkennungswerte schaffen und viele Funktionen auf einem Screen untergebracht werden müssen, müssen auch Anforderungen an Barrierefreiheit berücksichtigt werden. Menschen sollen Zugänge haben, ob sie sehschwach, motorisch eingeschränkt oder anderweitig beeinträchtigt sind.

Ein User Interface funktioniert in der Regel am besten, wenn es nicht versucht, alle Bedarfe abzudecken, sondern auf eine Persona zugeschnitten ist. Bei Barrierefreiheit müssen jedoch viele individuelle Charakteristika gleichzeitig bedient werden. Ein Widerspruch, der sich nicht leicht auflösen lässt. Zum Glück gibt es mittlerweile gute Gesetze, die Lösungen trotz dieser Herausforderung einfordern.

Und dann kam das LLM

Und nun, nach 45 Jahren Forschung und Fortschritt in HCI (lassen wir die Zeit, in der Computer noch keine Bildschirme hatten, mal außen vor) kommen die Large Language Models. Ein simples Chatfenster oder ein Mikrofon reicht.

• „Lösche bitte meinen langweiligen Blogbeitrag!“ – zack, weg.
• „Schreib einen neuen!“ – zack, Influencer.
• „Durchsuche meine Mails!“, „Schicke eine Nachricht!“, „Recherchiere Folgendes!“, „Programmiere mir ein Skript!“ – alles über dasselbe Interface.

Wo man früher zehn verschiedene Interfaces brauchte, gibt es jetzt nur noch eins. Die „Zeichensprache“, die jahrelang unsere Kommunikation mit dem Computer geprägt hat, wird nun zur echten, natürlichen Sprache – zu Natural User Interfaces (NUI).

LLMs als neue Gesprächspartner

Ja, persönliche Assistenten wie Siri oder Alexa können das schon ein paar Jahre. Aber deren Feedback war immer stark eingeschränkt. Ein LLM dagegen agiert mit mir, als wäre ich – oder besser gesagt: als wäre es – ein Mensch. Damit kommen wir der alten Analogie aus den 80ern („HCI ist näher an Mensch-zu-Mensch-Kommunikation als an einer Werkzeugbenutzung“) nun sehr nahe.

Ein LLM als Frontend für ein IT-System kann vieles einfacher machen:

• Usability: Die Einstiegshürde sinkt radikal, weil natürliche Sprache jeder versteht.
• Effizienz: Statt zehn Klicks reicht eine Anweisung.
• Barrierefreiheit: Auch Menschen mit Einschränkungen oder geringen IT-Kenntnissen können komplexe Systeme bedienen.
• Flexibilität: Dasselbe Interface kann für unzählige Aufgaben genutzt werden – vom ETL-Skript bis zum Marketingtext.

Chancen und Risiken

Das bringt viele Vorteile mit sich, die wir alle seit ein bis zwei Jahren spüren. Aber: Kommunikation „wie mit einem Menschen“ bedeutet auch Missverständnisse „wie mit einem Menschen“.

„Lösche bitte meinen langweiligen Blogbeitrag“ ist sehr viel undeutlicher als

rm langweiliger-blogbeitrag.doc

– und definitiv Interpretationssache.

Das Verhalten der Maschine kann plötzlich nicht-deterministisch sein und bei gleichen Anfragen Unterschiedliches tun.

Hybride Ansätze im Entwickleralltag

Dennoch: Gerade aus Sicht eines Analytics-Entwicklers blicke ich positiv auf diese Entwicklung. Von Lochkarten zu Assembler, zu gängigen Programmiersprachen, zu grafischen Low-Code-Baukästen – und nun zu einem reinen Beschreiben von Anforderungen.

Hybride Ansätze halten Einzug in unseren Alltag:

• Tools wie GitHub Copilot oder DBT verbinden Spracheingabe mit Code-Generierung.
• Erste Plattformen wandeln Prompts in Flowcharts oder Visualisierungen um.
• Hybride Interfaces erlauben es, zwischen Code, Grafik und Sprache zu wechseln – ohne Medienbruch.

Fazit – und zurück zum Hammer

Mitte November wird es weitere, konkretere (versprochen!) Beiträge zu diesem Thema geben. Wie können grafische ETL-Workflows durch KI-basierte Ansätze abgelöst werden? Warum wird der Code dadurch effizienter? Und wo sind (noch) die Limits?

Und was hat die KI nun mit dem Hammer gemein?

Beide sind Teil der HCI-Forschung – und mit beiden muss man umgehen können. Ansonsten nicht viel. Verzeiht mir also den Clickbait. Ob KI eine ähnliche technologische Explosion auslöst wie das erste menschliche Werkzeug? Wir werden sehen.

Literatur

• Card, S.K. (Ed.). (1983). The Psychology of Human-Computer Interaction (1st ed.). CRC Press. https://doi.org/10.1201/9780203736166
• Nielsen, J. (1994a). Enhancing the explanatory power of usability heuristics. Proc. ACM CHI’94 Conf. (Boston, MA, April 24-28), 152-158.
• Norman, D. A. (2013). The Design of Everyday Things. MIT Press.