Aus dem Experiment abgeleitete Usability-Probleme

Ziel des Experiments war unter anderem die Herausarbeitung bestehender Gebrauchstauglichkeitsprobleme in diesem Programmteil. Dazu bin ich nun die verschiedenen Protokolle der Aufgabenlösung durchgegangen und habe versucht, daraus Gebrauchstauglichkeitsprobleme abzuleiten. Zusätzlich habe ich noch die Nachbesprechung ,,Was hat sie an dem Programm gestört? `` und die Bewertung der ausgewählten Probleme aus der heuristischen Evaluation miteinbezogen. Die Darstellung ist wie folgt:

Problem: (Gewicht) Kurzbeschreibung des Problems [ Kürzel der Versuchspersonen (Zahl=Nummer im Protokoll, N=Nachbesprechung, H=Heuristik)]
Erläuterungstext

Nicht alle Punkte aus den Protokollen deuteten automatisch auf ein Gebrauchstauglichkeitsproblem hin. Manche bezogen sich auf allgemeine Probleme mit Schichtplanthematik, andere auf die Struktur von BASS II als Ganzes. Solche Punkte wurden hier nicht weiter berücksichtigt. Die Auswahl, ob ein Punkt nun zu einer zu berücksichtigen Kategorie gehörte oder nicht, muß der Evaluator vor dem Hintergrund seiner Programm- und seiner Benutzerkenntnis fällen.

Die Reihenfolge der Probleme ist nicht gleichzusetzen mit einer Gewichtung, sondern hat sich aus der sequentiellen Abarbeitung der Versuchspersonen und der Punkte ergeben. Eine Gewichtung erfolgte je nach Schwere der Störung der Aufgabenlösung (siehe Tabelle

Gewicht Begründung

fatal Die Aufgabenlösung wurde verhindert.

schwer Es kam zu einem falschen Ergebnis.

mittel Es kam zu einer Verzögerung, aber es wurde selbstständig eine Lösung gefunden

leicht Es kam nur zu einer leichten Verzögerung.

Tabelle: Gewichtungsschema für die Experimentauswertung

**Tabelle:** Gewichtungsschema für die Experimentauswertung
Gewicht	Begründung
fatal	Die Aufgabenlösung wurde verhindert.
schwer	Es kam zu einem falschen Ergebnis.
mittel	Es kam zu einer Verzögerung, aber es wurde selbstständig eine Lösung gefunden
leicht	Es kam nur zu einer leichten Verzögerung.

Problem: (mittel) Trennung von Schichtbedarf und Schichtplan [ N1(2,8,36), E1(1), E2(5), E3(1,N))]

Es kam immer wieder zu Verwechselungen zwischen Schichtplan und Schichtbedarf. Die Darstellung der Schichtverteilungen in beiden Fenstern ist identisch, wohingegen die restlichen Elemente größtenteils verschieden sind. Zum Beispiel gibt es im Schichtbedarfsfenster eine Auswahlliste der definierten Schichten, welches im Plan fehlt. Offenbar verwechseln auch die erfahrerenen Benutzerinnen diese beiden Bearbeitungsschritte.

Daß das Problem bei N2 nicht auftrat, ist darauf zurückzuführen, daß N2 den Schichtbedarf nicht näher gesehen hatte, wohingegen N1 ausdrücklich danach gefragt hatte.

Dieses Problem liegt allerdings eher im Bereich der Aufgabenanalyse. Dort hätte bereits festgestellt werden können, daß die strikte Trennung von Bedarf und eigentlichem Plan unter Umständen unnötig kompliziert ist. E3 hatte dies dann einerseits auch bemängelt und andererseits in der Nachbesprechung ausdrücklich gesagt, daß es eine solche Trennung geben müsse. Hier müßte eine weitere gründlichere Aufgabenanalyse Klarheit verschaffen.

Trotzdem ist die Erkennbarkeit von Schichtplänen im Gegensatz von Schichtbedarfsrastern ein mittleres Usability-Problem, da es zu Verzögerungen bei der Bedienung führte.

Problem: (leicht) Vertauschung von Schichten bei Drag&Drop nicht erkannt [ N1(6,13), N2(6)]

N1 erkannte nicht sofort das Vertauschen der Schichten. N2 war sich unsicher, ob die Schichten so nicht verdoppelt würden. Beide fanden es aber innerhalb kurzer Zeit heraus und machten es dann fortan auch richtig. Die erfahrenen Benutzerinnen hatten es auch nach längerer Nichtbenutzung des Programmes nicht vergessen.

Dadurch ergibt sich die Gewichtung als ,,leichtes`` Problem, wenn überhaupt. Der Verschiebemechanismus an sich (Drag&Drop) wurde von allen Versuchspersonen sofort gesehen und genutzt. Selbst die ungeübten Benutzer hatten damit keine Startschwierigkeiten (N1(9,10), N2(6)).

Problem: (schwer) Aussageschwache Bezeichnungen im Menü ,,Kriterien`` [ N1(7,21,23), E1(20),E2(7),E3(H),N2(3,4,17,20,23,H)]

Bei allen Benutzern kam es durch dieses Problem zu Verzögerungen und sogar manchmal zu Fehlern, selbst bei den erfahrenen Benutzerinnen.

Problem: (schwer) Fehlende Legende [ N1(14,28), E1(6,7,19,H), E2(8,9,10,20,24,H), E3(3,H), N2(5,H)]

Auch wenn in der Besprechung der Heuristikergebnisse alle Benutzer die Notwendigkeit einer solchen Erläuterung der gerade dargestellten Kriterien nicht sahen, kam es immer wieder zu Fehlinterpretationen, selbst bei den erfahrenen Benutzerinnen. Das als Legende nutzbare Fenster ,,Bewertung`` kann diesen Zweck offensichtlich nicht vollständig erfüllen, da es bei größeren Plänen schnell überdeckt wird und auch nur die Farben, nicht aber die Art der Darstellung (Balken, Kasten oder Zahl) angibt. Außerdem kam es auch zu Unklarheiten bezüglich der gerade gültigen Parameter.

Dieses Problem müßte zusammen mit dem vorherigen betrachtet werden, denn eine Legende muß dann natürlich auch aussagekräftige Bezeichner haben, die konsistent zum Restprogramm sein müssen und andererseits kurz genug, um sie gleichzeitig mit dem Plan darzustellen. Insgesamt ist die Darstellung von Kriterien im Plan durch farbige Markierungen an sich allen Versuchspersonen sofort klar gewesen.

Wirklich schwer wird dieses Problem allerdings dadurch, daß die Unklarheiten über die aktuellen Parameter zu falschen Ergebnissen führen können. Ob diese unbedingt in einer Legende dargestellt werden müßten, wäre nocheinmal kritisch zu betrachten.

Problem: (leicht) Kommentarfeld wird nicht als solches erkannt [ N1(15,31),E1(11,N), E2(12), E3(6), N2(12)]
Zwar wird das Kommentarfeld von keinem als solches ohne Hinweis erkannt, doch andererseits bedeutet dies nur den Verzicht auf ein ,,Feature`` des Programmes, das selbst den an der Entwicklung Beteiligten unbekannt war.

Problem: (fatal) ,,Speichern als...`` verhält sich unerwartet [ N1(16), E1(12,15,21,N), E2(27), E3(7,13,N), N2(13)]

Das Verhalten des Menüpunktes ,,Speichern als...`` führte entweder zu Datenverlusten, wenn die Benutzer annahmen, sie würden nun in dem neuen Plan arbeiten und dabei in Wirklichkeit den alten überschrieben, oder zu Umwegen (E3) bei der Bedienung

Problem: (mittel) Kriterien müssen jedes Mal nach einem Programmstart für jeden Plan im Pulldownmenü ,,Kriterien`` neu angewählt werden [ N1(19,H), E2(14), E3(N)]

Dies führt natürlich zu Verzögerungen. Außerdem steigt das Fehlerrisiko, ein wichtiges Kriterium unter Umständen zu vergessen. (siehe auch Problem

)

Problem: (schwer) Umweg bei der Kriteriendarstellung ,,Anwählen`` dann ,,Definieren`` und dann ,,Aktivieren`` [ N1(25,26,27,H), E1(16,H), E2(N,H), E3(N,H), N2(25,N,H)]
Der Umweg, ein Kriterium zunächst in die Liste der möglicherweise zu bewertenden Kriterien einzutragen, es dann mit einem gültigen Parameter zu versehen und dann auch noch einmal extra aktivieren zu müssen, damit es auch tatsächlich angezeigt wird, führte zu Fehlern und Beschwerden in der Nachbesprechung. Vor allem steigt auch hier das Fehlerrisiko, einen dieser Schritte falsch oder gar nicht auszuführen. (siehe auch Problem

)

Problem: (schwer) Parametereingaben [ N1(25,29,35,H), E1(13,18,H), E2(13,15,16,18,25,N), E3(10,H), N2(9,10,16,18,27,N)]
Die Eingabe von Parametern zu den Kriterien wies mehrere Schwierigkeiten auf: Zum einen war unklar, wann denn nun die Parametereingabe abgschlossen sei und auch erfahrene Benutzerinnen beendet die Parametereingabe (hier überflüssigerweise) wohl gewohnheitsmäßig mit [Return]. Zum anderen wurde es von allen Benutzern als lästig empfunden, daß die Eingaben ignoriert wurden, sobald der Mauszeiger, zum Beispiel durch Erschütterungen des Tisches durch das Eintippen, das Fenster verließ. Dieses Verhalten führte bei allen Benutzern zu Verzögerungen und die meisten beschwerten sich auch ausdrücklich.

Ein weiteres Problem stellte eine Unsicherheit über die gerade gültigen Parameter dar. Manche Benutzer bemerkten gar nicht, daß andere als die gewünschten Parameter aktuell waren. Dieses habe ich allerdings dem Problem

zugeordnet, da eine Legende auch Informationen über die zur Zeit aktuellen Parameter geben sollte.

Problem: (schwer) Aktivierung von Kriterien [ N1(25,27,H), E1(3,14,17), E2(5,6,19),N2(1,25,26)]

Es kam zwar nur gelegentlich vor, daß Benutzer vergaßen, ein angewähltes Kriterium auch zu aktivieren, doch dann wurde dies auch nicht mehr entdeckt. Dadurch könnte es zu Fehlern bei der Planoptimierung kommen. In den Fallbeispielen wurde dies durch die teilweise Redundanz von Kriterien meist vermieden.

Dieses Problem muß dann auch im Zusammenhang mit der fehlenden Übersicht über die zur Zeit aktuellen Parameter und dargestellten Kriterien gesehen werden. Eine Neugestaltung eines Teils der Kriterienauswahl würde alle diese Probleme betreffen.

Problem: (leicht) ,,Abreißmenü`` (siehe Anhang ) nicht erkannt [ N1(20),E1(2,H)]

Neue Benutzer kannten die Bedienung eines Abreißmenüs nicht und auch die erfahrenen Benutzerinnen hatten in Vorversuchen ab und zu vergessen, wie man das Pull-Down-Menü in ein Fenster umwandelt.

Dies führt zwar zu Verzögerungen und somit zu einer etwas herabgesetzten Effizienz, doch nicht zu Fehlern oder ähnlichem.

Problem: (leicht) Dateihierarchie beim Speichern nicht erkannt [ N1(32), E1(N), E2(22), E3(8)]
Die meisten Benutzer erkannten nicht, daß jeder Schichtbedarf ein eigenes Datenverzeichnis hatte und somit die Namen nur innerhalb eines Schichtbedarfs unterschiedlich sein müssen. Stattdessen gaben sie sich Mühe, jedesmal eigene Namen zu vergeben (,,Plan``, ,,Plan2``), auch wenn es sich um verschiedene Schichtpläne handelte.

In Abbildung

wird der Grund für diese Annahme deutlich. Die Hierarchie ist nicht abgebildt, selbst der Name des Schichtbedarfes ist nicht noch einmal angegeben. Da ist das Verhalten der Benutzer nur richtig gewesen.

Dieses Problem führt auf Dauer aber nur zu Verzögerungen, denn die Benutzer müssen sich immer wieder neue Namen ausdenken.

Problem: (schwer) Erkennbarkeit der Farben [ N1(30,N,H), E1(N,H), E2(23,H), E3(H), N3(H)]

Die Gewichtung dieses Problems war etwas schwierig. Zum einen kann das Übersehen einer Farbe zu einem suboptimalen Plan führen, zum anderen kam dieser Fall nur ein einziges Mal wirklich vor. Hier fehlt die statistische Auswertung größerer Versuchsreihen, um zu einem endgültigen Ergebnis zu kommen. Die Einordnung als ,,schwer`` erfolgte letztlich aufgrund der in Tabelle

, ist aber diskussionswürdig.

Problem: (mittel) Fehlermeldungen [ E2(15), E3(N), N2(19)]
Die Fehlermeldung ,,Falsches Zeitformat``, die sich so penetrant in den Vordergrund drängt, auch wenn das fehlerverursachende Fenster teilweise überdeckt ist, hatte selbst bei der erfahrensten Benutzerin Irritation hervorgerufen. Die Tcl-Fehlermeldung bei N2(19) hatte nur in eine Sackgasse geführt, der Anwender wußte nicht mehr weiter.

Abgemildert wird die Schwere dieses Problems durch die Tatsache, daß der Benutzer nicht direkt zu einem falschen Ergebnis gelangt. Probiert er zum Beispiel alle drei Möglichkeiten des Tcl-Fehlerdialogs aus, so hat er bei [OK] oder [Skip messages] keine weiteren Auswirkungen. [Stack Trace] erzeugt zwar einen für den Benutzer unlesbaren Textdump, ist aber nicht weiter gefährlich für die Daten.