ux-design-for-architects
Leitfaden für Architekten zum Entwerfen und Überprüfen der UX von nicht-UI-Benutzerschnittstellen (API / Konfiguration / Erweiterungen) für KI-Agenten. Das Design von UI-Oberflächen (Farben, Layout usw.) ist nicht Gegenstand.
UX betrifft nicht nur die UI, sondern sämtliche Berührungspunkte zwischen System und Benutzer. Eine schlechte UX an diesen Punkten ist später nur schwer zu ändern (da Benutzer davon abhängen) und senkt die Erfolgswahrscheinlichkeit des Gesamtsystems. Daher wird sie vor der Implementierung festgelegt.
Vorgehen
- Schnittstellen identifizieren: API, Konfiguration oder Erweiterungen (auch mehrere).
- Benutzer identifizieren (Prinzip 1): Wer nutzt es, wofür und auf welchem technischen Niveau.
- Entsprechende Detailanleitung lesen:
- Konfiguration →
references/configuration.md - API →
references/api.md - Erweiterungen →
references/extensions.md
- Konfiguration →
- Mit den 6 Prinzipien prüfen (siehe unten). Bei einem Designvorschlag kurz die Begründung anhand der Prinzipien anfügen.
- Bei einem Review die Kritik im Format von
references/review-checklist.mdverfassen. - Bei Meinungsverschiedenheiten den Benutzer mit einer Hypothese befragen (AskUserQuestion).
Die 6 UX-Prinzipien
| # | Prinzip | Kernpunkt | Warum |
|---|---|---|---|
| 1 | Benutzer verstehen | Ziele, technisches Niveau, mentales Modell und typische Arbeitsabläufe erfassen, damit das System den Erwartungen entspricht (Prinzip der geringsten Überraschung) | Benutzer handeln anders als erwartet. Beobachten und Messen ist besser als Fragen |
| 2 | Nur das Nötigste tun | Nur die wirklich benötigten Funktionen anbieten. Weit verbreitete Standards (OAuth, OpenID usw.) übernehmen | Bereitgestelltes wird zur Verbindlichkeit. Einmal eingeführt, sind Benutzer daran gewöhnt und Änderungen sind schwierig |
| 3 | Kein Handbuch nötig | Die Bedienung selbsterklärend machen, durch Empfehlungen und Hinweise führen | Benutzer lesen keine Handbücher. Wenn sie ein Problem nicht lösen können, geben sie dem Produkt die Schuld |
| 4 | Als Informationsaustausch denken | Nicht fragen > wenig fragen > in leicht beantwortbarer Form fragen. Dasselbe nicht zweimal fragen | Eingabe ist eine Belastung. Sie kann durch Schätzen, Erinnern oder Ableiten reduziert werden |
| 5 | Einfaches einfach halten | Barrieren bei den ersten Schritten beseitigen. Vorkonfigurierte Clients oder Beispiele bereitstellen | Anfänger steigen schneller aus. Das erste Erlebnis entscheidet über die Bindung |
| 6 | UX vor der Implementierung designen | UX vor der Architektur festlegen und iterativ Feedback einholen | UX-Änderungen nach der Implementierung sind teuer. Implementierung verzögern, Design vertiefen |
Entscheidungsfindung beim Abfragen von Informationen (Konkretisierung von Prinzip 4)
Priorisiert denken:
- Nicht fragen: Angemessene Standardwerte, automatische Erkennung aus der Umgebung, Speichern früherer Eingaben, Ableiten aus bekannten Informationen
- Wenig fragen: Nur das wirklich Notwendige
- Leicht beantwortbar fragen: Nicht in der Sprache der internen Implementierung, sondern so, dass der Benutzer nicht im Kopf rechnen muss (z.B. statt „maximale Cache-Eintragsanzahl" lieber „Obergrenze des Cache-Speichers", und noch besser: aus der Modusauswahl wie „Server oder Client" die Details ableiten)
Rückgabe von Ausgaben/Antworten (Prinzip 4)
Wenn die Leistung es zulässt, möglichst viele Informationen in einer für den Benutzer verständlichen Form zurückgeben, damit er die nächsten Schritte vorhersagen kann. Wenn das Ergebnis eines Aufrufs an den nächsten Aufruf übergeben wird, so aufbereiten, dass die Verarbeitung minimal ist.
Zusammenfassung pro Schnittstelle
- Konfiguration: Am besten ist es, keine Konfiguration einzuführen. Als nächstes automatische Entscheidung, zuletzt mit angemessenen Standardwerten einführen. Die Frage lautet: „Hat der Benutzer einen besseren Kontext als wir?" – Nur bei „Ja" als Konfiguration anbieten. Unbekannte Schlüssel oder fehlgeschlagene Anwendungen nicht stillschweigend ignorieren, sondern Fehler melden. Gültige Konfigurationswerte sollten z.B. beim Start überprüfbar sein.
- API: Die Nutzer sind Entwickler. Leicht zu lernen, schwer falsch zu verwenden, der nächste Schritt ist immer klar. Eine Sache gut machen. Keinen Boilerplate-Code erzwingen. Standards folgen. Von Anfang an versionieren. Die Veröffentlichung hinauszögern, bis sie nötig ist – zuerst intern verwenden.
- Erweiterungen: Mit dem Hinzufügen warten, bis der Anwendungsfall tief verstanden ist (später durch Refactoring nachrüstbar). Eine Sache gut machen. Ein- und Ausgaben definieren, interne Strukturen nicht offenlegen. Einmal veröffentlicht, sind Änderungen schwierig.
Häufige Fehler (bei Design/Review vermuten)
- Mangelnde UX-Fachkenntnisse / zu späte Einbeziehung von Experten
- Nur auf die UI achten und die UX von API, Konfiguration und Erweiterungen vernachlässigen
- Der technische Leiter entscheidet über die UX und überlässt dem Experten nur die Feinanpassung der UI
- Vorschläge von Experten ignorieren
- Bei zwei Optionen in der Konfiguration ausweichen (das Problem auf den Benutzer abwälzen)
Wenn kein Experte verfügbar ist, dies explizit angeben und empfehlen, frühzeitig einen UX-Experten hinzuzuziehen. Den Entwurf jedoch nicht aufgrund von Beratungsverweigerung stoppen, sondern einen provisorischen Vorschlag gemäß diesem Leitfaden erstellen.
Verbindung zum iterativen Vorgehen
- Design aus der User Journey ableiten → Leitfaden auf die einzelnen Berührungspunkte der Journey anwenden
- Iterativ schneiden → Im ersten Schnitt nur die benötigten Schnittstellen erstellen (öffentliche APIs oder Erweiterungen sind oft erst nach dem MVP sinnvoll)
- Schwer änderbare Dinge tief entwerfen und langsam implementieren → UX ist ein Paradebeispiel. Aus der Beobachtung der tatsächlichen Nutzung lernen
Ausgabeformat
Designvorschlag: Kurze Darstellung in der Reihenfolge „Zielschnittstelle → Benutzerprofil → Vorschlag → Zutreffendes Prinzip und Begründung → Offene Punkte".
Review: Im Format von references/review-checklist.md.