Beim Zerlegen verschiedener Produkte habe ich langsam eine Gewohnheit entwickelt. Bevor ich bewerte, ob eine Benutzeroberfläche gut aussieht oder ob es genügend Funktionen gibt, zeichne ich zuerst, wie das Produkt den Nutzer dazu bringen soll, es zu bedienen.

In der Regel stelle ich drei Fragen: Was ist die wichtigste Aktion, die Nutzer in diesem Produkt ausführen? Wenn Nutzer mehr Auswahlmöglichkeiten benötigen, was tun sie dann? Können diese Bedienregeln alle Funktionen im Produkt abdecken?

Als Nächstes suche ich gezielt nach den Stellen, an denen die Regeln anfangen, nicht mehr zu funktionieren.

Raycast ist ein sehr leicht verständliches Beispiel. Mit Enter wird die Hauptaktion ausgeführt, mit Cmd+K werden weitere Optionen angezeigt – diese beiden Tasten decken nahezu alles ab: eine App starten, nach Dateien suchen, Fenster verwalten und außerdem mehr als 2500 Drittanbieter-Erweiterungen.

Das gesamte System ist sehr einheitlich – bis KI ins Spiel kommt.

KI lässt sich nur schwer auf „Enter drücken und ein Ergebnis erhalten“ reduzieren. Nutzer müssen normalerweise weiter nachfragen, Anforderungen anpassen, Dateien hinzufügen und außerdem den bisherigen Kontext beibehalten. Deshalb hat Raycast der KI letztlich eine zweite Benutzeroberfläche und eine zusätzliche Bedienweise hinzugefügt.

Das ist ein wichtiges Signal.

**Wenn die ursprünglichen Bedienregeln eines Produkts zu versagen beginnen, sind wir in der Regel bereits nahe an der Obergrenze dessen, was seine aktuelle Struktur verkraften kann.**

Das bedeutet nicht zwingend, dass ein Designfehler vorliegt; vielmehr zeigen sich einfach endlich die Grenzen der ursprünglichen Struktur.

Diese Methode verursacht fast keine Kosten und lässt sich direkt auf das eigene Produkt anwenden. Notiere zuerst die wichtigste Aktion der Nutzer, dann, wie Nutzer an mehr Optionen gelangen, und suche anschließend nach der Funktion, die sich dieser Regel immer wieder entzieht.

Diese Funktion weist normalerweise auf den Rand der Produktstruktur hin.