Fehlertoleranz nach ISO 9241-110 bedeutet, dass das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben mit keinem oder geringem Korrekturaufwand erreichbar bleibt. Bei einer Funktion mit generierter Ausgabe kommt der Fehler häufig aus der Ausgabe, und er ist vorab nicht bekannt. Der Beitrag überträgt den Grundsatz auf solche Funktionen und benennt die Anforderungen an Rücknahme, Vergleich und Korrekturweg. Er richtet sich an Interaction Designer und UX-Verantwortliche, die eine solche Funktion spezifizieren oder im Review prüfen.
Ausgangslage
In der Norm ist Fehlertoleranz auf Eingabefehler ausgerichtet: Die Person tippt etwas Falsches, wählt die falsche Option, vergisst ein Feld. Das System soll den Fehler erkennen, vermeiden helfen und die Korrektur erleichtern. Die Fehlerzustände sind dabei aufzählbar, und die Gestaltung kann sie einzeln abfangen.
Bei einer Funktion, die Text erzeugt oder Fälle zuordnet, tritt der Fehler an einer anderen Stelle auf. Die Eingabe ist korrekt, die Ausgabe enthält eine fehlende Angabe, eine falsche Zuordnung oder eine Aussage, die im Original nicht steht. Der Fehler ist vorab nicht bekannt, er lässt sich nicht aufzählen, und er sieht aus wie ein richtiges Ergebnis. Die Person muss ihn finden, und sie muss danach zum Arbeitsergebnis kommen, ohne von vorn zu beginnen.
Fehlertoleranz heißt in diesem Fall: Der Weg von einer fehlerhaften Ausgabe zum verwendbaren Arbeitsergebnis ist kurz, und er ist in der Oberfläche vorgesehen. Wir beschreiben drei Anforderungen, die diesen Weg herstellen, und eine vierte für den Fall, dass er nicht reicht.
Anforderung 1: Rücknahme
Jede Handlung, die auf einer Ausgabe beruht, lässt sich rückgängig machen, solange die Person sie noch nicht weitergegeben hat. Die Übernahme einer Zusammenfassung in den Vorgang, die Anwendung einer vorgeschlagenen Zuordnung, das Einfügen eines Entwurfs: Alle drei sind Handlungen mit Rücknahme, und die Rücknahme stellt den Zustand vor der Handlung wieder her, einschließlich der Daten, die die Ausgabe überschrieben hat.
Zusätzlich lässt sich eine Ausgabe verwerfen, ohne dass etwas passiert ist. Die Person hat die Ausgabe gelesen, hält sie für unbrauchbar und geht zurück zum Ausgangspunkt. Im Review prüfen wir, ob dieser Ausgangspunkt nach dem Verwerfen unverändert ist. In Tests sehen wir Funktionen, die die Ausgabe sofort in den Vorgang schreiben, so dass die Person danach aufräumen muss. Das ist der Fehlerfall mit dem höchsten Korrekturaufwand.
Anforderung 2: Vergleich
Die Person kann die Ausgabe neben dem Original sehen, aus dem sie entstanden ist, und neben früheren Ausgaben zum selben Fall. Der Vergleich mit dem Original ist die Handlung, mit der ein Fehler gefunden wird; ohne ihn bleibt der Fehler unsichtbar. Der Vergleich mit früheren Ausgaben zeigt, worin die Funktion schwankt, und gibt der Person die Wahl.
Die Oberfläche stützt den Vergleich, indem sie die Stellen markiert, an denen die Prüfung nötig ist: Pflichtangaben, Zahlen, Namen, Aussagen ohne Herkunft im Original. Eine Markierung an der Ausgabe, die auf die Stelle im Original verweist, verkürzt die Prüfzeit; das ist im Test messbar. Was das System nicht verarbeitet hat, etwa einen Anhang, wird als nicht verarbeitet angezeigt.
Anforderung 3: Korrekturweg
Ist der Fehler gefunden, korrigiert die Person die Ausgabe an Ort und Stelle. Sie ergänzt die fehlende Angabe, ändert die Zuordnung, streicht den Satz. Die Korrektur bleibt erhalten, auch wenn danach ein erneuter Durchlauf gestartet oder die Ausgabe aktualisiert wird. Eine Korrektur, die beim nächsten Durchlauf überschrieben wird, erzeugt denselben Aufwand ein zweites Mal.
Der Korrekturweg hat eine zweite Richtung: Die Person kann die Funktion auf einen Teil der Ausgabe erneut anwenden, ohne den Rest zu verlieren. Ein Absatz wird neu erzeugt, die übrigen bleiben. Ob die Nutzergruppe diese Möglichkeit braucht, zeigt die Kontexterhebung; bei langen Ausgaben liegt sie nahe.
Anforderung 4: Der Weg ohne die Funktion
Wenn Rücknahme, Vergleich und Korrektur zusammen mehr kosten als das eigene Erstellen, muss die Person die Aufgabe ohne die Funktion abschließen können, aus derselben Oberfläche heraus und ohne Umweg über ein anderes Werkzeug. Der Weg ist in der Oberfläche sichtbar und führt zum selben Arbeitsergebnis. Eine Funktion, die sich nicht umgehen lässt, zwingt die Person in den Korrekturaufwand, auch wenn er die Aufgabe verlängert.
Der Weg ohne die Funktion ist zugleich das Abbruchkriterium für den Test. Wählen Testpersonen ihn bei einer Fallart regelmäßig, ist die Funktion für diese Fallart nicht gebrauchstauglich, und das ist ein Befund an das Produktteam.
Die Prüfung im Test
Im Usability-Test enthalten die Aufgaben Ausgaben mit bekannten Fehlern an bekannter Stelle. Beobachtet wird, ob die Person den Fehler findet, welche Vergleichsmöglichkeit sie dafür nutzt, wie lange die Korrektur dauert, ob die Korrektur erhalten bleibt und ob sie zum Weg ohne die Funktion greift. Das Protokoll hält je Durchlauf Prüfzeit, Eingriffe und Ausgang fest. Effizienz nach ISO 9241-11 wird am Gesamtaufwand bis zum verwendbaren Ergebnis gemessen, und die Fehlertoleranz zeigt sich daran, wie stark eine fehlerhafte Ausgabe diesen Aufwand erhöht.
Grenzen
Die vier Anforderungen setzen voraus, dass die Person den Fehler erkennen kann. Erkennbarkeit ist eine Frage der Selbstbeschreibungsfähigkeit und der Fachkenntnis der Nutzergruppe; eine Oberfläche mit gutem Korrekturweg hilft nicht, wenn niemand merkt, dass korrigiert werden muss. Die Anforderungen gelten außerdem für Funktionen, deren Ausgabe eine Person vor der Weiterverwendung sieht. Für Funktionen, die ohne Sichtung in einen Ablauf schreiben, greifen sie nicht; dort ist die Frage, ob eine solche Funktion in diesem Nutzungskontext zulässig ist.
Was danach vorliegt
Vier Anforderungen an die Oberfläche, formuliert als Nutzungsanforderungen mit Prüfkriterium: Rücknahme jeder Handlung auf Basis einer Ausgabe, Vergleich mit Original und früheren Ausgaben, Korrektur an Ort und Stelle mit Bestandsschutz, Abschluss der Aufgabe ohne die Funktion. Dazu Testaufgaben mit bekannten Fehlerfällen und ein Protokoll, das den Korrekturaufwand je Durchlauf erfasst. Das Team kann damit Fehlertoleranz nach ISO 9241-110 für eine Funktion prüfen, deren Fehler es vorher nicht kennt.
