Die Frage vor dem Prompt
Ein Auftrag wie „Mach diese Erinnerungsseite intelligenter“ kann überzeugend aussehen, ohne das Produktproblem zu klären. Das Ergebnis hat vielleicht ein ordentliches Layout und angenehme Texte. Trotzdem bleibt unklar, was eine Person tun möchte und welche Informationen das System tatsächlich kennt.
Der erste hilfreiche Schritt ist keine aufwendigere Stilanweisung, sondern eine kleinere, präzisere Aufgabe. Welche Entscheidung unterstützt die Oberfläche? Was ist bekannt? Was muss bearbeitbar bleiben? Diese Fragen machen eine Antwort prüfbar, unabhängig davon, ob sie von einem Menschen, einem KI-Werkzeug oder beiden stammt.
Eine fiktive Erinnerungsaufgabe
Der Ausgangsauftrag
Gestalte eine Einstellungsseite für eine Terminerinnerung. Mach sie einfach und nutze KI zur Personalisierung.
Der Auftrag vermischt eine Aufgabe mit einer ungeprüften Lösung. „Personalisieren“ könnte eine Uhrzeit empfehlen, einen Kanal wählen oder den Termin selbst ändern. Das sind verschiedene Produkte mit unterschiedlichen Folgen. Ein Briefing sollte diese Grenze klären, bevor es eine Oberfläche verlangt.
Das Briefing prüfbar machen
Ich würde den Auftrag in fünf explizite Teile zerlegen. Das ist ein vorgeschlagener Designansatz, kein Bericht über einen durchgeführten Kundenprozess.
Ein strukturiertes Briefing
Eine Person kann eine Erinnerung für einen bestehenden Termin einrichten, prüfen und ändern.
Das Termindatum und der gewählte Kontaktkanal. Ort, Präferenzen oder Berechtigungsstatus dürfen nicht erfunden werden.
Die Oberfläche verschiebt den Termin nicht. Vorschläge bleiben optional. Eine Einstellung wird vor dem Speichern bestätigt.
Leer, eingerichtet, Bearbeitung, nicht verfügbare Benachrichtigungen und fehlgeschlagenes Speichern mit erhaltenen Eingaben.
Die aktuelle Uhrzeit ist lesbar. Bearbeitung ist erreichbar. Eingaben sind beschriftet. Ein Fehler erklärt den nächsten Schritt. Tastaturzugang und schmale Ansichten sind berücksichtigt.
Diese Struktur macht das Design nicht automatisch richtig. Sie macht Auslassungen sichtbar. Eine prüfende Person kann auf einen fehlenden Bearbeitungszustand oder eine erfundene Berechtigungsannahme zeigen, ohne darüber zu streiten, ob die Seite „intelligent“ aussieht.
Die grobe Antwort hinterfragen
Eine Seite zeigt eine empfohlene Uhrzeit, einen Schalter „Intelligente Erinnerung“ und eine Speichern-Schaltfläche. Danach erscheint „Alles bereit!“.
Die Antwort ist plausibel, aber unvollständig. Woher kommt die empfohlene Uhrzeit? Was ändert der Schalter? Lässt sich die gespeicherte Einstellung prüfen? Was passiert ohne Benachrichtigungsberechtigung? „Alles bereit“ könnte eine sichere Zustellung suggerieren, obwohl nur eine Einstellung gespeichert wurde.
Die fehlenden Teile sind keine Dekoration. Sie verändern die Bedeutung des Produkts. Ein vager „intelligenter“ Schalter bündelt Verhalten, das die Person nicht beurteilen kann. Eine allgemeine Erfolgsmeldung verdeckt den Unterschied zwischen dem Speichern einer Absicht und ihrer Ausführung. Auch Barrierefreiheit folgt nicht aus einem sauberen Layout.
Die Interaktion überarbeiten
Mit dem bestehenden Termin und der gewählten Erinnerungszeit beginnen. Die Beschriftung klar halten. Ist ein Vorschlag durch vorhandene Informationen begründet, die relevante Grundlage kurz erklären und einen anderen Wert ermöglichen. Fehlt diese Grundlage, eine neutrale Auswahl statt einer erfundenen Empfehlung zeigen.
Nach dem Speichern die Einstellung in einer lesbaren Zusammenfassung mit Bearbeitungsmöglichkeit zeigen. Konkret formulieren: „Erinnerungszeit gespeichert. Du kannst sie in den Erinnerungseinstellungen ändern.“ Nicht verfügbare Benachrichtigungen getrennt benennen und einen echten manuellen Schritt anbieten. Bei der Rückkehr bleibt die Einrichtung erhalten.
Schlägt das Speichern fehl, den eingegebenen Wert erhalten und den Fehler beim betroffenen Bereich erklären. Ein erneuter Versuch braucht ein erkennbares Ergebnis. Das sind vorgeschlagene Interaktionsanforderungen, keine Behauptung, dass das fiktive Produkt umgesetzt oder getestet wurde.
Eine wiederverwendbare Prüfliste
- Die Aufgabe benennen, ohne eine unbestätigte KI-Lösung einzubauen.
- Bekannte Informationen von Annahmen und fehlenden Daten trennen.
- Standard-, Bearbeitungs-, Fehler- und Rückkehrzustände vor der Gestaltung definieren.
- Vorschläge optional halten und ihre Folgen verständlich machen.
- Texte, Semantik, Fokusreihenfolge und die längste Übersetzung prüfen.
Die Liste hilft, weil jeder Punkt unabhängig scheitern kann. Eine gute Überschrift ersetzt keinen verlorenen Bearbeitungsweg. Eine flüssige Übersetzung belegt nicht die Wahrheit einer Empfehlung.
Was daraus nicht folgt
Ein strukturiertes Briefing schafft eine bessere Gesprächsgrundlage. Es beweist nicht, dass ein KI-Werkzeug Zeit spart oder nutzbare Designs erzeugt. Dafür braucht es einen definierten Vergleich, passende Aufgaben und dokumentierte Belege. Dieses Beispiel belegt keine solchen Ergebnisse.
Reale Nutzung, Produktgrenzen und Plattformverhalten können den Vorschlag weiterhin infrage stellen. In einem echten Projekt müssten diese Bedingungen mit den Menschen geprüft werden, die das Produkt nutzen und umsetzen.
Quellen zum Ansatz
Microsoft HAX bietet Orientierung zu Fähigkeiten, Interaktion und Korrektur. Google PAIR behandelt Vertrauen, Fehler und Kontrolle. Ich nutze sie als Grundlage für Prüffragen, nicht als Erfolgsbeleg des fiktiven Designs.
Sprache und Beispiele warten auf Oksanas Durchsicht. Der Artikel beschreibt Designüberlegungen, keine gemessene Leistung und keine Kundenstudie.
Zurück zum Journal