Kurzgefasst: Ich habe den Usability-Lifecyle zur Verbesserung der Bedienbarkeit des Ilmenauer "Stundenplan-Servers" verwendet. Dazu habe ich die Anforderungen für eine solche Web-Site von Grund auf neu ermittelt; ein Konzept für ein "elektronisches Vorlesungsverzeichnis" erstellt, dass diese Anforderungen befriedigt; und schließlich dieses Konzept in einem Prototypen-Test evaluiert.
Dies ist ein informeller Bericht; kein Medienprojekt oder etwas, für das man einen Schein bekommen kann. (Zumindest nicht am FG Medienkonzeption.)
Projekt-Daten
Zeitraum: Juli, August, September 2002
durchgeführt von: Robert Will
Auftraggeber: Dezernat für Planung der TU Ilmenau
Betreuung/Ansprechpartner: Tibor Kunert, Prof. Heidi Krömker
(beide FG Medienkonzeption TU Ilmenau)
Im ersten Abschnitt erläutere ich die prinzipielle Vorgehensweise bei einem solchen Projekt. In diesem Zusammenhang ist mein Projekt-Plan zu sehen, der sich am Ende des Abschnitts befindet. In den nächsten Abschnitten beschreibe ich die Phasen des Projektes, jeweils mit Vorgehen und den Ergebnissen. Die Phasen sind
Im letzten Abschnitt sage ich kurz, was denn nun daraus wird. Wer nicht so gerne liest, kann sich auch nur die MockUps anschauen.
Grundsätzlich müssen in jeden Software-(Außen-)Entwurf (d.h. die Erstellung der Spezifikation) drei Aspekte einfliessen:
Bei einem Projekt gibt es drei Beteiligte: der Auftragnehmer (Website-Konzepter und Entwickler), der Auftraggeber (Kunde des Auftragnehmers) und die Anwender (Kunden des Auftragnehmers). Die Anforderungen der Anwender wissen natürlich nur die Nutzer selbst - obwohl der Kunde hier natürlich Vorgaben macht, welcher Bereich behandelt werden soll. Viele Projekte werden auch ohne Nutzerbeteiligung durchgeführt und dann gibt der Kunde die Anforderungen (oder sogar schon die Gestaltung) natürlich vor. Das allgemeinen Gestaltungswissen hat der Konzepter (hoffentlich) während seinem Studium oder der Ausbildung erworben. Die technischen Möglichkeiten kann der Kunde vorgeben oder er lässt dem Auftragnehmer freie Wahl. Die organisatorischen Möglichkeiten werden komplett vom Kunden vorgegeben. Unter Umständen möchte der Kunde aber seine Organisation zugunsten der Anwender - seiner Kunden - ändern, dann muss der Website-Konzepter entsprechende Vorschläge machen (und natürlich begründen).
Ein Projekt nach dem Usability-Lifecycle läuft nun so ab, dass die Entwickler die Anforderungen aus den Kunden "herausholen" und dann unter Einbeziehung des Gestaltungswissens und der gegebenen Möglichkeiten ein Konzept erstellen. Dieses Konzept wird mit Hilfe eines Prototypen der Website illustriert und solange mit den Nutzern getestet und danach entsprechend korrigiert, bis es gut ist. Dies ist nötig, weil man bei gefunden Usability-Fehlern zwar weiß, dass das schlecht ist, aber noch nicht unbedingt, wie man es besser machen sollte. Deshalb muss die neue Gestaltungsvariante wieder genauso getestet werden.
Damit man nicht wegen eines einzigen Fehlers große Teile des Konzepts und des Prototypen ändern muss, erstellt man zunächst nur ein grobes Konzept und baut nicht-funktionale Prototypen (z.B. einfach nur Skizzen der Oberfläche, sogenannte MockUps) und detailliert diese mit jeder erfolgreichen Iteration. In den letzten Iterationen hat man es dann mit der fertigen Software zu tun, die noch solange evaluiert und korrigiert wird, bis sie gut ist. Wenn alles gut läuft, hat man für jeden Detaillierungsgrad genau eine Iteration. Um das zu schaffen wird man jeweils Gestaltungs-Alternativen ausarbeiten, so dass man
Es ist nun für jedes individuelle Projekt nötig zu entscheiden, welche Iterationstufen durchgeführt werden sollen. Natürlich muss auch festgelegt werden, wie die initiale Anforderungsanalyse durchgeführt werden soll. Wie ich das gemacht habe, beschreibe ich in der Planevolution.
Die Anforderungen werden von den Nutzer aufgenommen und anschließend analysiert. Analyse heißt: Klärung von Widersprüchen, Vervollständigung, Strukturierung, Bewertung. Man fasst die viele einzelnen Äußerungen zu einem Dokument zusammen, auf Basis dessen dann ein Konzept erstellt wird. Wie im Plan beschrieben, habe ich die initiale Anforderungen mit Fragebögen, Fokusgruppen und Interviews ermittelt.
Bevor ich die ersten Nutzergespräche durchführte, musste ich erstmal die Nutzer ausfindig machen. Dies war gar nicht so leicht, da die Informationen der Raumplanung vielfältig verwendet werden. Ausserdem habe ich anfangs kurz die Altsysteme begutachtet.
Nachdem ich alle Nutzer kannte, teilte ich sie in folgende Gruppen ein:
Auch die Reinigung wird von einer unabhängigen Firma durchgeführt, es gibt aber einen Mitarbeiter beim Dez. Planung, der die Raumplanung auswertet und entsprechend Aufträge an die Firma erteilt. Da dieser Mitarbeiter zur Zeit der Anforderungsaufnahme gerade im Urlaub war, habe ich die verantwortliche Mitarbeiterin der Reinigungsfirma interviewt.
Alle für mein Projekt aquirierten Nutzer sollten zunächst einen Fragebogen zur Bewertung der Altsysteme beantworten. Getan haben das aber nur die akademischen Nutzer.
Ergebnis der Fragenbogen-Auswertung war, dass alle Altsysteme genutzt werden und das auf alle möglichen Arten. Nur die Stundenpläne des Göttlich-Systems fanden wenig Anklang, das lag aber an Ihrer Gestaltung, generell wurde Stundenpläne nämlich gewünscht. Ausserdem verteilten sich die Nutzungsarten quer durch alle Nutzergruppen (der akademische Teilnehmer). Es konnte also durch die Aktion weder eine Aufteilung der Nutzer für die Fokusgruppen, noch eine Einschränkung des zu untersuchenden Bereichs gewonnen werden.
Mitarbeiter: Plan, Verlauf, Ergebnisse, Selbstkritik
Studenten: Plan, Verlauf, Ergebnisse
Von den Studenten habe ich Stundenpläne gesammelt, um deren Inhalte und Darstellung zu analysieren. Stundenplan-Spenden-Auswertung.
Ich habe drei Interviews Audio-aufgenommen und später ausgewertet: Heizmeister, Wachführer, Putzchefin, und ein Kurzgespräch nur mit Notizen geführt: Hörsaaltechnik
Die Stunden wünschten im eVV auch zu sehen, welche Veranstaltungen sie belegen müssen, welche sie anrechnen können, welche man nur gemeinsam und welche man nicht gemeinsam anrechnen kann. Daher habe ich mal schnell alle StuOn der TU Ilmenau durchgelesen. Es stellte sich heraus, dass das ziemlich juristisch vollgeladene Texte sind, mit Beschreibungen einzelner Typen von Lehrveranstaltungen und wenig Aussagen darüber, welche Scheine man denn nun anschaffen muss, um ein Diplom zu bekommen. Um diese Frage zu beantworten, reicht meist ein Blick in die angehängten Studienpläne.
Hier meine Analyse. Im Konzept modelliert der Begriff "Studienkomplex" ein paar Gemeinsamkeiten aller StuO, denn eine unterschiedliche Behandlung der SG verwarf ich wegen des Pflegeaufwands bei Änderungen der StuO.
Den wichtigen Begriff "(Website-)Konzept" lernte ich erst gegen Ende des Projektes kennen (in der Mensa in Hamburg), deshalb verwende ich noch die Begriffe "Modell" (für das Konzept vor dem Prototyping) und "Spezifikation" (für das Konzept vor der Implementation).
Im Rahmen der Konferenz "Mensch und Computer 2002" habe ich an einem Workshop betitelt "Entwurf und Konzeption von Webseiten" teilgenommen. In Unternehmen, die Web-Seiten entwickeln, gibt es zu dieser Tätigkeit eine Berufsgruppe, die sogenannten "Konzepter". So einer hat in dem Workshop über seine Arbeit berichtet: die einzelnen Seiten müssen einander zugeordnet werden, gemeinsame Elemente müssen identifiziert werden, dabei werden Seiten-Typen identifiziert. Alle Seiten eines Typs müssen gestaltet werden, außerdem kann es Untertypen (etc.) geben. Die Navigation muss entworfen werden. All das hatte ich gerade in den beiden Wochen, bevor ich den Workshop besuchte, zum ersten Mal getan.
mein Modell
Tibor Kunert hat den Vorschlag gemacht, eine Methapher für die gesamte Anwendung zu finden, so dass die Nutzer von Anfang an, eine Ahnung haben, was sie überhaupt prinzipiell machen können. Mir sind dazu zwei Sachen eingefallen, die aber letztendlich beide nicht richtig ins Kozept gepasst haben. Die erste Idee war, das Heraussuchen und Auswählen von Veranstaltungen für den persönlichen Stundenplan mit einem Einkauf zu vergleichen. Der Benutzer schiebt dann seinen Warenkorb durch die Gegend und wer schonmal online einkaufen war, weiß dann wie er Veranstaltungen auswählen kann. Die andere Idee war, den Stundenplan zum dominanten Gestaltungsmittel zu machen. Dies könnte man umsetzen, indem man schon auf der ersten Seite einen Stundenplan mit den Sonderveranstaltungen der aktuellen Woche anzeigt. Man könnte auch beide Möglichkeiten kombinieren und anstelle eines Warenkorbs eine Mini-Version des persönlichen Studenplanes anzeigen, an der man sieht, an welchen Terminen man "schon was hat".
Die Mockups zu dem Modell habe ich laufend verändert, es entstanden neue Alternativen und andere Alternativen wurden wieder verworfen. Die überlebenden sind nahtlos in die Mockups der Spezifikation übergegangen - sie finden sich also im nächsten Abschnitt.
Ein Test wurde nur für die akademischen Nutzer durchgeführt. Ich habe mich mit den Teilnehmern der Fokusgruppen einzeln getroffen und diese durften sich zuerst den Prototypen anschauen und sollten dann ein paar vorgegebene Aufgaben lösen. Die Aufgaben verlangen immer genau den Studiengang/das Fachgebiet/die Seminargruppe zu suchen, die auch in den MockUps enthalten ist.
Test-Plan,
zu lösende Aufgaben,
Test-Teilnehmer,
gefundene Fehler.
Bei der Besprechung der Spezifikation sagte der Dezernent für Planung zwei wichtige Sachen:
Bisher war ich davon ausgegangen, dass das Altsystem "Stundenplan-Server" von einem Programmierer des Dezernats für Planung erstellt wurde. Dieser Herr Göttlich ist aber eigentlich für etwas ganz anderes zuständig und hat den Stundenplan-Server nur ganz freiwillig nebenbei gemacht.
Wir einigten uns so, dass 1. meine Arbeit evtl. in das Projekt E-Campus eingehen wird, das irgendwann ansteht, und dass 2. Herr Göttlich ein paar Verbesserungen in sein System einbaut. Hier meine Thesen, mit denen ich ihn hoffentlich überzeugt habe.
In der Praxis ist der Auftraggeber (nicht die Nutzer) derjenige, gegenüber dem die Entwickler verantwortlich sind, und mit dem sie sich am meisten absprechen. Bei einem Studienprojekt ist das natürlich nicht wichtig, weil man nicht vom Auftraggeber bezahlt wird. Trotzdem bin ich wohl zuweit davon abgewichen. Ich empfehle allen Nachfolgeprojekten sich bereits ganz zu Anfangs mit "ihrem Auftraggeber" auseinander zu setzen (besser: sich mit ihm zusammen zu setzen :-) und eine Projekt-Vereinbarung zu treffen.