Eine Prozentangabe neben einer Ausgabe verlagert die Beurteilung auf eine Zahl, deren Zustandekommen niemand am Arbeitsplatz nachvollzieht. In moderierten Sitzungen zu Fachanwendungen mit Vorschlagsfunktion haben wir beobachtet, wie Testpersonen mit solchen Angaben umgehen. Der Beitrag beschreibt die Beobachtung, ordnet sie ein und stellt Alternativen zur Diskussion, die an die Aufgabe der Nutzenden anschließen.
Die Situation
Eine Sachbearbeiterin, ich nenne sie hier Frau Berger, öffnet den nächsten Fall. Die Anwendung schlägt eine Zuordnung zur Sparte vor, daneben steht eine hohe Prozentzahl. Frau Berger liest die Zahl, übernimmt den Vorschlag und geht zum nächsten Fall. Auf die Frage nach der Aufgabe, worauf sie ihre Entscheidung gestützt habe, sagt sie: auf die Zahl, die sei ja hoch. Der Vorschlag war falsch; die Aufgabe enthielt den Fehler absichtlich.
Solche Sitzungen haben wir in mehreren Usability-Tests von Fachanwendungen erlebt. Neben jedem Vorschlag der Funktion stand eine Konfidenzangabe, eine Prozentzahl oder ein Balken, der anzeigen sollte, wie sicher die Funktion sich bei diesem Vorschlag ist. Die Anwendungen kamen aus der Sachbearbeitung und dem Kundenservice; die Vorschläge betrafen die Zuordnung eines Falls, eine Zusammenfassung oder eine Antwort. Die Testpersonen führen die Aufgabe im Alltag aus. Die Testaufgaben enthielten Fälle mit brauchbaren und mit fehlerhaften Vorschlägen, und die Moderation fragte nach jeder Aufgabe, worauf die Person ihre Entscheidung gestützt hatte.
Was sich zeigte
Die Testpersonen lasen die Zahl. Auf die Frage, was sie bedeute, gab niemand eine Antwort, die sich auf den vorliegenden Fall bezog. Die Antworten lauteten sinngemäß: dass das System sich ziemlich sicher sei, dass die Zahl wohl aus dem System komme, dass sie nicht wüssten, worauf sich die Zahl beziehe.
Mein erster Gedanke nach den ersten Sitzungen war, dass die Zahl erklärt werden müsse, etwa mit einem Hinweistext. Die weiteren Sitzungen haben diesen Gedanken nicht bestätigt, weil der Umgang mit der Zahl in zwei Muster fiel, die eine Erklärung beide nicht aufgelöst hätte. Ein Teil der Testpersonen übernahm Vorschläge mit hoher Angabe ohne weitere Prüfung, auch wenn der Vorschlag im Fall einen Fehler enthielt, und begründete das mit der Zahl, wie Frau Berger. Ein anderer Teil ignorierte die Angabe vollständig und prüfte jeden Vorschlag so, wie er den Fall ohne die Funktion geprüft hätte; für diese Personen war die Zahl ohne Wirkung, und die Funktion ersparte ihnen keinen Schritt.
Bei niedriger Angabe trat ein drittes Verhalten auf, mit dem ich nicht gerechnet hatte: Einige Testpersonen suchten den Fehler bei sich, prüften ihre Eingabe erneut oder fragten die Moderation, ob sie etwas falsch gemacht hätten. Die Zahl wurde als Rückmeldung zur eigenen Arbeit gelesen, obwohl sie sich auf den Vorschlag bezog.
Keine Testperson konnte die Zahl mit dem Fall abgleichen. Die Frage „Worauf bezieht sich das?" blieb in allen Sitzungen ohne Antwort in der Oberfläche. Wie viele Personen welchem Muster folgten, nennen wir nicht; die Sitzungen stammen aus verschiedenen Projekten mit verschiedenen Aufgaben und lassen sich nicht zu einer Zahl zusammenfassen.
Einordnung
Eine Konfidenzangabe beschreibt einen Zustand im Inneren der Funktion. Sie sagt nichts darüber, welche Angabe im Fall unsicher ist, warum, und was die Person tun müsste, um das zu klären. Frau Berger kann den Fall prüfen; die Statistik kann sie nicht prüfen, und die Zahl verlangt ihr eine Beurteilung ab, für die sie weder Grundlage noch Zuständigkeit hat. Nach ISO 9241-110 verlangt die Selbstbeschreibungsfähigkeit, dass ein System seinen Zustand in einer Form erkennbar macht, die zur Aufgabe passt. Eine Zahl ohne Bezug zum Fall erfüllt diese Anforderung für die Aufgabe der Sachbearbeitung nicht, auch wenn sie für die Modellentwicklung eine sinnvolle Größe ist.
Die Gegenposition, die ich aus Entwicklungsteams kenne, lautet: Die Zahl ist die einzige Information, die das Modell über seine eigene Unsicherheit hat, und jede andere Darstellung wäre eine Interpretation, die das Team verantworten müsste. Ich halte den Einwand für richtig in dem, was er über das Modell sagt, und für unvollständig in dem, was er über die Aufgabe sagt. Die Interpretation findet ohnehin statt, in unseren Sitzungen bei jeder Testperson einzeln und jedes Mal anders. Offen ist, ob das Team diese Interpretation gestaltet oder sie den Nutzenden überlässt.
Die Beobachtung sagt, dass Konfidenzangaben in dieser Form in unseren Sitzungen keine Prüfung ausgelöst haben. Sie sagt nicht, welche Darstellung von Unsicherheit eine Prüfung auslöst. Dazu fehlt ein Test mit mehreren Darstellungsvarianten an derselben Anwendung, und die Alternativen unten sind bis dahin Hypothesen, die aus den Aussagen der Testpersonen stammen. Ob sich das Muster in anderen Domänen wiederholt, etwa bei Fachleuten, die mit Wahrscheinlichkeiten arbeiten, können wir aus diesen Sitzungen nicht sagen.
Was sich abstellen lässt
Die Alternativen, die an die Aufgabe anschließen, haben gemeinsam, dass sie die Unsicherheit an einer Stelle im Fall verorten statt an der Ausgabe als Ganzes.
Die Markierung der unsicheren Stelle zeigt in der Ausgabe, welche Angabe die Funktion nicht sicher bestimmen konnte, etwa den Betrag oder die Zuordnung zur Sparte. Frau Berger prüft dann diese Angabe. Der Verweis auf die Ursache nennt, was zur Unsicherheit geführt hat: eine fehlende Anlage, widersprüchliche Angaben im Antrag, ein Fall, der dem Bereich der Funktion nur teilweise entspricht. Sie weiß dann, wo sie nachsehen muss. Die Handlungsempfehlung im Prüfablauf formuliert die Unsicherheit als Schritt: „Prüfen Sie die Angabe zum Vertragsbeginn in Anlage 1." Das entspricht der Form, in der Kolleginnen und Kollegen einander Hinweise geben. Und die Schwelle in der Sprache der Aufgabe ersetzt die Zahl durch eine Zuordnung, die im Fachbereich bereits existiert: Vorschlag zur Übernahme, Vorschlag zur Prüfung, kein Vorschlag. Die Grenzen zwischen den drei Stufen legt der Fachbereich fest, und sie stehen in der Spezifikation.
Jede dieser Alternativen wird als Nutzungsanforderung formuliert und im Test geprüft, mit Aufgaben, in denen der Vorschlag einen Fehler enthält, und mit dem Erfolgskriterium, dass die Person den Fehler an der Angabe erkennt. Welche Alternative in welcher Anwendung funktioniert, wissen wir erst nach diesem Test. Wenn Sie eine der Varianten bereits im Einsatz haben, interessiert mich, was Ihre Sitzungen zeigen.