Zwei Funktionen von MockUps: - Testen "wie in echt" - Diskutieren, Vorschlagen -> streng zu trennen Dementsprechend hat die Test-Sitzung zwei Teile. Ich lasse diese Teile sich abwechseln. In einem Teil simulieren wir die Bearbeitung einer Aufgabe (Anwendungsfall). Nach jeder Aufgabe wird dies kurz ausgewertet. Es ist wichtig, dass ich mich als Beobachter nicht in die Bearbeitung der Aufgabe einmische! Ich mache mir Notizen zum Verhalten des Probanden! Der Proband "denkt laut". Ich habe für den Test eine Reihe von Aufgaben vorbereitet, diese sind jeweils als Text gegeben. Für jeden Probanden wähle ich seiner Nutzergruppe entsprechend Aufgaben aus. Der Proband hat dabei die Möglichkeit, Augaben, die nicht auf ihn zutreffen, zu überspringen. Für ihn _seltene_ Aufgaben sollte er aber auch durchspielen! Wenn die von mir gewählten Aufgaben abgearbeitet sind, darf der Proband noch Aufgaben vorschlagen, die ich vergessen habe. Entweder ich habe zu einer solchen Aufgabe schon einen Text (und hatte die Aufgabe nur anfangs nicht ausgewählt) oder ich formuliere die Aufgabe kurz schriftlich auf Papier. Wichtig ist, dass ich in der Diskussion mit dem Nutzer möglichst nicht mit den Begriffen aus der Spezifikation operiere, sondern die Sprache des Nutzers annehme! (Erstens, um besser verstanden zu werden, zweitens weil der Nutzer das Modell alleine verstehen muss.) Wir reden über das, was sichtbar ist. Über die Darstellung, nicht die Ideen dahinter. Nach jeder Aufgabe darf der Proband Fragen stellen, was passiert, wenn er die Aufgabe leicht modifiziert. Zum Beispiel Suche nach "mathe I" statt "Mathematik I". Ich sage dann, was mein System machen würde (genau nach Spezifikation) und der Proband sagt, ob ihm das gefällt. Dann darf ich Fragen stellen: nach allgemeiner Kritik und Verbesser- ungsvorschlägen und dann nach Stellen, an denen ich noch keine Lösung hatte.(1) Zuletzt frage ich, wie häufig (Tage, Wochen, Semester, ..) diese Aufgabe erwartungsgemäß ausgeführt wird. Nachdem auch die vom Probanden vorgeschlagenen Aufgaben abgearbeitet sind, bewertet er anhand des Modells und der MockUps die Nutzungs- häufigkeit für einzelne Funktionen. (Diesmal Funktionen als Elemente der Spezifikation, nicht Aufgaben. Am Ende hat der Proband ja einen Überblick über das System.) Danach kommt noch eine Abschlussrunde mit Fragen, Kritik und Vorschlägen. ------- In den MockUps selbst muss unterschieden werden, zwischen Funktionen, die _noch_ nicht funktionieren (weil's ein Prototyp ist) und solchen, die _überhaupt_ nicht funktionieren werden (weil's im Modell nicht vorgesehen ist). Dazu werde ich alle im MockUp anklickbaren Links markieren. Die Links zu Funktionen sollten alle aber funktionieren, nur die Daten müssen nicht alle verfügbar sein. [[Aktuelle Lösung: alle Links führen zu den selben Daten.] Die MockUps sollten möglichst streitbar sein. Also nicht Dinge zeigen, denen sowieso jeder zustimmt, sondern Alternativen präsentieren, die noch offen sind. Schließlich müssen nach dem MockUp-Test alle Fragen geklärt sein. "Ein schönes Icon ist wie ein Lächeln. Es hilft dem Nutzer nicht weiter, aber es kann ihn animieren, zu klicken, also sich selbst zu helfen." Nach diesem Motto würde ich gern ein paar Bildchens ins System einfügen. Ich kann aber nicht zeichnen. Schade. (1) Insbesondere die Standard-Einstellungen, d.h. z.B. welche Darstellung der Verans.mengen ist initial aktiv.