Im Lenkungskreis liegt die Anforderungsliste für das neue Leitsystem, und sie ist aus dem Funktionskatalog des alten entstanden. Der Anlass ist in jedem Haus ein anderer: Ein Leitsystem wird abgelöst, ein Smart-Meter-Rollout verändert die Arbeit im Netzbetrieb, eine Fachanwendung wandert vom Desktop in die Cloud, eine gewachsene Modullandschaft wird konsolidiert. In jedem dieser Fälle entscheidet die Migration über Arbeitsplätze, an denen Fehlbedienung teuer oder gefährlich ist. Diese Checkliste ordnet, welche Fragen zur Nutzung vor der Migrationsentscheidung offen sind und welche Beobachtung sie beantwortet.
Einordnung
Aus unseren Projekten mit Netzbetreibern und Softwarehäusern kennen wir drei Muster. Klassische Usability-Tests zeigen kognitive Engpässe im Leitstand nur unvollständig, weil die Person die Aufgabe abschließt und der Test nicht sieht, welche Meldung sie dabei übersehen hat. Power-User verweigern Vereinfachung, und Neueinsteiger finden nicht hinein. Und rund um Abschlusstermine ist die Zielgruppe für Studien kaum verfügbar. Diese drei Muster bestimmen, was vor einer Migration geklärt werden muss. Wir arbeiten und beobachten dort, wo die Menschen Ihr Produkt benutzen. Die Punkte unten sagen, was diese Beobachtung liefern soll, und zu jedem Punkt steht, woran Sie im Review erkennen, ob die Angabe erhoben oder geschätzt ist.
Die Checkliste
Der Migrationsanlass und sein Zeitrahmen sind benannt. Ablösung eines Leitsystems, Smart-Meter-Rollout, Desktop-zu-Cloud-Migration und Konsolidierung gewachsener Module setzen unterschiedliche Fristen. Legen Sie die Beobachtung vor die Entscheidung, die die Anforderungen an das neue System festlegt. Erhoben ist der Zeitrahmen, wenn er mit Datum aus dem Projektplan stammt.
Die Arbeitsplätze und Rollen sind erfasst. Schichtleitung, Operatorinnen und Operatoren, Neueinsteiger und Sachbearbeitung mit Abschlussterminen arbeiten mit demselben System unter verschiedenen Bedingungen; jede Rolle hat einen eigenen Nutzungskontext. Prüfen Sie, ob die Liste der Rollen aus dem Betrieb bestätigt ist oder aus dem Organigramm abgeleitet.
Die Aufgaben, bei denen Fehlbedienung teuer oder gefährlich ist, sind benannt. Nicht jede Funktion braucht dieselbe Prüftiefe. Die kritischen Aufgaben bestimmen, wo Blickführung und Reaktionszeit erhoben werden müssen. Erhoben ist die Liste, wenn Betrieb und Qualitätsmanagement sie benannt haben und Vorfälle aus dem Register dahinterstehen.
Die Nutzung des Altsystems ist beobachtet worden. Interviews liefern die Erinnerung an die Arbeit. Die Beobachtung am Arbeitsplatz zeigt Umwege, Merkzettel, Parallelfenster und Zurufe an den Nachbarplatz, die im Interview niemand erwähnt. Im Review erkennen Sie die Beobachtung an Protokollen mit Datum, Arbeitsplatz und Rolle; ein Kapitel aus Systemsicht ist keine Beobachtung.
Power-User und Neueinsteiger sind getrennt betrachtet. Was für langjährige Operatoren eine Vereinfachung zerstört, ist für Neueinsteiger der einzige Zugang. Planen Sie für beide Gruppen eigene Aufgaben und eigene Befunde. Erhoben ist die Trennung, wenn die Protokolle beider Gruppen getrennt vorliegen.
Die Schichtplanung erlaubt Studien im Betrieb. Sitzungen im Kontrollraum brauchen einen Zeitpunkt, an dem eine Person beobachtet werden kann, ohne den Betrieb zu gefährden. Planen Sie diesen Zeitpunkt mit der Schichtleitung. Ein Termin, den die Schichtleitung bestätigt hat, ist erhoben; einer aus dem Projektkalender ist eine Annahme.
Die Terminlogik der Fachdomäne steht im Studienplan. Abschlusstermine, Fristen, Kampagnen und Schichtwechsel legen fest, wann die Zielgruppe erreichbar ist. Ein Studienplan ohne diesen Kalender scheitert an der Rekrutierung. Lassen Sie sich den Kalender aus dem Fachbereich geben und legen Sie ihn neben den Studienplan.
Die Blickführung an kritischen Stellen ist bekannt oder wird erhoben. Wo ein Usability-Test nur den Abbruch sieht, zeigt Eyetracking, wohin die Person gesehen hat und was sie übersehen hat. Eine Aussage zur Blickführung ohne Aufzeichnung ist eine Vermutung der Beobachtenden und wird so geführt.
Ein Testarbeitsplatz oder Nachbau ist möglich. Ein Arbeitsplatz, an dem sich Aufgaben ohne Eingriff in den Betrieb wiederholen lassen, macht Studien planbar und den Vergleich zwischen Alt- und Neusystem möglich. Klären Sie mit dem Betrieb, ob ein Arbeitsplatz frei ist oder ein Nachbau nötig wird, und halten Sie die Antwort fest.
Übergabepunkte für Assistenz- und KI-Funktionen sind benannt. Wenn das neue System Vorschläge erzeugt oder Entscheidungen vorbereitet, muss vorher feststehen, wer sie prüft und nach welchem Kriterium. Erhoben ist der Übergabepunkt, wenn die prüfende Rolle ihn im Gespräch beschrieben hat; ein Satz aus dem Systemkonzept ist eine Absicht des Anbieters.
Die Anforderungen an das neue System sind aus der Beobachtung abgeleitet. Nutzungsanforderungen nach ISO 9241-210 nennen, was eine Person in welcher Situation erreichen muss, und sind messbar. Anforderungen aus dem Funktionskatalog des Altsystems sind es meist nicht. Prüfen Sie im Review, ob jede Anforderung auf ein Protokoll oder eine Sitzung verweist.
Ohne diese Angaben wiederholt das neue System die Umwege des alten
Wer die Nutzung nicht beobachtet hat, schreibt die Anforderungen aus dem Altsystem ab. Wer Power-User und Neueinsteiger nicht trennt, bekommt Befunde, die sich widersprechen. Wer keinen Testarbeitsplatz hat, kann nach der Migration nicht vergleichen. In einem unserer Projekte standen die Umwege des alten Systems als Anforderungen im Backlog des neuen, weil niemand am Arbeitsplatz gewesen war; die Beobachtung kam nach, und die Liste wurde umgeschrieben.
Die Strecke beschreibt in den folgenden Beiträgen, was Eyetracking im Leitstand zeigt, wie Studien in der Schicht ablaufen und wie ein Testarbeitsplatz im Kontrollraum Wiederholung möglich macht. Der nächste Beitrag: `power-user-und-neueinsteiger`.