Auf dieser Seite
Ein Supportsystem empfiehlt, eine Bestellung zu erstatten. Auf dem Bildschirm steht „hohe Konfidenz“, aber die Bedienperson kann weder sehen, um welche Bestellung es geht, welche Richtlinienversion gilt noch ob bereits eine Ersatzlieferung unterwegs ist. Die Empfehlung kann richtig sein. Die Bedienperson kann es nicht wissen. Das ist ein beispielhaftes Support-Szenario und kein berichteter Vorfall.
Eine Demonstration zur Entscheidungsunterstützung zeigt ein besser prüfbares Muster: Prüfende sehen einzelne Messwerte und können die zugrunde liegende Untersuchung öffnen, statt nur einen abschließenden Vorschlag zu erhalten. Die Demonstration findet im medizinischen Bereich statt, in dem eine unabhängige Validierung besonders wichtig ist. Sie belegt keine klinische Genauigkeit. Die Gestaltungslehre lässt sich auf weniger sensible Aufgaben übertragen, ohne die Ergebnisversprechen des Anbieters zu übernehmen.
Eine Empfehlung verdichtet die Belege
Verdichtung ist hilfreich. Wer wissen möchte, ob eine Bestellung erstattet werden sollte, möchte nicht jedes Ereignis im Journal lesen. Eine Empfehlung kann aus einem langen Vorgang die nächste Aktion ableiten. Dabei gehen aber auch Einzelheiten verloren, die das Ergebnis widerlegen könnten.
Betrachte einen beispielhaften Bestellverlauf. Eine Kundin meldet ein fehlendes Paket. Das Modell sieht im Feed des Versanddienstes „nicht zugestellt“ und schlägt eine Erstattung vor. Ein anderer Datensatz besagt, dass heute Morgen ein Ersatz versandt wurde. Verbirgt die Empfehlung diesen Datensatz, erhält die Kundin vielleicht zwei Lösungen für ein Problem. Zeigt sie beide Fakten mit ihren Zeitpunkten, kann die Bedienperson fundiert entscheiden.
Die Oberfläche sollte vor einer Aktion vier Fragen beantworten: Was wurde beobachtet? Woher stammt es? Wie aktuell ist es? Was könnte die Empfehlung falsch machen? Eine textliche Begründung ist nur ein Teil der Antwort.
Quellbeobachtungen und prüfende Person werden durch eine Empfehlung mit Herkunft und Unsicherheit verbunden. So lässt sich der Originaldatensatz untersuchen.
„Erstatten, weil die Zustellung fehlgeschlagen ist“ klingt flüssig, auch wenn der Status des Versanddienstes veraltet ist.
| Sichtbares Element | Was die prüfende Person damit testen kann |
|---|---|
| Empfehlung und vorgeschlagene Aktion | Ob die Aktion zur Aufgabe passt |
| Beobachtungen aus Quellen mit Zeitstempeln | Ob die Fakten aktuell und vollständig sind |
| Fehlende oder widersprüchliche Belege | Ob pausiert oder nachgeforscht werden sollte |
| Link zum Originaldatensatz | Ob die Zusammenfassung ein entscheidendes Detail ausgelassen hat |
| Ergebnis und Korrekturverlauf | Ob ähnliche Vorschläge wiederholt scheitern |
Das ist eine konzeptionelle Checkliste für Oberflächen und keine Behauptung, ein bestimmtes Dashboard verbessere Entscheidungen.
Mach Unsicherheit zum Teil der Arbeit, nicht zum Kleingedruckten
Ein System kann aus verschiedenen Gründen unsicher sein. Eine Quelle hat nicht geantwortet. Zwei Kennungen könnten dieselbe Bestellung bezeichnen. Eine Richtlinie hat sich seit der letzten Indexierung geändert. Vielleicht weiß das Modell selbst nicht, wie es eine Beschwerde in Freitext einordnen soll. Das sind unterschiedliche Fehlerarten und sollten unterschiedlich dargestellt werden.
„Niedrige Konfidenz“ reicht nicht aus, wenn die Bedienperson einen konkreten fehlenden Fakt klären kann. Zeig „Versanddaten zuletzt gestern aktualisiert“ oder „Ersatzdatensatz konnte nicht abgerufen werden“. Gibt es keine Grundlage für einen Wert, blende keine genaue Prozentzahl ein. Die prüfende Person soll entscheiden können, was als Nächstes zu verifizieren ist.
Dieselbe Struktur ist bei einem Datensync wichtig. Erhält ein Zielsystem einen neuen Kundenstatus, speichere die Quellereignis-ID, den Zeitpunkt und die Regel, die die Änderung verursacht hat. Fragt später jemand, warum eine Kampagne eine Kundin eingeschlossen hat, kann das Team der Entscheidung rückwärts folgen. Ein nicht erklärter kopierter Wert ist eine Empfehlung ohne Belege.
Diese vorgeschlagene Tajo-Ansicht trennt den Bericht des Aktivitätsverlaufs von dem, was unbelegt bleibt. Der Schreibvorgang gilt als angewendet, die Zielprüfung steht noch aus. Tajos bestehender Aktivitätsverlauf zeigt Ergebnisse und Rohereignisse. Das zusätzliche Prüffeld illustriert, wie diese Grenze deutlicher werden könnte.
Ein abgeschlossener Schreibvorgang braucht weiterhin Belege
Wurde die Kundensynchronisierung abgeschlossen?
Schreibvorgang angewendet. Prüfung ausstehend.
Der Zielzustand wurde noch nicht geprüft.
Sync-Aktivität
- Anfrage angenommen
- Aktualisierung angewendet
- Zielprüfung ausstehend
Beispielhafter Durchlauf · 14:32 UTC
Was wir wissen
- Antwort des Anbieters
- Angenommen
- Ergebnis des Schreibvorgangs
- Angewendet
- Rücklesung aus dem Zielsystem
- Ausstehend
Ein erfolgreicher Aufruf belegt den Endzustand nicht.
Vorgeschlagenes Layout auf Grundlage von Tajos Aktivitätsverlauf. Die Illustration ergänzt einen Prüfstatus und behauptet nicht, dass die Rücklesung aus dem Zielsystem bereits implementiert ist.
Mach Prüfungen nützlich, ohne alles offenzulegen
Die meisten Routineaktionen sollten nicht erfordern, dass jemand eine Fallakte öffnet. Eine gute Oberfläche hält die Empfehlung knapp und stellt die Belege einen Schritt entfernt bereit. Sie kann außerdem nur Abweichungen zeigen, die die Entscheidung verändern könnten. Das ist etwas anderes, als die Grundlage ganz zu verbergen.
Mehr sichtbare Daten bringen ein echtes Datenschutzrisiko mit sich. Eine prüfende Person sollte nur die für diese Entscheidung nötigen Felder sehen, unter denselben Zugriffsregeln wie beim Quelldatensatz. Sichtbarkeit von Belegen ist keine pauschale Erlaubnis, eine Kund:innenhistorie offenzulegen. Auch für Aufbewahrung und Audit-Protokolle braucht es eine zuständige Stelle.
Ein zweites Risiko ist Automatisierungsbias: Eine sichtbare Empfehlung kann die prüfende Person weiterhin lenken. Prüfe, ob sie absichtlich eingebaute Widersprüche erkennt und ob sie ohne Hindernisse „Belege unzureichend“ auswählen kann. Miss nach der Einführung Korrektur- und Rücknahmemuster. Eine gefällige Erklärung ist kein Maß für den Erfolg.
Eine Prüfoberfläche braucht auch einen Ort, um Widerspruch zu erfassen. Lehnt die zuständige Person den Erstattungsvorschlag ab, frage nach einem gezielten Grund, der das System verbessern kann: falsche Bestellzuordnung, veralteter Versandstatus, fehlender Ersatzdatensatz oder Ausnahme von der Richtlinie. Verlange nicht zu jeder Abweichung einen langen Text. Fasse die Gründe zusammen und prüfe, ob eine Quelle wiederholt Probleme verursacht. So führt eine einzelne Prüfung zur Reparatur des Systems. Der Leitfaden zur Workflow-Erhebung hilft, den tatsächlichen Ausnahmeweg zu finden, bevor ein Vorschlag gebaut wird. Belege neben der Empfehlung helfen der prüfenden Person heute. Korrekturdaten können den Entscheidungsweg von morgen verbessern.
Bei folgenreichen Aktionen sollte der Prüfweg Teil des Produktvertrags sein. Das System macht einen Vorschlag, nennt seine Belege, legt ungeprüfte Punkte offen und hält das Ergebnis fest. Tragen die Belege keine Entscheidung, lautet die hilfreichste Empfehlung vielleicht: „Warten.“
Häufig gestellte Fragen
Macht eine Erklärung eine Empfehlung zuverlässig?
Nein. Auch ein plausibler Erklärtext kann ein falsches Ergebnis begleiten. Prüfende brauchen Zugriff auf Beobachtungen aus der Quelle, Herkunft, Unsicherheit und Ergebnisse, nicht nur einen selbstsicher formulierten Satz.
Welche Belege gehören neben einen automatisierten Vorschlag?
Zeig die konkret verwendeten Beobachtungen, ihre Quelle und ihren Zeitpunkt, fehlende Eingaben, soweit relevant die Regel- oder Modellversion und eine Möglichkeit, den Originaldatensatz einzusehen.
Wann sollte eine Person das Ergebnis prüfen?
Wenn die Folgen den autorisierten Umfang des Systems überschreiten oder Belege unvollständig, veraltet oder umstritten sind. Prüfende müssen sinnvoll widersprechen und die Aktion anhalten können.