Aufgabenanalyse

Das Ziel, Benutzer und ihre Arbeit kennenzulernen, ist schwer umzusetzen, da
Entwickler häufig zunächst Kontakt zu den Auftraggebern haben. Diese sind aber in
der Regel nicht die Benutzer der zu entwickelnden Systeme, sondern deren Vorgesetzte.
Die Kunden eines Systems sind also vielfach nicht die Benutzer. Deswegen
wird teilweise von Endbenutzern gesprochen, um zu verdeutlichen, dass es sich um
diejenigen handelt, die unmittelbar mit einem System interagieren.
In vielen Fällen ist es schwierig, Vorgesetzte davon zu überzeugen, dass ein direkter
Kontakt mit den betroffenen Mitarbeitern erforderlich ist, denn die „Chefs“
sind oft der Meinung, selbst die Probleme zu kennen. Thimbleby [1990] beschreibt
in Kapitel 7, inwiefern Manager nicht imstande sind, die Arbeitsaufgaben ihrer Mitarbeiter
in vollem Umfang korrekt einzuschätzen. Zwar können die meisten Manager
gut einschätzen, welche Aufgaben ihre Mitarbeiter haben und welche Arbeitsergebnisse
sie von diesen bekommen, aber sie kennen oft die Schwierigkeiten auf
dem Weg zu diesen Ergebnissen nicht. Probleme und Schwierigkeiten, die umschifft
werden müssen, werden häufig Vorgesetzten nicht mitgeteilt („man spricht nur über
seine Erfolge“) oder von diesen verdrängt. Diese Unkenntnis der praktischen Probleme
ist eine entscheidende Ursache dafür, dass die alleinige Beteiligung der Vorgesetzten
auf der Seite der Benutzer nicht ausreichend ist.
Geis and Hartwig [1998] beschreiben einen derartigen Fall, wo bei der Entwicklung
einer Software die Benutzer durch einen Abteilungsleiter „repräsentiert“ wurden.
Dieser ging davon aus, dass das, was für ihn gut ist, für seine Mitarbeiter nicht
falsch sein kann. Im Ergebnis entstand ein gutes Management-Informationssystem,
das zwar auf ihn selbst zugeschnitten war, aber mit dem seine Mitarbeiter – zu seiner
Verwunderung – wenig anfangen konnten.
11.1 Historische Entwicklung: Vom Usability Engineering zum
User Interface Engineering
Zu den Gebieten, die das User Interface Engineering maßgeblich beeinflusst haben,
gehört die Luftfahrt, speziell die Entwicklung des Cockpits. Dass diese Entwicklung
auf die kognitiven und motorischen Fähigkeiten und Bedürfnisse der Piloten
zugeschnitten sein muss und dass diese Eigenschaft nur durch enge Zusammenarbeit
mit Piloten erreichbar ist, war frühzeitig klar. Butler [1996] erläutern dies unter
dem passenden Stichwort pilot-centered design.
11.2 Der Kontext der Softwareentwicklung
In diesem Abschnitt, werden einige typische Situationen betrachtet, in denen Benutzungsschnittstellen
entwickelt werden. Diese Betrachtung hilft zu verstehen, warum
selbst elementare Erkenntnisse der Mensch-Computer-Interaktion oft kaum umgesetzt
werden. Die Entwicklungskontexte bieten in unterschiedlichem Umfang Mög-
452