Selbstbeschreibungsfähigkeit für Funktionen mit unsicherer Ausgabe

Selbstbeschreibungsfähigkeit für Funktionen mit unsicherer Ausgabe

Selbstbeschreibungsfähigkeit für Funktionen mit unsicherer Ausgabe

Selbstbeschreibungsfähigkeit für Funktionen mit unsicherer Ausgabe

|

KI menschzentriert

Von

leefs Redaktion

Der Grundsatz der Selbstbeschreibungsfähigkeit aus ISO 9241-110 verlangt, dass ein System seinen Zustand und seine Möglichkeiten erkennbar macht. Bei generierten Ausgaben gehören zwei Angaben dazu, die bei deterministischen Funktionen selten gebraucht wurden: die Herkunft der verwendeten Daten und die Grenze des Zuständigkeitsbereichs. Der Beitrag beschreibt Gestaltungsmittel für beide Angaben, zeigt, wie sie als Nutzungsanforderung formuliert werden, und wie sich im Test prüfen lässt, ob sie ihren Zweck erfüllen. Er richtet sich an Interaction Designer und Produktverantwortliche.

Ausgangslage

Eine Funktion, die aus einem Antrag eine Zusammenfassung erzeugt oder zu einer Anfrage eine Antwort vorschlägt, arbeitet mit Eingaben, die die Person an der Oberfläche nicht vollständig sieht: Felder aus mehreren Systemen, Anlagen, frühere Vorgänge, Wissensbestände mit einem Stand, der nicht angezeigt wird. Und sie arbeitet in einem Bereich, der irgendwo endet: Für Fälle aus einer anderen Sparte, in einer anderen Sprache oder mit einem Format, das sie nicht lesen kann, liefert sie trotzdem eine Ausgabe, oft ohne erkennbaren Unterschied zu einer brauchbaren.

In Usability-Tests solcher Funktionen beobachten wir zwei Fragen, die Testpersonen an die Oberfläche stellen und dort nicht beantwortet bekommen: „Hat das den Anhang gelesen?" und „Ist das überhaupt für so einen Fall gedacht?" Beide Fragen betreffen die Selbstbeschreibungsfähigkeit. Das System hat seinen Zustand und seine Möglichkeiten nicht erkennbar gemacht. Die Beobachtung, dass die Datenherkunft eine der vier Eigenschaften generierter Ausgaben mit Gestaltungsfolgen ist, beschreibt `vier-eigenschaften-mit-gestaltungsfolgen`; dieser Beitrag geht einen Schritt weiter zu den Gestaltungsmitteln.

Bestandteil 1: Die Herkunft der Daten sichtbar machen

Die Person muss erkennen können, welche Eingaben in die Ausgabe eingeflossen sind, welchen Stand sie haben und was nicht verarbeitet wurde. Vier Gestaltungsmittel haben sich in unseren Projekten bewährt, und sie lassen sich kombinieren.

Die Quellenliste je Ausgabe nennt die Dokumente, Felder oder Vorgänge, die verwendet wurden, in den Bezeichnungen, die die Person aus ihrer Anwendung kennt: „Antrag vom Datum, Anlage 2, Vorgangshistorie". Der Verweis je Aussage markiert einzelne Stellen der Ausgabe und führt beim Aufruf an die Stelle im Original, aus der sie stammen; die Person prüft dann die Aussage, die sie prüfen will, statt die gesamte Ausgabe. Der Datenstand nennt, mit welchem Stand der Quellen die Ausgabe erzeugt wurde, damit die Person erkennt, ob eine Änderung von heute Vormittag enthalten ist. Die Liste des Nichtverarbeiteten führt auf, was übersprungen wurde: eine Anlage in einem Format, das die Funktion nicht liest, ein Feld, das leer war, ein Dokument, das zu lang war. Diese Liste ist das Mittel, das im Test am häufigsten fehlt und am häufigsten gebraucht wird.

Bestandteil 2: Die Grenze des Zuständigkeitsbereichs erkennbar machen

Die Person muss erkennen können, für welche Aufgaben und Fälle die Funktion vorgesehen ist und wann sie einen Fall außerhalb bearbeitet. Dafür gibt es drei Gestaltungsmittel.

Die Aufgabenbeschreibung an der Funktion sagt in einem Satz, wofür die Funktion gedacht ist, in den Begriffen der Aufgabe: „Fasst Anträge der Sparte X zusammen; Anlagen in Papierform werden nicht gelesen." Der Hinweis bei Eingaben außerhalb erscheint, wenn die Funktion einen Fall bekommt, der die Grenze überschreitet, und benennt den Grund: andere Sparte, andere Sprache, fehlende Pflichtangabe. Die Übergabe statt Ausgabe ist die Konsequenz für Fälle, die die Funktion nicht bearbeiten soll: Sie erzeugt dann keine Ausgabe, sagt das, und führt die Person zum manuellen Ablauf. Eine Funktion, die außerhalb ihres Bereichs eine plausibel klingende Ausgabe erzeugt, verletzt die Selbstbeschreibungsfähigkeit an der Stelle, an der es die meisten Folgen hat.

Die Angaben als Nutzungsanforderung formulieren

Beide Bestandteile werden als Nutzungsanforderungen geschrieben, mit Nutzergruppe, Aufgabe, erwartetem Ergebnis und Bedingung. Zwei Beispiele aus einer Fachanwendung in der Sachbearbeitung: „Eine Sachbearbeiterin erkennt an der Zusammenfassung eines Antrags, welche Anlagen verarbeitet wurden und welche nicht, bevor sie den Antrag entscheidet." Und: „Eine Sachbearbeiterin erfährt bei einem Antrag aus einer anderen Sparte, dass die Zusammenfassung dafür nicht vorgesehen ist, und gelangt ohne Umweg in die manuelle Bearbeitung." Beide Anforderungen nennen, wer, was, woran und wann. Beide lassen sich einer Messgröße nach ISO 9241-11 zuordnen, hier der Effektivität: Erkennt die Person die Lücke oder die Grenze, vollständig und rechtzeitig?

Im Anforderungsreview mit der Entwicklung klären wir zusätzlich, ob die Funktion die Angaben liefern kann: Weiß sie, welche Anlage sie übersprungen hat, und meldet sie das? Wenn nicht, ist die Anforderung an die Oberfläche eine Anforderung an die Funktion, und sie steht dann dort.

Im Usability-Test prüfen

Ob die Gestaltungsmittel ihren Zweck erfüllen, zeigt sich an Testaufgaben mit eingebauter Lücke. Die Person bekommt einen Fall, in dem eine Anlage nicht verarbeitet wurde, und einen Fall außerhalb des Zuständigkeitsbereichs. Das Erfolgskriterium ist, dass sie beides erkennt, bevor sie die Ausgabe übernimmt, und das Protokoll hält fest, an welcher Angabe sie es erkannt hat. Welche Darstellung der Angaben eine Prüfung am ehesten auslöst, ist offen; dazu fehlt ein Test mit mehreren Darstellungsvarianten an derselben Anwendung. Wir prüfen deshalb in Projekten, wenn möglich, zwei Varianten gegeneinander und dokumentieren, welche Angabe die Person gelesen hat.

Grenzen

Angaben zur Herkunft und zur Grenze setzen voraus, dass die Funktion sie liefern kann; das ist eine technische Voraussetzung, die im Review mit der Entwicklung geklärt wird. Angaben, die niemand liest, sind Ballast auf der Oberfläche; welche gelesen werden, entscheidet der Test und nicht die Vollständigkeit. Und die Selbstbeschreibungsfähigkeit nach ISO 9241-110 ist ein Gestaltungsgrundsatz. Ob und welche Informationspflichten aus dem AI Act für Ihre Funktion gelten, klärt die Rechtsabteilung; wie solche Pflichten in die Spezifikation kommen, beschreibt `regulatorische-anforderungen-in-die-spezifikation`.

Was danach vorliegt

Je Funktion mit generierter Ausgabe zwei Gruppen von Nutzungsanforderungen, zur Herkunft der Daten und zur Grenze des Zuständigkeitsbereichs, mit Gestaltungsmitteln im Entwurf der Oberfläche, geklärten Voraussetzungen an die Funktion und Testaufgaben mit Erfolgskriterium. Das Team kann nach dem Test sagen, ob eine Sachbearbeiterin erkennt, was die Funktion gelesen hat und wofür sie zuständig ist, und es kann die Anforderungen bei der nächsten Funktion wiederverwenden.