Aufgabenanalyse

Kapitel 11
User Interface Engineering: Einleitung
In diesem kurzen Kapitel wird der Prozess der Entwicklung von Benutzungsschnittstellen
auf einer hohen Ebene charakterisiert. Ziel dieses Prozesses ist es systematisch,
zuverlässig und in einer reproduzierbaren Form gut nutzbare, attraktive Benutzungsschnittstellen
zu entwickeln. Dabei werden wesentliche Phasen der Entwicklung
und typische Ergebnisse dieser Phasen beschrieben. Vergleiche mit der klassischen
Softwareentwicklung dienen dazu, die Besonderheiten des User Interface
Engineerings zu verdeutlichen und sollen Orientierung geben für eine integrierte
Entwicklung, die die Benutzungsschnittstelle und die anderen Teile einer Computerunterstützung
umfasst. So umfasst das User Interface Engineering auch Aktivitäten,
die für das Softwareengineering charakteristisch sind, wie die Analyse, die
Sammlung und Strukturierung von Anforderungen, die Erstellung von Spezifikationen
und in späten Phasen die Bewertung von Prototypen (Evaluierung). Im Unterschied
zum klassischen Softwareengineering sind diese Aktivitäten hier konsequent
auf die Benutzersicht fokussiert und nicht auf die technische Sicht (Daten, Bandbreite,
Performance, Funktionalität, . . . ). Am Beispiel der Evaluierung lässt sich
dieser Unterschied gut erklären. Während im klassischen Softwareengineering die
korrekte Funktionalität, die Performance und die Zuverlässigkeit im Vordergrund
stehen, werden im User Interface Engineering vor allem die Usability Faktoren Erlernbarkeit,
Behaltensleistung, Effizienz und Fehlerrate (der Benutzer) betrachtet.
Der in diesem Teil beschriebenen Methoden können auf verschiedene Weise zu
einem Prozess kombiniert werden. Auf diese Weise ist eine Anpassung an konkrete
Projektsituationen möglich. Nicht zuletzt aus Kostengründen ist es oft nötig, den
Umfang einzelner Phasen zu begrenzen bzw. Methoden einzusetzen, die mit geringerem
Aufwand verbunden sind. Insofern wird bei der Vorstellung der Methoden
das Aufwand-Nutzen-Verhältnis konsequent betrachtet. Die Gegenüberstellung von
Aufwand und Nutzen ist eine wichtige Argumentation und ist bereits 1994 durch
das Buch Bias and Mayhew [1994] populär geworden. Einige Methoden des User
Interface Engineering sind in verschiedenen Phasen oder sogar in allen Phasen anwendbar.
Diese werden in diesem übergreifenden Kapitel kurz vorgestellt. Beispielhaft
skizzieren wir zwei etablierte Prozesse, die szenariobasierte Entwicklung und
die kontextbasierte Entwicklung.
451

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

lichkeiten, User Interface Engineering systematisch zu betreiben. Das User Interface
Engineering ordnet sich in größere Softwareentwicklungsprozesse ein. Sie ist dabei
von einem organisatorischen Rahmen geprägt, der ein modernes User Interface Engineering
unterstützt oder eher behindert.
In vielen Organisationen, die heutzutage in erheblichem Umfang Benutzungsschnittstellen
entwickeln, spielte die User Interface-Entwicklung zuvor lange nur
eine geringe Rolle und dementsprechend sind die Abläufe oft nur unzureichend auf
das User Interface Engineering zugeschnitten. Die Softwareentwicklung ist oft von
Vorgehensmodellen geprägt, die nicht auf die Entwicklung von benutzergerechten
Systemen zugeschnitten sind. Auch die Strukturierung von Entwicklungsabteilungen
beeinflusst häufig die Entwicklung interaktiver Systeme – meist eher negativ als
positiv.
In vielen Organisationen wird die gesamte Softwareentwicklung nach dem traditionellen
Wasserfallmodell durchgeführt, das verschiedene Phasen enthält, wobei
allenfalls ein Zyklus von einer Phase zu der direkt davor liegenden Phase „zulässig“
ist. Das Wasserfallmodell und seine Realisierung entsprechend der Strukturierten
Analyse [DeMarco, 1978]. werden den Spezifika von interaktiven Systemen, insbesondere
der Notwendigkeit von häufigen Veränderungen, nicht gerecht. Tests der
Akzeptanz einer Bedienoberfläche und Auswertungen hinsichtlich der Effizienz der
Interaktion haben in diesem Modell keinen Platz.
GRUDIN hat drei unterschiedliche Szenarien der Softwareentwicklung identifiziert
und analysiert, wie in diesen unterschiedlichen Situationen benutzergerechte
Systeme entwickelt werden können [Grudin, 1991] (siehe Abb. 11.1):
1. Vertragsentwicklung nach einer Ausschreibung. Dieses Szenario tritt besonders
häufig in Zusammenhang mit öffentlichen Einrichtungen, z.B. Behörden oder
Krankenhäusern, auf: Ein Projekt wird in der öffentlichen Einrichtung spezifiziert.
Daraufhin wird in einer Ausschreibung eine Firma gesucht, die dieses
Projekt realisiert. Während die Benutzer in der Regel von Anfang an bekannt
sind, werden die Entwickler später bestimmt. Diese Vorgehensweise ist auch
in Firmen üblich und hat im Vergleich zu dem dritten Szenario durch Outsourcing-Aktivitäten
an Bedeutung gewonnen. 1
2. Produktentwicklung. Dieses Szenario tritt mittlerweile am häufigsten auf. Eine
Firma entwickelt ein Produkt und bringt es auf den Markt. Wer das Produkt
tatsächlich benutzt, stellt sich erst später heraus. Hier existiert also ein größeres
Maß an Unsicherheit über die Benutzer. Im Consumerbereich ist dies praktisch
das einzige Softwareentwicklungsszenario. Aber auch im professionellen
Umfeld wächst die Bedeutung dieses Szenarios – Software wird auf dem freien
Markt eingekauft. Teilweise wird dieses Szenario mit dem ersten so kombiniert,
dass die eingekaufte Standardsoftware durch entsprechende Berater so
konfiguriert und ggf. in Details erweitert wird, dass sie auf firmenspezifische
Besonderheiten bestmöglich eingestellt ist – dieses Szenario betrifft vor allem
betriebliche Standardsoftware.
1 Unter dem Stichwort Outsourcing werden die Aktivitäten zusammengefasst, die eine Auslagerung
von DV-Abteilungen zum Ziel haben.
453

3. Entwicklung in der eigenen Firma. Viele Projekte werden in Rechenzentren
oder Datenverarbeitungsabteilungen für andere Abteilungen einer Firma realisiert.
Bei diesen Projekten stehen die Entwickler und die Anwender von vornherein
fest. Dies ist oft in Banken und Versicherungen der Fall, die häufig über
Entwicklungsabteilungen von der Größe mittelgroßer Softwarehäuser verfügen.
Man konnte in den 90er Jahren teilweise den Eindruck gewinnen, dass dieses
Szenario rapide an Bedeutung verliert, weil verstärkt versucht wurde, Kosten
durch Auslagerungen, speziell ins Ausland, zu sparen. Dieser Trend hat sich
abgeschwächt, teilweise sogar umgekehrt und allein aus Gründen von Datenschutz
und Sicherheitsüberlegungen ist zu erwarten, dass dieses Szenario weiterhin
relevant bleibt.
Diese schematische Darstellung ist am ehesten anwendbar bei Projekten, die einen
konkreten Startpunkt haben, z.B. in Form einer Entscheidung, ein System zu modifizieren,
zu ersetzen oder gänzlich neu zu entwickeln, und ein konkretes Auslieferungsdatum.
Abb. 11.1: Verbreitete Szenarien der Software- und User Interface-Entwicklung.
Der Beginn der Balken (links) markiert, in welchem Stadium des Projekts Benutzer
bzw. Entwickler bekannt sind. Das (rechte) Ende der Balken symbolisiert das
Projektende, das zeitlich hinter der Systemauslieferung liegt. Dadurch wird berücksichtigt,
dass auf Benutzerreaktionen nach der Auslieferung reagiert wird. (Nach
[Grudin, 1991]).
Zwischen diesen drei Szenarien sind verschiedene Mischformen üblich. So kann
nach einer Vertragsentwicklung eines Systems eine Erweiterung in Richtung eines
Produktes entstehen, das auf den Erfahrungen (auch der Benutzer) mit dem ursprünglichen
System aufbaut. Eine Vertragsentwicklung kann auch ohne Ausschreibung
in einer sehr frühen Phase erfolgen.
Jede dieser drei Entwicklungssituationen hat die gegenwärtige Praxis der Entwicklung
interaktiver Systeme beeinflusst. Viele Firmen haben sich speziell auf eines
dieser Szenarien eingestellt.
454

11.2.1 Vertragsentwicklung
Die Vertragsentwicklung mit dem Fokus auf Methoden des Softwareengineerings
spielt insbesondere in den USA eine herausragende Rolle. Die bedeutenden Modelle
des Softwareengineerings, das Phasenmodell und das Wasserfallmodell, sind unter
maßgeblicher Mitwirkung der US-Behörden entstanden. Das Wasserfallmodell
ist teilweise noch heute die Grundlage für Ausschreibungen. Nachdem die Benutzerorganisation,
die Machbarkeit und den Nutzen eines Projekts überprüft und eine
Anforderungsanalyse erstellt hat, erfolgen separate Ausschreibungen für die Spezifikationsphase,
die Implementierung und die Wartung. Ein direkter Kontakt zwischen
Entwicklern und Benutzern ist so kaum möglich. Das Wasserfallmodell ist
von großen Softwareherstellern akzeptiert worden und bildet die Grundlage für die
Strukturierung der Entwicklungsabteilungen und für die Konzeption von Schulungen.
Diese Situation ist für ein modernes User Interface Engineering problematisch.
Die Entwickler von Benutzungsschnittstellen sind an Spezifikationsdokumente gebunden.
Ein direkter Kontakt zu den Benutzern kommt nicht zustande bzw. bleibt
ohne angemessene Konsequenzen, da in erster Linie ein Vertrag zu erfüllen ist. „Die
Spezifikationsdokumente stellen eine Wand zwischen Benutzern und Entwicklern
dar.“ [Grudin, 1991]. Die Einhaltung der Spezifikation hat die höchste Priorität.
11.2.2 Produktentwicklung
Die Produktentwicklung mit dem Fokus auf der Benutzungsschnittstelle hat an Bedeutung
gewonnen, da durch die geringen Hardwarekosten ein Massenmarkt entstanden
ist. Dennoch wird der größte Teil des Umsatzes mit Software nicht durch
den Verkauf an Privatkunden, sondern durch den Verkauf an Firmen erzielt. Beim
Verkauf an Firmen ist es in der Regel so, dass die „Entscheidungsträger“, die als
Kunden in Erscheinung treten, nicht die Benutzer sind. Falls ein System nur mühsam
zu bedienen ist, können interne Schulungen durchgeführt und Administratoren
mit der Konfiguration beauftragt werden. Schließlich kann ein Vorgesetzter seine
Mitarbeiter sogar dazu verpflichten, ein System zu benutzen. Von all diesen internen
Schwierigkeiten erfahren die Entwickler höchstens über Umwege.
Obwohl bei der Produktentwicklung, insbesondere für Privatkunden, der Benutzungsschnittstelle
mehr Aufmerksamkeit gewidmet wird, ist der direkte Kontakt
zwischen Entwicklern und Benutzern eher die Ausnahme. Die Entwicklungsfirmen
holen sich Rat bei Marktforschern und Beratern, die zumindest ein gutes Gefühl
für die Absetzbarkeit eines Produktes haben sollten. Bei der Absetzbarkeit spielen
zwar auch Aspekte der Benutzbarkeit eine Rolle. Diese indirekte Methode führt aber
kaum dazu, dass die Entwickler ein detailliertes Verständnis von Benutzbarkeitsproblemen
bekommen. Die grundsätzlichen Probleme mit diesem Vorgehen werden in
Abschn. 11.2.4 erläutert.
455

In den 80er Jahren ist das Bewusstsein gewachsen, dass bestimmte, generische
Aspekte die Benutzbarkeit fast aller Systeme beeinflussen: ein einheitliches Lookand-Feel
und die Einhaltung von Standards mindern den Lernaufwand. Untersuchungen
zur Strukturierung von Menüs (Zahl der Einträge und Hierarchieebenen)
und zur Benutzung von Farben, die sich auf die kognitiven Fähigkeiten der Benutzer
stützen, wurden in diesem Szenario mehr und mehr berücksichtigt. Allerdings
spielen die spezifischen Aspekte, die die Benutzbarkeit konkreter Systeme für spezifische
Aufgaben und bestimmte Benutzergruppen beeinflussen, nach wie vor eine
geringere Rolle.
Dennoch ist die Beachtung von Usability- und User Experience-Aspekten bei
dieser Form der Softwareentwicklung am stärksten ausgeprägt. Große Firmen, wie
APPLE, IBM, MICROSOFT und SUN, haben spezielle Gruppen gebildet, die sich
aus ausgewiesenen Experten zusammensetzen, um eine hohe Qualität ihrer Benutzungsschnittstellen
sicherzustellen.
Weiterentwicklung eines existierenden Produkts.
Die Entwicklung eines gänzlichen neuen Produkts ist eher die Ausnahme. Die meisten
Projekte zielen darauf ab, eine neue Version eines existierenden Produkts zu
entwickeln. In Bezug auf das User Interface Engineering ist dies oft eine schwierige
Situation, weil Kompatibilität zu der im Markt existierenden Software ein wesentlicher
Faktor ist – tendenziell ist der Spielraum für Verbesserungen in Bezug
auf Erlernbarkeit, Effizienz und Attraktivität stärker eingeschränkt. Allerdings zeigt
sich mittlerweile bei vielen Produkten, dass die mehr oder weniger inkrementelle
Weiterentwicklung, primär durch Hinzufügen weiterer Features, an Grenzen stößt.
Radikal neue Konzepte, wie die Ribbons in MICROSOFT OFFICE WORD, sind teilweise
nötig – trotz des damit verbundenen Lern- und Umstellungsaufwandes. Insofern
sollten Entwickler und User Interface-Spezialisten nach Gelegenheiten suchen,
echte Innovationen in neue Versionen zu integrieren.
11.2.3 Entwicklung innerhalb einer Firma
Die Softwareentwicklung innerhalb einer Firma mit dem Fokus auf der Beteiligung
der Benutzer ist die älteste überhaupt. Die Entwickler der „ersten Stunde“ waren
die Benutzer ihrer eigenen Systeme. Später entwickelten sie Software für ihre Kollegen
in anderen Abteilungen. In DV-Abteilungen und Rechenzentren großer Banken,
Versicherungen und anderer Konzerne entsteht immer noch ein Großteil der
in diesen Unternehmen angewendeten Software. Forschungs- und Entwicklungsabteilungen
entwickeln Software für andere Unternehmensbereiche, wobei ein kommerzieller
Vorteil angestrebt wird. Beispiele dafür finden sich unter anderem in der
Automobilindustrie. So werden in Autokonzernen zunächst neue Formen der computergestützten
Wartungs- und Montageunterstützung erprobt, die auf die Typen
456

des jeweiligen Konzerns zugeschnitten sind. Diese Form der Softwareentwicklung
kommt auch Geheimhaltungsaspekten zugute. Die Firmen müssen externen Personen
gegenüber keine Details von organisatorischen und logistischen Abläufen preisgeben.
Es gibt auch aktuell gute Gründe dafür, betriebliche Software in der eigenen
Firma entwickeln zu lassen. Nur diese Form der Softwareentwicklung ermöglicht
es, dass detailliert auf die Bedürfnisse und Besonderheiten der Benutzer und ihrer
organisatorischen Einbettung, speziell auch die Firmenkultur eingegangen wird.
Insbesondere ein vertieftes Verständnis der aktuellen Prozesse, der Probleme und
„Workarounds“, ist nur bei einer Entwicklung in der eigenen Firma zu erwarten [?].
Die Vertragsenwicklung (Abschn. 11.2.1) ist dagegen darauf angelegt, relativ generische
Softwaresysteme in Details anzupassen; tendenziell gelingt die Anpassung
aber nur teilweise. Daher fehlt auf der einen Seite häufig benötigte Funktionalität;
andererseits wird oft vieles angeboten, was nicht benötigt wird, so dass die Systemnutzung
unnötig kompliziert wird.
In Bezug auf die Beteiligung von Benutzern ist die Entwicklung in der eigenen
Firma ideal: Benutzer und Entwickler stehen von Anfang an fest. Die Entwickler
sind – im Gegensatz zur Entwicklung für den Massenmarkt – darauf angewiesen,
dass ihre Software in einem definierten Anwenderkreis akzeptiert wird. Dadurch
sind Entwickler in dieser Situation auch oft erstmalig mit Benutzbarkeitsproblemen
konfrontiert worden, die in anderen Softwareentwicklungsszenarien den Benutzern
in der Regel verborgen bleiben. Eine partizipatorische Entwicklung (vgl.
Abschn. 11.6) ist in diesem Szenario am leichtesten zu verwirklichen. Dazu wird ein
Mitarbeiter innerhalb der eigenen Firma zeitweilig in eine andere Abteilung versetzt
oder arbeitet dort auf Teilzeitbasis. Dennoch wird auch hier häufig eine „Wand“ in
Form von starren Spezifikationen errichtet.
Interessanterweise wird allgemein anerkannt, dass diese Form der Softwareentwicklung
in Europa besser funktioniert als in Amerika [Grudin, 1991]). Die frühe
und intensive Beteiligung von Benutzern wird hier also als eine Form der betrieblichen
Mitbestimmung, als eine Frage nach Demokratie auf Betriebsebene angesehen.
Die skandinavischen Länder, in denen ein hohes Maß an Konsens über innerbetriebliche
Softwareentwicklung angestrebt wird, werden hier als Vorbild angesehen.
Die gründliche Analyse von Poltrock and Grudin [1994] ist zwar bereits relativ
alt; aktuelle Gespräche bestätigen aber, dass in vielen Organisationen nach wie vor,
direkte Kontakte zwischen Benutzern und Entwicklern rar sind und sogar durch
organisatorische Vorgaben verhindert werden.
11.2.4 Wo sind die Usability und die User Experience angesiedelt?
Idealererweise wird das User Interface Engineering in speziellen Abteilungen durchgeführt,
die sich ganz auf die damit verbundenen komplexen Prozesse konzentrieren.
Die Realität in vielen Organisationen sieht allerdings anders aus. Für die Anforderungen
an Neuentwicklungen sind oft Marketingexperten oder Produktmanager
verantwortlich. Inwiefern Marketingexperten regelmäßig mit dieser Aufgabe über-
457

fordert sind, wird in [Poltrock and Grudin, 1994] eindrucksvoll beschrieben. Die
Kernkompetenz von Marketingexperten ist es, etwas zu bewerben und zu verkaufen,
ggf. clevere Strategien der Bündelung von Hard- und Software zu konzipieren. Die
eher von Psychologen zu erwartende Kompetenz, Benutzer effizient zu befragen,
Bedürfnisse zu erahnen, durch gezielte Nachfragen zu verifizieren oder zu falsifizieren
und diese Erkenntnisse so zu kommunizieren, dass die User Interface Entwicklung
davon profitiert, ist bei Marketingexperten nicht zu erwarten. Produktmanager
haben eine weitreichende und übergreifende Verantwortung für ein Produkt, wobei
Features und Aspekte der Zuverlässigkeit und Performance dabei als mindestens
genau so wichtig gelten wie die Qualität des User Interface. Auch Produktmanager
sind also in der Regel nicht die optimalen Führungskräfte für das User Interface Engineering;
insbesondere fehlt ihnen meist eine Ausbildung, die sie dazu befähigen
würde.
In den späteren Phasen der Entwicklung werden Prototypen getestet, verfeinert,
„abgerundet“ und schließlich fertig gestellt. Die Verantwortung dafür liegt meist
in Qualitätssicherungsgruppen und -abteilungen. Deren Kernkompetenz liegt in der
Regel darin, das korrekte Funktionieren der Software sicherzustellen, die Einhaltung
der Spezifikation zu prüfen, ggf. die Performance zu bewerten und zu verbessern.
In speziellen Anwendungsbereichen ist mittlerweile eine formale Prüfung und
Zertifizierung von Software erforderlich, etwa nach ISO 9001 oder nach dem Medizinproduktegesetzt.
In diesen Fällen ist die Vorbereitung und Durchführung dieser
Zertifizierung die wichtigste Aufgabe der Qualitätssicherung. Erwartet wird dabei,
dass durch diese Qualitätssicherung auch die Usability gesichert wird – dies ist aber
im Allgemeinen nicht der Fall, weil die Kompetenzen, die z.B. nötig sind, um Usability
Tests zu konzipieren, durchzuführen und auszuwerten, sich erheblich von den
anderen Anforderungen an die Qualitätssicherung unterscheiden.
11.2.5 Zusammenfassung
Dieser Abschnitt hat verschiedene Szenarien der Softwareentwicklung beleuchtet.
Alle drei Szenarien sind vor allem in größeren Firmen zu finden. Organisatorische
Rahmenbedingungen fördern oder unterdrücken den frühzeitigen und intensiven
Kontakt zu Benutzern, der für die Entwicklung interaktiver Systeme wesentlich ist.
Kleinere Firmen sind wesentlich flexibler und weniger stark durch traditionelle Organisationsstrukturen
eingeschränkt. Die Kenntnis dieser Zusammenhänge und das
Bewusstsein für organisatorische Probleme macht es teilweise möglich, Auswege
zu finden.
Poltrock and Grudin [1994] fassen ihre Analyse in zwei repräsentativ ausgewählten
professionellen Softwareentwicklungsorganisationen so zusammen: die Erfordernisse
des User Interface Engineering und die Organisation der Softwareentwicklung
passen häufig nicht zusammen. Erfolgreiches User Interface Engineering erfordert
häufige und intensive Kommunikation. Die Häufigkeit und Qualität der Kommunikation
hängt aber stark von organisatorischen Strukturen ab. Organisatorische
458

Veränderungen wären die Voraussetzung für erfolgreiches User Interface Engineering.
Für jüngere Firmen, die auf die User Interface-Entwicklung spezialisiert sind,
gilt diese Aussage sicher nicht – in anderen Firmen, teilweise auch jüngeren Firmen
ohne Fokus auf User Interface-Entwicklung, sind die genannten Probleme immer
noch verbreitet.
11.3 Phasen der Entwicklung
Jede User Interface-Entwicklung sollte mit einer gründlichen Analysephase beginnen,
in der
• Benutzer und ihre Ziele, Wünsche und Präferenzen,
• Aufgaben sowie
• typische Nutzungskontexte
sorgfältig analysiert werden. Benutzer und andere für die Entwicklung wesentliche
Personen müssen dazu identifiziert, kontaktiert, beobachtet bzw. befragt werden.
Dabei gibt es zahlreiche Varianten, wie z.B. Gruppeninterviews, in denen eine
kleine Gruppe von Benutzern befragt wird und erhofft wird, dass durch das entstehende
Gespräch tiefer gehende Informationen erlangt werden als in Einzelgesprächen.
Gespräche aufzuzeichnen bzw. Beobachtungen zu filmen, führt zu konkreten
und umfassenden Informationen; ist allerdings mit Datenschutz- und Sicherheitsproblemen
verbunden.
Welche Methoden konkret zum Einsatz kommen, wie sie ggf. kombiniert werden,
welche Vorbereitung erforderlich ist und wie die Ergebnisse ausgewertet werden,
wird in Kapitel 12 erläutert. Hier sei lediglich gesagt, dass für diese Phase relativ
viel Zeit eingeplant werden muss, weil eine gründliche inhaltliche und organisatorische
Vorbereitung nötig ist, damit diese Maßnahmen zu nützlichen Ergebnissen
führen. Zudem ist es wichtig, Experten mit einschlägiger Erfahrung an diesem Prozess
zu beteiligen.
Die zu lösenden Aufgaben müssen identifiziert und abgegrenzt werden. Dabei
darf nicht nur die Standardvorgehensweise erfasst werden, sondern auch der Umgang
mit Problemen und Sonderfällen, die einer Spezialbehandlung bedürfen. Zunächst
wird so viel wie möglich Information gesammelt werden. Strukturiert, fokussiert
und priorisiert, wird in einer späteren Phase. Im Ergebnis dieser Phase sollte
festgehalten werden,
• welche Ziele aus Anwendersicht im Vordergrund stehen,
• welche Aufgaben dabei erledigt werden müssen,
• in welchem Zusammenhang diese Aufgaben stehen,
• welche Aufgaben Priorität haben, z.B. weil sie besonders häufig sind oder besonders
kritisch,
• welche Nutzungskontexte relevant sind und
• welche Rahmenbedingungen sich daraus ergeben.
459

Bezüglich der Aufgaben muss verstanden werden,
• wie diese Aufgaben bisher gelöst wurden,
• was daran als gut wahrgenommen wird und
• welche Schwachstellen existieren
Während Schwachstellen als Ansätze möglicher Verbesserungen oft sehr gut analysiert
werden, wird oft vernachlässigt, was sich aus Sicht der Benutzer bewährt hat.
Dies ist sehr kritisch, denn wenn dieses Wissen nicht in die Entwicklung einfließt,
ist es wahrscheinlich, dass zwar existierende Schwachstellen durch die Entwicklung
behoben werden, aber dafür – aus Sicht der Benutzer – neue Schwachstellen entstehen,
weil Bewährtes durch wenig ausgereifte Funktionen ersetzt werden, die zudem
neu erlernt werden müssen. Mögliche grafische Repräsentationen der abgeschlossenen
Aufgabenanalyse sind:
• Workflowdiagramme (Schemazeichnungen, die verdeutlichen, wie einzelne Aktivitäten
zusammenhängen, insbesondere auch welche Varianten existieren und
wovon die Auswahl dieser Varianten abhängt),
• Aufgabenmodelle (Beschreibungen der hierarchischen Zerlegung von Aufgaben
in Teilaufgaben) und
• Performance-Modelle (Aufgabenmodelle, die um Zeiten angereichert sind, die
erfahrene Benutzer dafür benötigen).
Die Analysephase ist besonders herausfordernd, wenn grundsätzlich verschiedene
Benutzergruppen zu beachten sind und insofern auch unterschiedliche Mengen
von Aufgaben und Aktivitäten zu beachten sind. Beim Nachdenken über das zu
lösende Problem entstehen naturgemäß auch Ideen, wie das Problem zu lösen ist.
Diese sollten stichpunktartig festgehalten werden. Der Versuchung, einzelne Lösungsideen
in dieser Phase auszuarbeiten, muss man widerstehen. Ehe Anforderungen
präzise festgelegt sind, ist eine Konzeptentwicklung nicht sinnvoll und außerdem
sollte über Lösungsmöglichkeiten breit und offen diskutiert werden – eine
vorschnelle Konzeptentwicklung für einen Ansatz ist dabei kontraproduktiv.
Anforderungen.
Aus der Analyse ergeben sich Anforderungen an das zu entwickelnde System. Diese
sind nach Prioritäten zu ordnen, so dass für alle an der Entwicklung beteiligten
deutlich wird,
• welche Anforderungen das Minimum eines sinnvollen und nutzbaren Systems
darstellen,
• was darüber hinaus dringend erwünscht wird und
• was schließlich nützlich ist, aber doch von geringerer Bedeutung und damit evtl.
eher in den Fokus eines Folgeprojektes rücken könnte.
Selbst wenn eine solche Anforderungsliste auf einer sorgfältigen Analyse beruht,
ist nicht zu erwarten, dass die Anforderungsliste in einem größeren Projekt konstant
460

leibt. Sowohl die Anforderungen an sich ändern sich (typischerweise kommen weitere
hinzu) als auch Prioritäten verschieben sich. Anforderungen durch skizzenhafte
Lösungen zu veranschaulichen, ist sehr hilfreich, um möglichst früh eine weitgehend
vollständige Anforderungsliste zu erzeugen.
Um die Bedeutung der Analysephase und der Anforderungsdefinition zu verdeutlichen,
ist ein Vergleich mit einem Hausbau hilfreich. Dabei ist den allermeisten
Bauherren klar, dass Anforderungen an die Raumaufteilung, an die Materialien,
an die Heizung bis hin zu Details wie benötigten Steckdosen und Internetanschlüssen
frühzeitig und präzise geklärt werden müssen. Spätere Veränderungen sind sehr
zeit- und kostenaufwändig.
In Kapitel 12 wird die Definition von Anforderungen präziser beschrieben. Es
zeigt sich dabei, dass der Schritt von der Analyse zu einer Anforderungsdefinition
nicht unbedingt naheliegend ist – die Anforderungen müssen also nicht nur gesammelt
werden, sondern in einem kreativen Prozess synthetisiert werden, wobei neben
den Wünschen von Auftraggebern bzw. Kunden und den Bedürfnissen von Benutzern
technische Realisierungsmöglichkeiten angemessen zu berücksichtigen sind.
Spezifikation und Design.
Eine abgestimmte Anforderungsliste ist Ausgangspunkt für den Entwurf geeigneter
Lösungen. Diese Phase erfordert in besonderer Weise Kreativität – idealerweise
werden hier Personen aktiv, die einen Background (eine Ausbildung oder substanzielle
Erfahrungen) im Bereich Design aufweisen, z.B. Interaction Designer.
Vergleicht man die Softwareentwicklung wiederum mit dem Hausbau, dann ist
hier vor allem der Architekt gefragt – ein Experte, der Techniken beherrscht, wie
Entwürfe erstellt, visualisiert und damit diskutiert werden können, der viele Umsetzungsvarianten
kennt und auch grob abschätzen kann, mit welchem Aufwand die
Umsetzung der Varianten verbunden wäre.
Wichtig ist, dass mehrere Entwürfe für wichtige Aspekte eines Systems vorliegen
und somit Vor- und Nachteile dieser Entwürfe diskutiert werden können, oft mit
dem Ergebnis dass Teile verschiedener Entwürfe neu kombiniert werden sollten.
Der Entwurf betrifft insbesondere:
• die Strukturierung von Informationen, z.B. beim Entwurf von Websites,
• die Navigation innerhalb dieses Informationsraums,
• die Layoutgestaltung,
• die visuelle Gestaltung, in Bezug auf den Einsatz von Fonts, Farben und häufig
benötigten Symbolen
Für den Entwurf sind sowohl textuelle Beschreibungen als auch semi-formale
grafische Notationen geeignet. Darüber hinaus spielen auch traditionelle Skizzen
eine wichtige Rolle. Wesentlich ist in dieser Phase, dass sich die Entwickler nicht
zu früh, auf eine (bekannte, traditionelle) Variante festlegen, sondern tatsächlich den
Gestaltungsspielraum explorieren. Wenn Entscheidungen über Designvarianten fallen,
ist es wichtig, diese Entscheidungen und die Begründungen dafür sorgfältig zu
461

dokumentieren. Entwurfsentscheidungen müssen zunächst in Bezug auf die übergeordneten
Aspekte eines Systems fallen; ein späterer Detailentwurf betrifft z.B.
Dialoge, Formulare, Toolboxen und andere Bestandteile. Ob jeder einzelne Dialog
komplett spezifiziert wird, ehe die Entwicklung beginnt, oder ob beispielhaft einzelne
Elemente spezifiziert werden und für die anderen Bestandteile lediglich Guidelines
festgelegt werden, ist von Projekt zu Projekt unterschiedlich und natürlich auch
von den Kompetenzen der Entwickler abhängig.
Die Methoden, mit denen ein derartiger Entwurf durchgeführt werden kann, einschließlich
der dabei möglichen und sinnvollen Computerunterstützung werden in
Kapitel ?? detailliert vorgestellt und an Beispielen erläutert.
Ähnlich wie in der traditionellen Softwareentwicklung muss auch im User Interface-
Engineering eine Spezifikation erfolgen, die für die Entwickler möglichst präzise
festlegt, welche Funktionalität und welche Benutzungsschnittstelle realisiert werden
soll. Spezifikation und Design entstehen oft parallel. Im User Interface Engineering
werden häufig informelle Spezifikationsmethoden genutzt, z.B. Skizzen von Dialogen
und Formularen, die das Layout grob charakterisieren. Formale Spezifikationsmethoden
sind z.B. Zustandsübergangsdiagramme, die in einer festgelegten Notation
das Verhalten einer Benutzungsschnittstelle beschreiben. Die Eindeutigkeit der
formalen Spezifikation ist ein wichtiger Vorteil; allerdings erfordert die Nutzung
dieser Methode sowohl bei der Erstellung durch den Autor als auch bei der Nutzung
durch Entwickler viel Erfahrung, insbesondere weil häufig sehr umfangreiche
Diagramme entstehen.
Umsetzung der entworfenen Lösungen.
Die Umsetzung von Lösungen erfolgt in verschiedenen Schritten. Zunächst werden
Prototyping-Methoden genutzt, um für wichtige Teilprobleme detaillierte Lösungsvorschläge
zu erarbeiten, die zunächst im Entwicklerteam und später mit Kunden
bzw. Benutzern diskutiert werden können. Visuelle Aspekte, z.B. das Layout einer
Webseite aber auch dynamische Aspekte, wie das Verhalten bei bestimmten Aktionen
sind dabei von Interesse.
Das Feedback der Benutzer dient dabei dazu, festzustellen, welche Aspekte der
Lösung als gut eingeschätzt werden und was als unbefriedigend eingeschätzt wird.
Konkrete Verbesserungsvorschläge werden Benutzer in der Regel nicht präsentieren
können, aber Anhaltspunkte für die Notwendigkeit von Verbesserungen. Die
eigentliche Produktentwicklung erfolgt dann mit professionellen Softwarewerkzeugen,
wobei hier die User Interface-Tools bedeutsam sind. Diese unterstützen in der
Regel die Erstellung von Menüs, Dialogen, Formularen und Icons und geben auch
gezielte Unterstützung dabei, das gewünschte Verhalten zu spezifizieren.
Die Erfahrung mit Prototypen kann auch für die Überarbeitung und Konkretisierung
einer Spezifikation genutzt werden. Ein Prototyp kann sogar wesentlicher
Bestandteil einer Spezifikation sein – die mit dem Prototyp definierte Benutzungsschnittstelle
soll effizient realisiert werden.
462

Evaluierung von Lösungen.
Evaluierung bedeutet, dass existierende Lösungen systematisch erprobt werden und
das Feedback von Experten oder Benutzern eingeholt wird. Systematisch bedeutet
dabei, dass es bei weitem nicht ausreicht, Benutzer mit einem neuen System zu konfrontieren
und nach ihrer Meinung zu fragen. Statt dessen muss sorgfältig überlegt
werden,
• welche Teile des Prototypen bewertet werden,
• nach welchen Kriterien die Bewertung vorgenommen wird,
• wieviel Testpersonen benötigt werden und
• und wie diese ausgewählt werden.
Bei der Evaluierung spielen die allgemeinen Usability-Kriterien wie Aufgabenangemessenheit,
Erlernbarkeit und Effizienz sowie User Experience-Kriterien eine wichtige
Rolle. Diese müssen aber auf spezielle Testaufgaben zugeschnitten und konkretisiert
werden. Zudem müssen sie ausgehend von den Projektzielen und den Ergebnissen
der Analyse geeignet gewichtet werden. Grundsätzlich sollte die Phase des
Requirement Engineering Ergebnisse generieren, die für die Bewertung (Wie gut ist
eine bestimmte Anforderung erfüllt?) unmittelbar relevant sind. Evaluierung sollte
in verschiedenen Stadien erfolgen:
• Die formative Evaluierung dient während der Entwicklung dazu, Verbesserungsvorschläge
zu generieren, um das Produkt entsprechend zu optimieren.
• Die summative Evaluierung am Ende einer Entwicklung dient dazu, den erreichten
Stand aus Benutzersicht zu dokumentieren.
Wie in den anderen Phasen kommen auch hier zahlreiche Methoden zum Einsatz;
insbesondere Methoden, die sehr ähnlich sind zu denen, die in der Analysephase
eingesetzt werden. Benutzer werden also wiederum befragt und beobachtet,
um z.B. zu verstehen, wie schnell und mit welchem Erfolg sie die Bedienung des
Programms erlernen, wie schnell sie Informationen auf Webseiten lokalisieren können,
wie effizient sie wichtige Bedienhandlungen durchführen können und welche
Fehler ihnen unterlaufen.
Je nach Projektziel kann es wichtig sein, auch die User Experience im Rahmen
einer Evaluierung zu erfassen. Häufig werden dabei auch quantitative Daten erhoben
und Methoden der Statistik müssen eingesetzt werden, um die Daten auszuwerten
und die Aussagekraft der Auswertung einzuschätzen. Langfristige Studien mit
einzelnen Benutzern, die eine Art Tagebuch führen, sind oft hilfreich, um Nutzungskontexte
gut zu verstehen. Mit Fragebögen, die über das Internet versandt werden,
erreicht man oft relativ schnell eine größere Zahl an Benutzern. Neben der empirischen
Evaluierung mit Benutzern werden dabei auch heuristische Evaluierungen
mit Experten betrachtet, die aufgrund ihrer Erfahrung Probleme präzise beschreiben,
klassifizieren und priorisieren können. Beide Arten der Evaluierung ergänzen
sich und werden daher oft in Projekten kombiniert [Butler, 1996].
Methoden der Evaluierung und ihre Anwendung werden in Kapitel ?? vorgestellt
und erläutert. Dabei werden auch viele praktische Aspekte, wie die Auswahl und
Motivation von Testpersonen und Fragen der statistischen Auswertung behandelt.
463

Iterative Entwicklung.
Die bisherige Beschreibung in diesem Abschnitt könnte den Eindruck eines strikt
linearen Prozesses vermitteln, in dem die Ergebnisse einer Phase (endgültig) vorliegen
müssen, ehe die nächste Phase beginnt. Dieser Eindruck ist unzutreffend; die
Entwicklung vollzieht sich iterativ und es ist nicht selten nötig, nach einer Evaluierung
die Anforderungsliste zu überarbeiten und nach neuen Lösungsmölichkeiten
für einzelne Aspekte zu suchen. Insbesondere sollte frühzeitig evaluiert werden, so
dass ausreichend Zeit verbleibt, um die Ergebnisse der Evaluierung in der weiteren
Entwicklung zu berücksichtigen.
Skalierbare Entwicklungsmethoden.
Jedes Projekt ist in Bezug auf seine Laufzeit und seine Kosten begrenzt. Die Einhaltung
dieser Rahmenbedingungen ist entscheidend und daher muss bei dem beschriebenen
Entwicklungsprozess auch bedacht werden, wie die einzelnen Phasen
ggf. abgekürzt werden können, welche ressourcensparenden Methoden zum Einsatz
kommen sollten. Die einzelnen Kapitel dieses Teils tragen diesem Aspekt Rechnung
und diskutieren mögliche Kompromisse zwischen Qualität und Aufwand. Tendenziell
sollten auch knappe Ressourcen nicht dazu führen, dass eine Phase komplett
übersprungen wird und tendenziell ist es nicht zu empfehlen, die Analysephase zu
stark zu begrenzen. Die Erfahrungen mit gescheiterten Projekten zeigen zu oft, dass
eine nur rudimentäre und unzureichende Analyse Hauptursache dafür ist, dass ein
Softwaresystem praktisch kaum einsetzbar ist.
11.4 Szenariobasierte Entwicklung
Die szenariobasierte Entwicklung ist eine Methode, bei der in allen Phasen durchgängig
und konsequent Szenarien natürlichsprachige Texte als Beschreibungsmethode
eingesetzt werden. Die Beschreibungen fokussieren auf Handlungen und Aktivitäten
in ihrem Kontext. Obwohl diese Methode bereits seit langem bekannt ist,
ist sie erst in den letzten Jahren stark verbreitet worden. Dazu haben unter anderem
die detaillierten Beschreibungen konkreter Anwendungen beigetragen [Carroll
and Rosson, 2002]. Neuere MCI-Lehrbücher behandeln die szenario-basierte Entwicklung
ebenfalls. Die sehr praxisorientierte Beschreibung in [Benyon et al., 2005]
ist besonders zu empfehlen. Die Popularität von Szenario-basierten Entwicklungen
ergibt sich auch dadurch, dass sie sich gut mit modernen Softwareentwicklungsprozessen,
insbesondere der agilen Softwareentwicklung kombinieren lässt [Obendorf
and Finck, 2007].
Szenarien charakterisieren typische Benutzer in ihrem jeweiligen Nutzungskontext
und ihre Motive bei der Durchführung von Bedienhandlungen. Neben den unmittelbaren
Benutzern werden oft auch andere Personengruppen charakterisiert, die
464

an der genutzten Technologie ein Interesse haben, wie z.B. Eltern und Lehrer bei
einem Lernprogramm für Schulkinder. Die Charakterisierung betrifft sowohl die
Analyse der aktuell eingesetzten Technologie (Ist-Szenarien) als auch die avisierte
Nutzung der neu zu entwickelnden Technologie (Soll-Szenarien).
Beispiel 1. Eine Bauleiterin betrachtet auf ihrem Laptop Skizzen und Zeitpläne
eines umfassenden Bauprojekts. Sie arbeitet dabei im Freien und bei relativ hoher
Lärmbelastung. Mit ihrem Handy macht sie Fotos, um den aktuellen Stand zu
dokumentieren. Die schnelle Nutzung dieser Fotos am Laptop ist für sie wichtig.
Die Funktion zum Fotografieren hat sie zunächst nur schwer gefunden. Am Anfang
fiel es ihr auch schwer, die erstellten Bilder auf dem Handy zu finden. Außerdem
braucht sie eine schnelle Internetanbindung, um mit ihrem Büro zu kommunizieren.
Beispiel 2. Ein Fußballfan möchte auf einer Zugreise die gerade laufenden Spiele
verfolgen. Er möchte über den Stand auf allen Plätzen informiert sein, aber auch
kurze Videosequenzen von spannenden Szenen betrachten. Da die Saison fast zu
Ende ist, interessiert er sich auch für die jeweils aktuelle Tabelle und will auch
das Restprogramm der Spitzenmannschaften betrachten, um zu spekulieren, wie die
Saison zu Ende gehen könnte.
Die informelle natürlichsprachige Form unterstützt den Dialog mit Anwendern
sehr gut. Mit dieser Beschreibungsmethode ist eine Analyse und Spezifikation in
verschiedenen Detaillierungsgraden möglich. Die Szenarioautoren können also an
wichtigen Stellen bewusst ins Detail gehen, z.B. hinsichtlich möglicher Lösungsvarianten
und an anderen Stellen bewusst abstrakter formulieren. Szenarien dienen
auch der Evaluierung, in dem Sinne, dass die Testaufgaben dabei entsprechend der
Szenarien gewählt werden.
Wie alle Entwicklungsprozesse hat diese Methode Vor- und Nachteile. Offensichtlich
ist sie auf gut verbalisierbare Aspekte der User Interface-Entwicklung fokussiert;
ggf. müssen die Szenarien durch Screenshots, Storyboards oder andere
visuelle Komponenten ergänzt werden. Diese Ergänzung ist sowohl in der Analysephase
sinnvoll, z.B. um Fotos von einem Arbeitsplatz und wichtigen Artefakten zu
integrieren als auch in der Spezifikations- und Entwurfsphase.
Der informelle Charakter ermöglicht insbesondere bei Szenarien auf einer hohen
Ebene breiten Interpretationsspielraum. Das ist bei der Implementierung teilweise
hinderlich. Zudem sind Softwareentwickler geschult darin, formale Notationen zu
interpretieren – Szenariobeschreibungen enthalten Informationen, die für die Implementierung
redundant sind. Insofern sind für die Kommunikation der Entwickler oft
Ergänzungen durch andere Beschreibungsformen sinnvoll.
Schließlich erfordert die szenariobasierte Entwicklung eine sehr sorgfältige Verwaltung
der entstehenden Dokumente, ihrer Entstehungsgeschichte und -zusammenhänge.
Entsprechend des durchgehenden Charakters wird in den folgenden Kapiteln immer
wieder darauf Bezug genommen, wie Szenarien in den unterschiedlichen Phasen
zweckmäßig eingesetzt werden können.
465

11.5 Contextual Design
Contextual Design ist eine weitere benutzerzentrierte Entwicklungsmethode, die
ebenfalls alle genannten Phasen umfasst. Sie wurde von Holtzblatt and Beyer [1998]
vorgestellt und basiert auf den langjährigen Erfahrungen der Autoren als Usability-
Consultants. Aufgrund der Flexibilität der Methode ist sie breit anwendbar und wird
tatsächlich auch häufig genutzt.
Die besondere Betonung liegt auf dem Kontext. Es wird also sorgfältig durch entsprechende
Beobachtungen und Befragungen der organisatorische und soziale Kontext
analysiert, in den ein technisches System eingebettet werden soll. Die Arbeitsumgebung
und die Kooperation mit anderen Benutzern spielen dabei eine wichtige
Rolle. Die besonderen Anforderungen an die Unterstützung der Kooperation von
Benutzern hat zu einer Reihe spezieller Entwicklungen unter dem Stichwort computer
supported cooperative work geführt (siehe [Gross and Koch, 2007] für eine
aktuelle Übersicht).
Die Analysephase ist dabei besonders stark ausgeprägt. Dabei werden u.a. auch
Artefakte hinsichtlich ihrer Nutzung analysiert. Beispiele dafür sind Kalender, Notizbücher
und Arbeitspläne. Einige Analyseergebnisse wurden speziell auf diese
Methode zugeschnitten. Interessant ist die Haltung der Autoren in Bezug auf die
Analysephase: sie betrachten die Benutzer als Meister und die Usability-Experten
als Lehrlinge, die sich von den Meistern ihre Domäne erklären lassen (ohne dabei
das Niveau der Meister zu erreichen). Der große Respekt vor Benutzern ist dabei
spürbar und sollte tatsächlich das Verhältnis zu ihnen prägen.
In den folgenden Kapiteln wird es immer wieder Verweise auf das contextual
design geben, um Empfehlungen von HOLTZBLATT und BEYER zur Nutzung einzelner
Methoden des User Interface-Engineerings zu integrieren.
11.6 Partizipative Entwicklung
Partizipatorisches Design 2 ist eine Entwicklungsmethode, bei der das Einbeziehen
von Benutzern einen besonderen Schwerpunkt einnimmt [Suchman, 1988]. Im Unterschied
zu anderen User Interface-Engineering-Prozessen werden hier einzelne
Benutzer als aktive Beteiligte, als Mitentwickler, der Entwicklung angesehen und
nicht nur als passive Informationsquellen, die zu gegebener Zeit gewisse Fragen beantworten.
Die „Mitsprache“ der Anwender hat aber einen für die Akzeptanz und
den Erfolg eines Systems wesentlichen Grund: Sie fühlen sich einbezogen, an der
Entwicklung beteiligt; ihnen wird nicht einfach ein System aufgedrängt, sondern sie
können aktiv mitgestalten. Umgekehrt kann die Nichteinbeziehung von Benutzern
im schlimmsten Fall dazu führen, dass sie ein System regelrecht boykottieren, weil
sie eventuell befürchten, dass das System sie ersetzen soll [Shneiderman, 1997a].
Das Einbeziehen von Benutzern ermöglicht es also auch, Ängste abzubauen. Was
2 Diese Methode wird teilweise auch kooperatives Design genannt.
466

im Detail unter Partizipatorischem Design verstanden wird, ist unterschiedlich und
reicht bis zur aktiven (Software-)Entwicklung durch Benutzer.
Partizipatorisches Design betont ein frühes gemeinsames Erarbeiten von Entwürfen
zwischen Entwickler und Anwender. Dabei wird (mindestens) ein Benutzer
in das Entwicklungsteam integriert. Die Benutzer im Entwicklungsteam sind dabei
weitestgehend gleichberechtigt und können jederzeit Einfluss auf die Entwicklung
nehmen. Der ungehinderte Zugang zu Entwicklungsdokumenten, wie Anforderungsdefinitionen,
Spezifikationen und Entwürfen, ist dabei wesentlich. Benutzerinteressen
haben dadurch einen hohen Stellenwert. Mit der partizipatorischen Entwicklung
ist auch eine grundsätzliche Haltung zu demokratischer Mitbestimmung
in Firmen und Organisationen verbunden [Grudin, 1991]. Besonders deutlich wird
dies in dem Buch „Computers and Democracy“ [abdPelle Ehn and Kyng, 1987].
Good [1992]beschreiben das Partizipatorische Design sehr ausgewogen anhand
von mehreren Fallstudien aus dem Bereich Virtual Reality. So wird ein Projekt beschrieben,
bei dem unter Mitwirkung eines Chemikers ein VR-Werkzeug zum Entwurf
von molekularen Modellen erstellt wurde, das in der Pharmaindustrie eingesetzt
wird. GOOD argumentiert, dass gerade bei immersiven 3 VR-Anwendungen eine
derart benutzerorientierte Methode erforderlich ist, damit die Akzeptanz bei den
Benutzern zustande kommt.
Allerdings kann die partizipatorische Entwicklung den Entwicklungsprozess verlängern
und damit verteuern, weil es zu vielen Diskussionen kommen kann, die
aufgrund eines eventuell nur eingeschränkten Verständnisses der Sichtweise der jeweils
anderen Partner ineffizient verlaufen können. Entscheidend ist daher, dass der
ins Entwicklerteam zu integrierende Benutzer gut in die Gruppe passt, ein gewisses
Verständnis für die technische Seite der Entwicklung hat und gegenseitige Akzeptanz
vorhanden ist. Ein breit diskutiertes und erfolgreiches Beispiel dieser Variante
ist die Entwicklung eines Informationssystems für die Olympischen Spiele in Los
Angeles, in die ein ehemaliger Olympionike intensiv eingebunden wurde [Boies
et al., 1985, Gould et al., 1987] Relativ verbreitet ist diese Entwicklungsmethode bei
Entwicklungen innerhalb einer Firma, bei der ein Mitarbeiter einer Entwicklungsabteilung
zeitweise – meist in Teilzeit – in eine IT-Abteilung dieser Firma integriert
wird.
Die partizipative Entwicklung hat ein besonders großes Potenzial im neuen Bereich
der Web2.0-Entwicklungen, bei denen die Grenze zwischen Nutzern und denjenigen,
die inhaltlich beitragen, unscharf ist. Benutzer an der Entwicklung einer
Web2.0-Plattform möglichst konkret zu beteiligen, die später Content entwickeln
und bereitstellen sollen, ist eine naheliegende und viel versprechende Idee.
Ein aktuelles, relevantes und umfassend dokumentiertes Fallbeispiel ist die Entwicklung
einer Sekretariatsplattform [Zorn et al., 2008], bei der deutlich wird, wie
sehr die Teilnahme der Sekretärinnen an der Technikentwicklung sowohl zur Weiterentwicklung
der Sekretärinnen (Einstellung zur Computertechnologie) als auch
zur Akzeptanz der Technik beigetragen hat.
3 Immersive Systeme sind VR-Systeme, bei denen der Benutzer in die Virtuelle Welt „eintaucht“
und auf Basis realistischer 3D-Darstellungen und spezieller Ein- und Ausgabegeräte natürlich mit
ihr interagiert.
467

Bei größeren und komplexeren Projekten, z.B. der Einführung von Software in
Firmen, die die Arbeit in mehreren Abteilungen betrifft, ist es die Mitarbeit eines
Vertreters der Anwender oft nicht ausreichend. In diesen Fällen werden verstärkt auf
Anwenderseite Teams gebildet, die verschiedene Kompetenzen bündeln und insgesamt
die Anwenderinteressen vertreten [?].
11.7 Beobachtungen, Befragungen und Workshops
Wesentliche Aktivitäten des User Interface Engineerings sind darauf gerichtet,
im Dialog mit Anwendern und anderen Interessenten an einer User Interface-
Entwicklung Informationen einzuholen, zu bewerten und zu strukturieren. Derartige
Aktivitäten sind in allen Phasen der Entwicklung bedeutsam. In den frühen Phasen
dienen sie dazu, aktuelle Lösungen in ihrem Kontext zu verstehen. In späteren Phasen
dienen sie der Festlegung und Priorisierung von Anforderungen und schließlich
wenn prototypische Lösungen vorliegen, dazu diese zu bewerten und Empfehlungen
für die weitere Entwicklung abzuleiten. Die wichtigsten Varianten dieser Dialogführung
sind:
• Beobachtungen,
• Befragungen und
• Workshops
Diese Methoden werden im Folgenden kurz vorgestellt und in den späteren Kapiteln
beispielhaft gezeigt, wie diese effektiv eingesetzt werden.
11.7.1 Beobachtungen
Beobachtungen dienen dazu, die Nutzung von Software durch repräsentative Anwender
in einem realistischen Kontext kennenzulernen und zu analysieren. Realistischer
Kontext bedeutet z.B. am Arbeitsplatz der Benutzer oder bei Freizeitaktivitäten
in einer typischen Situation, z.B. bei mobilen Geräten im Freien oder in
einem Verkehrsmittel. In frühen Phasen dienen Beobachtungen dazu, Arbeitsplätze
bzw. Orte, an denen Software zum Einsatz kommt, dahingehend zu verstehen, dass
Rahmenbedingungen für die Entwicklung verstanden werden. In späteren Phasen
helfen Beobachtungen einzuschätzen, ob prototypische Lösungen prinzipiell akzeptabel
sind. Beobachtungen sind generell sehr wichtig. Unverzichtbar sind sie, wenn
Software nicht in typischen – den Benutzern vertrauten – Büroanwendungen zum
Einsatz kommen soll, z.B. in einem Museum, auf einem Bahnhof, in einem Krankenhaus
oder in anderen speziellen professionellen Anwendungsfeldern.
Der Begriff Beobachtung impliziert, dass die User Interface-Spezialisten zunächst
passiv sind. Sie nehmen wahr und protokollieren, welche Aktivitäten die
Anwender ausführen – steuern das Geschehen aber nicht. Eine komplett passive
468

Vorgehensweise wird aber nicht ausreichen, um komplexe Anwendungssituationen
hinreichend zu verstehen. Insofern sind Nachfragen wichtig, insbesondere solche,
die helfen, das Beobachtete einzuordnen und die Relevanz zu verstehen. Beobachtungen
in der Evaluierungsphase werden stärker von User Interface-Spezialisten gesteuert
– sie geben zumindest einige Testaufgaben vor und erfassen, ob und wie diese
bearbeitet werden können.
Es ist extrem schwierig, komplexe Sachverhalte erstmals zu beobachten und zu
analysieren und gleichzeitig umfassend zu dokumentieren. Daher sollten Beobachtungen
durch kleine Teams (zwei bis drei Mitarbeiter) durchgeführt werden. Diese
Teams können die Beobachtungsergebnisse auch besser interpretieren als ein einzelner
Mitarbeiter, weil es häufig einer Diskussion bedarf, um bestimmte Beobachtungen
richtig einzuordnen.
Lautes Denken.
Die Effektivität von Beobachtungen kann oft wesentlich gesteigert werden, wenn
Benutzer gebeten werden, „laut“ zu denken, also jeweils zu kommentieren, welche
Absichten sie verfolgen und wie sie diese Absichten umsetzen wollen. Auf diese
Weise „verraten“ Benutzer ihr mentales Modell, was für die Entwicklung eine wichtige
Orientierung darstellt (Abschn. 3.2). Allerdings sind nicht alle potenziellen Benutzer
imstande, zügig und umfassend ihre Aktivitäten zu kommentieren. Zudem interferiert
die Lösung einer evtl. komplexen Arbeitsaufgabe mit der Kommentierung
dieser Aufgabe (beide Aktivitäten benötigen Aufmerksamkeit, vgl. Abschn. 2.5).
Daraus folgt auch, dass diese Methode bei Aufgaben, die höchste Konzentration erfordern,
z.B. bei einem neurochirurgischen Eingriff, nicht möglich ist.
11.7.2 Befragungen
Im Unterschied zu Beobachtungen liegt bei Befragungen die Steuerung vorrangig
bei den User Interface-Spezialisten, die durch mehr oder weniger präzise Fragen
gezielt Informationen einholen wollen. Befragungen können in Form von Interviews
mündlich oder mittels Fragebögen schriftlich durchgeführt werden.
11.7.3 Workshops in der Analyse und Evaluierung
Der Begriff Workshop ist weit verbreitet und bezeichnet sehr unterschiedliche Dinge.
Hier ist eine intensive fokussierte Diskussion gemeint, an der mehrere UI-
Spezialisten und mehrere Anwender teilnehmen, um ausgehend von einer intensiven
Diskussion die Entwicklung der Benutzungsschnittstelle voranzutreiben. Ein
Workshop ist sowohl in der Analysephase sinnvoll, um gemeinsam Anforderun-
469

Methoden Varianten Vor- und Nachteile
Beobachtung „Über die Schulter Persönlicher Kontakt,
schauen“, Videoauf- keine große Vorbereizeichnung,
akustische tung erforderlich
Aufzeichnung
les Protokoll)
(verba-
Interview mehr oder weniger
stark strukturiert
Fragebogen Integration von relativ
allgemeinen Fragen
persönlicher Kontakt,
geringer Vorbereitungsaufwand,
organisatorisch und
zeitlich aufwändige
Durchführung
geeignet, um relativ
viele Daten zu
sammeln und eine statistische
Auswertung
zu realisieren, hoher
Vorbereitungsaufwand,
Daten oft erst nach
längerer Zeit verfügbar
Tabelle 11.1: Methoden der Dialogführung beim User Interface Engineering
gen festzulegen und zu priorisieren als auch in der Evaluierung, bei dem das Ziel
dann darin bestehen würde, den Dialog mehrerer Anwender mit den Entwicklern zu
nutzen, um realistische Verbesserungsvorschläge zu entwickeln. Im Unterschied zu
Gruppeninterviews, in denen mehr oder weniger strikte Fragen abgearbeitet werden,
haben die Anwender hier eine aktivere Rolle, u.a. kann ein Vertreter der Anwender
derartige Workshops moderieren. Kreativitätstechniken, wie Brainstorming, können
vor allem bei Requirements Workshops unterstützen, um Vorschläge zu sammeln
und später zu bewerten und zu sortieren. Bei Evaluierungsworkshops steht im Vordergrund
eine gemeinsame Sicht auf aufgetretene Probleme zu entwickeln, die vor
allem dazu Stellung nimmt, welche Probleme mit welcher Priorität gelöst werden
sollten und ggf. welche alternativen Lösungswege verfolgt werden.
11.8 Werkzeuge für das User Interface Engineering
Das User Interface Engineering basiert nicht nur auf konzeptuellen Methoden und
Vorgehensweisen sondern auch auf praktischen (Software-)Werkzeugen, die in den
einzelnen Phasen unterstützen. Dies betrifft nicht nur die Implementierung, die offensichtlich
geeignete Bibliotheken mit vordefinierten Bedienelementen erfordert,
sondern auch die frühen Phasen des User Interface Engineering. Die vielen Dokumente,
die in der Analysephase entstehen, die oft in verschiedenen Versionen
vorliegen und zahlreiche Querbezüge aufweisen, müssen durch geeignete Werkzeu-
470

ge verwaltet werden. Für die Erstellung spezieller Diagrammformen ist eine Unterstützung
hilfreich, die idealererweise ein geeignetes Layout erzeugt und evtl.
auch gewisse Überprüfungen auf Plausibilität vornimmt. Die Auswertung von größeren
Evaluierungen erfordert geeignete Statistiksoftware. Die Prototyperstellung
kann durch Werkzeuge unterstützt werden; im günstigsten Fall so, dass keine Programmierung
erforderlich ist und der Entwurf auf das Design konzentriert werden
kann. Sogenannte Interface Builder unterstützen die visuelle Spezifikation einer
Benutzungsschnittstelle oft bereits abgestimmt auf eine Zielplattform. Eine etwas
ältere Übersicht über derartige Werkzeuge findet sich in [Myers et al., 2000].
Neuere Werkzeuge sind oft spezialisierter und z.B. auf die Erstellung (Authoring)
von Multimedia-Präsentationen, auf die Erstellung von Applikationen für mobile
Geräte, auf die Erstellung von interaktiven Websites oder auf interaktive 3D-
Benutzungsschnittstellen zugeschnitten.
Da sich diese Werkzeuge relativ schnell verändern, liegt in diesem Buch darauf
nicht der Fokus.
11.9 Zusammenfassung
471

Kapitel 12
Analyse von Aufgaben und Benutzern
In diesem Kapitel werden die frühen Phasen der Entwicklung interaktiver Systeme
erläutert. Diese Phasen umfassen die Analyse von Aufgaben Benutzern und des
Kontextes einschließlich organisatorischer und ökonomischer Rahmenbedingungen
mit dem Ziel Anforderungen an die Entwicklung abzuleiten. Die Analysephase basiert
darauf, dass eine Vielzahl von Daten gesammelt, strukturiert und bewertet wird,
wobei die Ergebnisse in prägnanter Form dargestellt werden müssen. Insbesondere
werden Modelle genutzt, um die aus der Analyse gewonnenen Annahmen über
den relevanten Ausschnitt der Realität darzustellen. Möglichst gute (ausreichend
genaue) Modelle der aktuellen Situation sind wesentlich für den Entwurf, der auf
einem Modell der zukünftigen Nutzung von Technologie basiert [Diaper and Stanton,
2003]. Eine Orientierung für diese Analysephase bieten das Vorgehen von Ingenieuren
in der Industrie, die neue Anlagen und Fabriken planen und dabei präzise
Arbeitsschritte, Ereignisse und Abhängigkeiten durchdenken müssen. Insbesondere
eine hierarchische Zerlegung von Aktivitäten in Teilaufgaben ist auch für die Analysephase
des User Interface Engineering relevant [Butler, 1996]. Neben Aufgaben,
die relativ präzise beschrieben werden können, sind auch Prozesse zu beachten, die
weniger klar definiert sind und sich durch viele optionale Aktivitäten auszeichnen.
Die Analyse von Benutzern und ihren Aufgaben ist die Voraussetzung für die
benutzergerechte Entwicklung interaktiver Systeme. Nahezu alle der im Kapitel 6
aufgeführten Prinzipien basieren auf konkreten Vorstellungen über Benutzer und
ihre Aufgaben. Benutzer mit ihren Fähigkeiten und Fertigkeiten, Aufgaben, die bestimmte
Handlungen erfordern und an deren Erledigung gewisse Voraussetzungen
geknüpft sind, bilden zusammen mit einem interaktiven Computersystem das Dreieck
der Softwareergonomie. So wichtig eine tiefgründige Analyse ist, so schwierig
ist es, eine solche Analyse durchzuführen. Informatikkenntnisse sind nützlich,
aber bei weitem nicht ausreichend. Kenntnisse und Erfahrungen in der Psychologie,
Soziologie und Arbeitswissenschaft sind besonders hilfreich, um komplexe Nutzungskontexte
in der Freizeit und an Arbeitsplätzen zu verstehen. Die Bezeichnung
User Researcher, die viele auf die Analysephase spezialisierte Usability-Experten
verwenden, ist angemessen: die solide Kenntnis von Methoden und ihre sorgfältige
und kreative Anwendung ist Voraussetzung, um zu belastbaren und klaren Aussagen
473

über Aufgaben und Benutzer zu kommen. Besonders wichtig ist es, Aufgaben und
Benutzer in einer realen Umgebung kennenzulernen, z.B. durch Besuche „vor Ort“.
Eine Analyse ausschließlich auf Basis von Akten, Unterlagen oder Befragungen an
nicht-typischen Orten aufzubauen, ist nicht empfehlenswert.
Eine systematische und vertiefte Analyse von Aufgaben und Benutzern wird
noch lange nicht bei allen Entwicklungen durchgeführt. Oft wird auf Basis der Aufgabenstellung
mit der Realisierung der Schnittstelle begonnen. Die fehlerfreie Umsetzung
der Funktionalität und die Einhaltung der von den Auftraggebern definierten
(harten) Rahmenbedingungen haben dabei Priorität. Geis and Hartwig [1998]
erwähnen, dass 60 Prozent der Probleme bei der Benutzung auf die unzureichende
Anpassung der Schnittstelle an die Aufgabe herrühren, also auf Probleme, deren
Ursache in diesen frühen Phasen liegt.
Die Vorgehensweise bei der Analyse von Aufgaben, Benutzern und Nutzungskontexten
unterscheidet sich grundlegend von der Art und Weise, wie Theorien über
das Lernen, über motorische Fertigkeiten oder Phänomene der Aufmerksamkeitslenkung
(Kapitel 2) gewonnen werden. Während diese Erkenntnisse auf Laborexperimenten
basieren, spielen hier Beobachtungen und Befragungen an Arbeitsplätzen
eine entscheidende Rolle, um Arbeits- und Nutzungskontexte realistisch in ihrer
Komplexität zu erfassen. Der Kontext, die räumliche und organisatorische Einbettung
von Aktivitäten, wird hier gezielt studiert, während in psychologischen Experimenten
dieser Kontext als Störfaktor gelten würde, der bewusst vermieden wird.
Gliederung.
In Abschn. 12.1 wird eine initiale Aufgabenanalyse erläutert. Im Ergebnis dieser
Phase soll das zu lösende Problem (engl. situation of concern) klar beschrieben sein
und eine kurze Beschreibung der Aufgabe (engl. problem statement) vorliegen. Diese
Ergebnisse sind Ausgangspunkt für eine vertiefte Analyse der Aufgaben. Diese
wird in Abschn. 12.2 erläutert, wobei Methoden der Analyse, wie Beobachtungen,
Interviews und schriftliche Befragungen, vertiefend behandelt werden.
Szenarien, Workflowdiagramme, Aufgaben- und Performance-Modelle sind mögliche
Ergebnisse dieser Phase (Abschn. 12.3). Die Benutzer werden in einer weiteren
Analysephase hinsichtlich ihrer Fähigkeiten, Vorkenntnisse und Fertigkeiten
charakterisiert (Abschn. 12.4), wobei z.B. Persona-Beschreibungen genutzt werden.
Bei der User Interface-Entwicklung sind oft Rahmenbedingungen zu beachten (Abschn.
12.5).
Die Analyseergebnisse werden genutzt, um Anforderungen festzulegen, wobei
sowohl funktionale als auch nicht-funktionale Anforderungen betrachtet werden
und Aspekte der Akzeptanz eine wichtige Rolle spielen (Abschn. 12.6). Es wird
dabei auch diskutiert, wie Anforderungen priorisiert und strukturiert werden.
474

12.1 Initiale Aufgabenanalyse
In der ersten Phase der Aufgabenanalyse geht es darum, die Situation zu charakterisieren,
die eine Neu- bzw. Weiterentwicklung eines Systems erforderlich macht.
Entscheidend ist, dass in Erfahrung gebracht wird, wie das Problem bisher gelöst
wird. Wird eine automatische Lösung für ein bisher manuell bearbeitetes Problem
angestrebt? Wird eine automatische Lösung angestrebt, die Nachteile einer bisher
genutzten Software umgehen soll? Was empfinden die Benutzer selbst als problematisch
an der bisherigen Art, ein Problem zu lösen, und was erscheint ihnen als
bewährt? Die Antworten auf diese Fragen sind für die weitere Entwicklung entscheidend.
In dieser Phase werden die Hauptziele eines Auftraggebers (im Falle der Vertragsentwicklung)
oder die wahrscheinlichen Ziele großer Benutzergruppen (im Falle
der Entwicklung für einen großen Markt) erläutert und analysiert. Dabei ist es wichtig,
typische Ziele zu verstehen, weil im konkreten Fall meist eines dieser typischen
Ziele im Vordergrund steht.
Kostenreduktion.
Ein kommerzieller Auftraggeber, z.B. eine mittelständische Firma oder eine Bank
will durch Einführung/Ausbau einer Softwarelösung sehr häufig Kosten reduzieren.
Dies kann erreicht werden, wenn Mitarbeiter Aufgaben zügiger erledigen können
oder gar Aufgaben automatisch durchgeführt werden, so dass Mitarbeiter an anderen
Stellen eingesetzt werden können. Die Mitarbeiter haben oft ganz andere Ziele,
fühlen sich evtl. sogar vom Jobverlust bedroht. Einsparziele waren z.B. wesentlich
bei der Einführung von Geldautomaten, electronic Banking-Lösungen oder Fahrkartenautomaten.
Die meisten IT-Projekte in Krankenhäusern dienen dazu, Verwaltungsabläufe
zu optimieren und dadurch zu beschleunigen. In diesen Fällen muss
die Softwareentwicklung konsequent auf diese Einsparziele ausgerichtet werden.
Hohe Zuverlässigkeit der Soft- und Hardware, stark integrierte Abläufe, bei denen
jegliche Mehrfacherfassung von Daten vermieden wird, sind dabei wesentlich. In radiologischen
Kliniken hat man die Erfassung und Archivierung von Bilddaten, z.B.
der Kernspintomographie, oft konsequent digitalisiert, um die Kosten der analogen
Filme zu sparen, sowie die Kosten, diese physisch zu archivieren. Außerdem sollten
die Suchzeiten in diesen Archiven verringert werden. Wer Kosten sparen will,
muss potenzielle Einspareffekte mit den dafür nötigen Investitionen in Hard- und
Software sowie Schulungen und andere organisatorische Maßnahmen vergleichen.
Eventuell ergibt diese Diskussion, dass eine Computertunterstützung zunächst auf
besonders häufige Aufgaben/Kernbereiche konzentriert werden muss, weil der hohe
Aufwand diverser Speziallösungen dem Kosteneinsparziel im Wege steht.
475

Qualitätsverbesserungen.
Qualitätsverbesserungen sind ein weiteres typisches Ziel von Firmen. Bankautomaten
sind rund um die Uhr „geöffnet“, ähnlich wie andere Verkaufsautomaten. Damit
ist ein potenziell besserer Service und ein höherer Umsatz verbunden. Webbasierte
Help-Desk-Systeme sollen Benutzern von Hard- und Software zeitaufwändige und
teure Anrufe in einer Hotline ersparen, in dem zumindest für relativ einfache und
häufige Probleme Lösungen übersichtlich dargestellt werden.
Für die radiologische Befundung wird Software entwickelt, um zuverlässiger zu
richtigen Diagnosen zu kommen, den Schweregrad von Erkrankungen besser einzuschätzen
und präzisere Informationen für die Planung operativer Eingriffe zu geben.
Wichtige Nebenbedingungen.
Mit einer Neu- oder Weiterentwicklung sind auch Risiken verbunden, die einerseits
darin liegen, dass die angestrebten Effekte nicht erreicht werden, andererseits darin,
dass Verschlechterungen bei anderen Aspekte eines Prozesses eintreten. Wichtig in
der Analysephase ist es also zu verstehen, in welchen Bereichen keine (wesentlichen)
Verschlechterungen eintreten dürfen.
Bankautomaten, electronic Banking und e-Commerce-Lösungen müssen so realisiert
werden, dass die Daten der Kunden und ihr Geld sicher sind. Der potenziell
höhere Umsatz wird nur erreicht, wenn Benutzer den Systemen vertrauen. Sicherheit
ist also in derartigen Fällen die wichtigste Nebenbedingung.
Software für die radiologische Befundung dient primär der Qualitätsverbesserung
darf aber die Effizienz der Ärzte nicht (wesentlich) verringern. Lange Ladeund
Setupzeiten, langsame Verbindungen zu einem Server mit den großen Mengen
an Bilddaten oder langwierige Berechnungen auf den Bilddaten sind also nicht akzeptabel,
weil sie letztlich zu Mehrbelastungen und Mehrkosten führen, die in der
Regel nicht gedeckt werden können. Es gibt Erfahrungswerte, wie lange Radiologen
im Durchschnitt für die Befundung ohne Softwareeinsatz bestimmter Bilddaten
brauchen – diese Werte müssen erfasst und während der gesamten Entwicklung
berücksichtigt werden, damit bei allen Diskussionen über mögliche Merkmale der
Software diese Performance beachtet wird.
Das Hauptziel und die wichtigsten Nebenbedingungen kennzeichnen zusammen
die Situation of concern – ein prägnanter Begriff, der auf [Newman and Lamming,
1995] zurückgeht. Diese lässt sich normalerweise in ein bis zwei Sätzen beschreiben
und sollte im Falle der Auftragsentwicklung gründlich mit den Auftraggebern
bzw. den Endanwendern geklärt werden. Bei einer Entwicklung für den freien Markt
sollten mehrere erfahrene Mitarbeiter mit substanziellen Markt- und Kundenerfahrungen
daran beteiligt sein, diese Beschreibung vorzunehmen.
476

Abb. 12.1: Die Ausgangssituation, die Anlass für eine Neu- oder Weiterentwicklung
eines Systems gibt, ist Ausgangspunkt der weiteren Analyse (Nach [Newman and
Lamming, 1995]).
Abb. 12.2: Ausgehend von den Aktivitäts- und Performance-Daten sowie dem Problemstatement
wird in einem Syntheseprozess ein erstes Dokument mit Anforderungen
erstellt, dass in mehreren Iterationen zu verfeinern ist. (Nach [Newman and
Lamming, 1995]).
Situation of Concern: Beispiel 1.
Studierende in einem noch relativ neuen Studiengang sind oft unsicher in Bezug auf
die Auswahl von Wahlpflichtfächern und Nebenfächern. Sie sind an Erfahrungen
älterer Studierender interessiert und haben generell einen hohen Beratungsbedarf.
Situation of Concern: Beispiel 2.
In einem großen Krankenhaus sind radiologische Bilddaten teilweise nicht auffindbar,
so dass es zu unnötigen Mehrfachuntersuchungen kommt. Die an der Behandlung
beteiligten Ärzte beklagen oft, dass Bilddaten und Befunde nicht an ihren Ar-
477

eitsplätzen verfügbar sind.
Ausgehend von der Situation of concern, z.B. den genannten Beispielen, soll ein
ebenso prägnantes auf die zu entwickelnde Lösung zugeschnittenes Statement entstehen
– das Problem Statement [Newman and Lamming, 1995]. Dieses Statement
hat eine gewisse Struktur; es soll Angaben zur Lösungsform, zur Art der Unterstützung,
zur unterstützen Aktivität enthalten und die Benutzer charakterisieren. Ein erster
Entwurf dieses Statements sollte nach der Diskussion der Situation of Concern
erfolgen. Nach der vertieften Aufgabenanalyse sollte das Statement noch einmal
verifiziert werden. Der in Abb. 12.3 dargestellte Prozess veranschaulicht dies. Wir
wollen unsere beiden Beispiele kurz aufgreifen und passende Problem Statements
diskutieren:
Problem Statement: Beispiel 1.
Ein übersichtlich gestaltetes Webbasiertes System mit einem moderierten Forum
soll Empfehlungen und Hinweise von älteren Studierenden und Lehrkräften für jüngere
Studierende des Studiengangs präsentieren.
Problem Statement: Beispiel 2.
Ein webbasiertes radiologisches Informationssystem soll die Archivierung digitaler
Bilddaten übernehmen. Alle an der Behandlung beteiligten Ärzte erhalten an ihrem
Schreibtisch Zugriff auf die Daten eines Patienten und die Befunde des Radiologen,
um zügig die nötigen therapeutische Entscheidungen zu treffen.
Beide Problem Statements beschreiben, wer unterstützt wird (hervorgehoben),
wie die Unterstützung erfolgt (webbasiertes System mit Forum bzw. webbasiertes
System) und welche Aktivität unterstützt wird. Mit Problem Statements sind auch
Abgrenzungen verbunden; das erste Statement macht deutlich, dass die eingeschriebenen
Studierenden adressiert werden und nicht Schüler oder Eltern, die sich grob
über Studienangebote informieren. Das zweite Statement impliziert, dass die Daten
nur Ärzten zur Verfügung stehen und genauer, dass es eine Autorisierung der an der
Behandlung beteiligten Ärzte geben muss.
12.2 Vertiefte Analyse von Aufgaben
In diesem Abschnitt wird erläutert, wie die in Abb. 12.1 genannten Aktivitätsdaten
erhoben werden. Eine Analyse von Aufgaben, Betriebsabläufen und organisatorischen
Zusammenhängen zeigt zunächst formale Strukturen und Verantwortlichkeiten,
die unter anderem in Tätigkeitsbeschreibungen, Verwaltungshandbüchern und
478

Dienstanweisungen festgelegt sein können. Ob es möglich ist, Zugang zu diesen
Dokumenten zu bekommen, muss erfragt werden. In der öffentlichen Verwaltung,
z.B. in Finanz- und Sozialämtern, orientieren sich die Abläufe stark an gesetzlichen
Vorgaben – dies betrifft insbesondere die Verantwortung und ggf. gerichtlich Überprüfung
von Entscheidungen.
Neben dieser formalen Ebene gibt es eine informelle Ebene, auf der „ungeschriebene“
Regeln existieren, wie mit Problemen umgegangen wird, wie Informationen
weitergeleitet werden. Teilweise wird auf der informellen Ebene sogar die formale
Vorgehensweise („Dienstweg“) regelmäßig umgangen. So beschreiben Poltrock
and Grudin [1994], dass User Interface-Entwickler inoffiziell den Kontakt zu ausgewählten
Benutzern pflegen, um direkt Probleme und Bedürfnisse kennenzulernen.
Die Entwickler umgehen so den offiziellen Weg, bei dem der direkte Kontakt dem
Marketing vorbehalten ist, welches eine Design-Abteilung informiert und erst über
diesen Weg würden (mehrfach grob vereinfachte) Informationen in die Entwicklungsabteilung
gelangen.
Für das Funktionieren von Organisationen ist also die informelle Ebene genau so
wichtig wie die formelle. Ihre Analyse ist besonders schwierig und erfordert Erfahrung,
soziale Kompetenz und „Zugewandtheit“. Auf der offiziellen Ebene wird vorwiegend
erklärt, wie Aufgaben erfolgreich bewältigt werden. Für die Analyse (und
Vermeidung von Problemsituationen) ist oft die informelle Ebene entscheidend. Das
ist auch einleuchtend – es gibt in jedem anspruchsvollen beruflichen Umfeld viele
mögliche Problemfälle und diese sind in der Regel nicht offiziell „geregelt“. Ausnahmen
sind Arbeitsplätze in sicherheitskritischen Bereichen, die oft penible Vorschriften
für alle bisher bekannten Probleme haben.
Was soll analysiert werden?
Die konkreten Fragen, die eine Analyse leiten, sind naturgemäß sehr spezifisch.
Orientierung geben die folgenden allgemeinen Fragen:
1. Welche (Arbeits-)prozesse sind relevant?
2. Welche Ergebnisse entstehen dabei?
3. Aus welchen Schritten bestehen die (Arbeits-)prozesse?
4. Welche Entscheidungen werden dabei gefällt, wodurch werden sie unterstützt?
5. Welche Anwender sind mit welchen Verantwortlichkeiten daran beteiligt?
6. Welche Schnittstellen zu anderen Prozessen existieren?
7. Welche Datenmengen aus welchen Datenbeständen werden in einem bestimmten
Zeitraum bearbeitet?
8. Welche Arbeitsschritte rufen bei den Anwendern Unzufriedenheit hervor?
9. Welche Fehler treten wie häufig auf?
10. Wie werden Fehler entdeckt und behoben?
Aus Antworten auf diese Fragen ergeben sich Aussagen
1. zur zeitlichen Reihenfolge von Teilschritten,
479

2. zur Dauer einzelner Teilschritte,
3. zur Häufigkeit einzelner Aufgaben,
4. zur Einteilung in häufige und seltenere Aufgaben und
5. zu kritischen und unkritischen Aufgaben.
Diese und weitere Aspekte werden als Aufgabenanalyse (task analysis) bezeichnet.
Im Ergebnis dieser Analyse werden Aufgaben auf einer hohen Ebene identifiziert
(z.B. Reiseroute bestimmen, Fahrzeiten ermitteln, Reservierung veranlassen)
und es kann beschrieben werden, wie Aufgaben in Teilaufgaben zerlegt werden,
welche Entscheidungen bei der Erledigung von Aufgaben gefällt werden und ähnliches.
Vorbemerkungen.
Einen Experten zu bitten, seine Vorgehensweise bei der Lösung eines komplexen
Problems zu beschreiben, ist oft bemerkenswert ineffektiv, selbst wenn die Sprache
des Experten gut verstanden wird und durch präzise Nachfragen versucht wird,
offene Punkte zu klären. Dafür gibt es u.a. folgende Gründe:
• Der Experte hat die Vorgänge verinnerlicht (automatisiert) und kann sie kaum
erklären (dies wurde in Band 1, Abschn. 2.7 mit der ACT-Theorie erklärt).
• Expertenwissen ist oft implizit und schwer zu verbalisieren.
• Experten verbergen ihr Expertenwissen oft selbst vor Kollegen, weil sie darin
einen persönlichen Vorteil sehen.
Trotz dieser grundsätzlichen Schwierigkeiten ist die Beobachtung und Befragung
von Experten eine wichtige Methode der Aufgabenanalyse. Das erste Problem kann
gelindert werden, wenn man den Experten bei der Lösung eines Problems beobachten
kann. Er ist dann in einer realistischen Situation, die es mental einfacher macht,
die Vorgänge zu beschreiben und zudem wird durch intensive Beobachtung einiges
offensichtlich, was allein verbal nicht vermittelt werden kann. Auch das zweite Problem
wird gelindert, wenn der Experte etwas demonstriert und dabei erklärt, ggf.
sind auch Skizzen hilfreich. Dennoch bleibt einiges auch bei sorgfältiger Befragung
und Beobachtung offen. Wenn man z.B. einen erfahrenen Chirurgen fragt, nach welchen
Kriterien er die Operabilität von Patienten mit komplexem Krankheitsbild beurteilt,
wird er neben einigen präzisen Kriterien und dem Verweis auf Leitlinien
der Fachgesellschaften auch auf sein Bauchgefühl verweisen, die Intuition, die ihm
sagt, ob die Operation mit vertretbarem Risiko und ausreichenden Erfolgschancen
durchführbar ist.
Das dritte Problem – mangelnde Offenheit – ist kritisch und kann nur gelindert
werden, wenn ein Vertrauen zwischen einem UI-Spezialisten und einem Anwendungsexperten
vorhanden ist. Vertrauen stellt sich nicht im allerersten Treffen nach
kurzer Zeit ein – insofern ist es nicht verwunderlich, wenn ein zweites oder drittes
Treffen evtl. substanziell neue Erkenntnisse mit sich bringt. Unter Umständen ist der
erste Ansprechpartner auch nicht der richtige; wer nicht mal den Kollegen vertraut,
wird einem Außenstehenden gegenüber wahrscheinlich auch nicht vertrauen.
480

Um nach dem Projektstart Benutzer, Aufgaben und Nutzungskontexte zu verstehen,
sind Beobachtungen an Arbeitsplätzen bzw. in entsprechenden Freizeitsituationen
und nachfolgende (mündliche) Befragungen sehr hilfreich. Beobachtungen
und Interviews können dabei kombiniert werden oder separat (an zwei Terminen)
durchgeführt werden.
12.2.1 Beobachtungen
Eine wichtige Rolle in der Analysephase spielt der Besuch bei den Benutzern vor
Ort an ihrem Arbeitsplatz, um diesen bei ihrer Arbeit „über die Schulter“ zu schauen
und um einen möglichst realistischen Eindruck von den Arbeitsaufgaben und vom
Umfeld zu gewinnen. Derartige „day in the life“-Beobachtungen können für die
Entwickler eine enorme Motivation darstellen und Einsichten vermitteln, die allein
durch ein Interview nicht möglich sind. Wer eine Software für die Navigation von
Blinden entwickelt, sollte Blinden zuschauen, wie sie sich mit ihren bisherigen Hilfen
orientieren, wer Operatoren von großen Telekommunikationsnetzwerken bei der
Fehlersuche unterstützen will, muss deren Arbeit vor vielen Kontrollmonitoren beobachten,
und wer schließlich medizinische Aufgaben vereinfachen will, der muss
ein Bild von dem hektischen Arbeitsalltag von Ärzten haben. Beobachtungen ermöglichen
oft das Verständnis von Zusammenhängen, die Benutzer selbst nicht explizit
äußern würden. Oft tragen Beobachtungen dazu bei, dass die UI-Spezialisten
erkennen, welche Fragen in späteren Interviews überhaupt zu stellen sind. Wie ergiebig
Beobachtungen sind, hängt von mehreren Faktoren und Voraussetzungen ab:
• Die UI-Spezialisten müssen sich schon vor einer Beobachtung kundig gemacht
haben und zumindest grob wissen, „was sie erwartet“.
• Die Beobachtung muss gut geplant werden, so dass sich tatsächlich etwas Interessantes
und Relevantes beobachten lässt.
• Die beobachteten Benutzer sind unterschiedlich gut imstande, zu erklären, was
sie tun, warum sie dies tun und wie sich die in übergeordnete Prozesse einordnet.
• UI-Spezialisten können durch gezieltes und geschicktes Nachfragen evtl. wesentliche
Informationen erfassen.
• Beobachtungen, die akustisch oder per Video aufgezeichnet werden, sind in der
Regel ergiebiger in der Auswertung.
• Zwei UI-Spezialisten, die das Beobachtete diskutieren können, werden im Ergebnis
mehr Zusammenhänge erkennen und mehr Fragen generieren als einer.
Als Konsequenz sollte versucht werden, die Beobachtung so zu gestalten, dass
möglichst viele der genannten Faktoren die Beobachtung positiv beeinflussen.
481

Protokollierung von Beobachtungen.
Eine wichtige Frage betrifft die Art der Protokollierung: handgeschriebene Notizen
und Skizzen, evtl. ergänzt durch Fotos sind der Standard. Tonband- oder Videoaufnahmen
sind umfassender und exakter. Allerdings ist die Auswertung von derartigen
Aufnahmen sehr aufwändig – wenn dieser Aufwand nicht geleistet werden kann,
lohnt sich die Erhebung der Daten kaum.
Zu einem benutzerzentrierten Entwicklungsprozess gehört natürlich, dass diese
Frage auch aus Benutzersicht betrachtet wird. Videoaufnahmen von Benutzern und
ihrer Arbeitsplätze, aber auch Fotos werfen massive Fragen nach dem Datenschutz
auf. Die Tatsache, dass Bilder und Videos heutzutage digital aufgenommen und fast
ohne Aufwand beliebig verbreitet werden, verschärft die Datenschutzproblematik
erheblich. Insofern muss im Vorfeld mit Benutzern und ggf. deren Vorgesetzten geklärt
werden, ob derartige Aufnahmen gestattet sind und es muss sorgfältig erklärt
werden, wie die Daten verwendet werden sollen und wie sichergestellt wird, dass sie
nicht für andere Zwecke verwendet können. Auch die Frage, wie lange die Daten
aufbewahrt werden und wer dazu Zugang hat, ist wesentlich. Die Genehmigung zur
Aufzeichnung sollte rechtzeitig geklärt und auch schriftlich festgehalten werden.
Die Benutzer müssen dabei auch die Möglichkeit haben, die Aufzeichnung zu stoppen
und ggf. zu überprüfen, was aufgezeichnet wurde. Selbst ohne eine derartige
Aufzeichnung erlangen die UI-Spezialisten dabei meist Erkenntnisse, die vertraulich
zu behandeln sind. Oft ist daher die Unterzeichnung eines Dokuments nötig, in
dem die UI-Spezialisten versichern die Informationen nicht weiterzugeben.
Praktisches Vorgehen.
Benutzer zu bitten, „laut“ zu denken, also ihre Vorgehensweise zu kommentieren
und zu erklären, ist oft sehr hilfreich. Das mentale Modell der Benutzer, einschließlich
der wahrgenommenen Probleme, wird dadurch teilweise explizit, zumindest die
Aspekte, die sich leicht verbalisieren lassen. Komplexere Prozesse lassen sich nicht
ausreichend durch eine einmalige Beobachtung analysieren. Mehrere Termine, die
etwas kürzer sind, sind günstiger als wenige sehr lange Beobachtungen. Sollten aus
organisatorischen Gründen, z.B. längere Anreisen, nur sehr wenige längere Termine
vorgesehen werden, sind ausreichende Pausen wichtig. Für die UI-Spezialisten ist
dies eine Gelegenheit, die Notizen zu sichten, zu strukturieren und zu analysieren,
was unklar geblieben ist bzw. welche Informationen noch bestätigt werden müssen.
Beobachtungen mit Video- bzw. Tonbandaufzeichnungen sind meist erst bei einem
zweiten oder dritten Besuch denkbar. Vor dem ersten Kontakt mit Benutzern bei der
Vorbereitung einer Beobachtung auch nach der Möglichkeit einer Aufzeichnung zu
fragen, ist schwer vorstellbar.
482

Beispiel.
Für die gründliche Weiterentwicklung einer kommerziellen radiologischen Workstation,
also einer umfassenden Software, mit der Radiologen Computertomographieund
Kenrspintomographiedaten befunden können, wurden die Abläufe in einer radiologischen
Klinik beobachtet und analysiert. Die ausgewählte Klinik weist eine
mittlere Größe auf (keine Universitätsklinik, aber auch keine sehr kleine Einrichtung).
Die Beobachtung wurde von zwei Personen durchgeführt, darunter ein UI-
Spezialist und der Geschäftsführer der Firma. Umfangreiche Vorkenntnisse waren
vorhanden; diese stammten vor allem aus Erfahrungen mit dem Vorgängerprodukt
und dabei vor allem von ersten Installationen und Messepräsentationen, die zu entsprechendem
Feedback von Radiologen geführt haben. Die Beobachtung hatte folgende
Ziele:
• die einzelnen Arbeitsplätze in der Klinik sollten in Bezug auf dort typische
diagnostische Fragen und Untersuchungsabläufe analysiert, werden,
• Erfahrungen der Radiologen mit der dort eingesetzten Software sollte dokumentiert
werden und
• das Zusammenspiel zwischen Radiologen und den überweisenden Ärzten, z.B.
Chirurgen beschrieben werden.
Die Beobachtung wurde mit dem Chefarzt der Klinik gründlich besprochen. Alle
Mitarbeiter der Klinik wurden darüber informiert. Die Beobachtung erfolgt an
vier aufeinanderfolgenden Tagen, so dass tatsächlich alle Arbeitsplätze beobachtet
werden konnten. Die Beobachtungen dauerten pro Tag etwa vier Stunden, wobei
nach ein bis zwei Stunden eine Pause erfolgte, um die Beobachtungsergebnisse
zu strukturieren und zu konsolidieren. Die Beobachtungen wurden ausschließlich
handschriftlich dokumentiert. Offene Fragen wurden zum großen Teil sofort geklärt;
einige Fragen wurden in einem abschließenden Gespräch mit dem Chefarzt
diskutiert. Alle Fragen, die Ausgangspunkt der Beobachtungen waren, ließen sich
umfassend klären. Zudem wurde eine Vielzahl weiterer nicht-antizipierter Beobachtungen
gemacht. So wurde deutlich, wie stark die radiologische Befundung als
Kooperation zwischen Radiologen und Medizinisch-technischer radiologischer Assistentin
(MTRA) zu verstehen ist. Nicht selten arbeitet dabei eine erfahrene MTRA,
die die Geräte und die Software lange kennt, mit einer relativ jungen Assistenzärztin
zusammen. Die Befunderstellung ist die originär ärztliche Aufgabe, aber bzgl.
der Einstellung des Gerätes und der Nutzung der Software kann die MTRA sehr
weitreichend unterstützen. Die bisherige Zusammenarbeit mit Benutzern hatte sich
zu stark auf die Radiologen konzentriert und den Kooperationsaspekt vernachlässigt.
Bzgl. der Zusammenarbeit mit den überweisenden Ärzten wurde deutlich, dass
nicht nur schriftliche Befunde übermittelt wurden, sondern häufig in sogenannten
Röntgendemonstrationen die Ergebnisse diesen Ärzten präsentiert und das weitere
therapeutische Vorgehen diskutiert werden konnte. Diese Röntgendemonstrationen
sind ein wichtiger Nutzungskontext, der andere Anforderungen an die Software (Art
der Darstellung, Einstellmöglichkeiten) stellt als die individuelle Befundung. Ein
besseres Verständnis ist auch dafür entstanden, an welchen Arbeitsplätzen Spezial-
483

software mit zugeschnittenen Algorithmen und Darstellungsmöglichkeiten benötigt
wird und welche Befunde mit einer relativ allgemeinen radiologischen Workstation
erstellt werden können. Die Beobachtungsergebnisse waren Ausgangspunkt für
Überlegungen, wie die Befundung stärker standardisiert werden kann, um sie zu beschleunigen,
ohne die Flexibilität einzuschränken, die in einem Einzelfall nötig ist,
um dafür gezielte Sichten darzustellen. Standardisierung bezieht sich dabei immer
auf spezielle diagnostische Aufgaben, z.B. die Befundung Computertomographiedaten
der Lunge bei Verdacht auf Lungenkrebs. Für derartige Aufgaben können z.B.
vordefinierte Sichten, Detaileinstellungen, wie Kontrast und Helligkeit, ggf. Synchronisationen
zwischen mehreren Sichten voreingestellt sein. Abb. ?? zeigt ein
Beispiel einer typischen Anordnung befundrelevanter Ansichten.
Abb. 12.3: Für die Planung eines neurochirurgischen Eingriffs sind CT-Daten des
Kopfes dargestellt. Gleichzeitig ist der Schädel als 3D-Darstellung und in orthogonalen
Querschnitten aus drei Richtungen dargestellt. Alle Darstellungsparameter
entsprechen den Standardwerten für diese Untersuchung.
Schließlich wurde auch deutlich, welche Informationen bei der Befundung erhoben
werden müssen, um die korrekte Abrechnung der Leistungen bei der Krankenkasse
zu ermöglichen. Die Ergebnisse dieser Beobachtungen wurden in einem
zwölfseitigen Dokument festgehalten, dass dem Produktmanager und den Entwicklern
zur Verfügung gestellt wurde. Zusätzlich wurden die Ergebnisse den Entwicklern
in einem Vortrag vorgestellt und diskutiert. Das Feedback der Entwickler machte
deutlich, dass diese Information als sehr wertvoll angesehen wurde.
484

Analyse von zeitlichen Aspekten und Varianten.
Häufig spielt die Erfassung zeitlicher Aspekte eine wichtige Rolle, vor allem dann,
wenn die Situation of Concern primär darin besteht, dass Vorgänge beschleunigt
werden sollen. In solchen Situationen ist es sehr hilfreich, zu messen, wie lange einzelne
Schritte dauern. Aussagen von Benutzern zu derartigen Zeiten sind oft sehr ungenau.
Valide Ergebnisse sind nur zu erwarten, wenn eine größere Zahl an Messungen
durchgeführt wird, verschiedene Benutzer und Varianten der Aufgabe betrachtet
werden. Ob solche Messungen möglich sind, bedarf einer gründlichen Diskussion.
ein externer Experte, der mit der Stoppuhr die Arbeit von Mitarbeitern analysiert,
ist natürlich nicht immer gern gesehen. Prinzipiell können Zeiten auch anhand von
Videoaufnahmen nach der eigentlichen Beobachtung gemessen werden – das unschöne
Bild mit der Stoppuhr ist so vermeidbar. Die Erfassung zeitlicher Aspekte
ist insbesondere Voraussetzung für die Erstellung eines deskriptiven Performance-
Modells (Abschn. 12.3.2).
Um ein valides Aufgaben- bzw. Prozessmodell zu erstellen, ist es auch wichtig,
Varianten von Abläufen zu erfassen. Dadurch kann beschrieben werden, wie wahrscheinlich
bestimmte Abläufe sind, so dass sich die Entwicklung auf die häufiger
auftretenden Varianten fokussieren kann. Abläufe, die seltener auftreten, können
auf ihre praktische Relevanz hinterfragt werden.
Eine ausgefeilte Beobachtung mit dem Ziel die ablaufenden Prozesse mit ihren
Aktivitäten, Abhängigkeiten und Ereignissen detailliert zu erfassen, bedarf einer
guten Organisation und evtl. auch technischer Unterstützung. Der beobachtende
User Interface-Experte benötigt eine definierte Menge an Symbolen und Zeichen,
mit denen er zügig und eindeutig, die beobachteten Ereignisse festhalten kann. In
Usability Labors (Abschn. ??) wird spezielle Software eingesetzt, die diese Art der
Protokollierung unterstützt. Die Eignung derartiger Editoren ist teilweise stark vom
konkreten Anwendungsgebiet abhängig. ? haben einen Editor entwickelt, mit dem
Prozesse und relevante Aktivitäten während eines chirurgischen Eingriffs erfasst
werden können. Tablet-PCs sind in diesen und anderen Anwendungsgebieten für
diese Erfassung besonders gut geeignet. Relevant ist dabei unter anderem, welche
chirurgischen Instrumente benutzt werden, welche anderen technischen Hilfsmittel,
wie Monitore bei endoskopischen Eingriffen („Schlüssellochchirurgie“) zum Einsatz
kommen, inwiefern die Patientenlagerung, die OP-Beleuchtung oder anderes
verändert wird. Die detaillierte Erfassung derartiger Aktivitäten liefert eine gute
Grundlage, um abzuschätzen, ob ein ausreichender Bedarf für eine Teilautomatisierung,
z.B. eine automatische Kameranachführung, besteht.
Diskussion.
Beobachtungen sind integrale Bestandteile der etablierte Prozesse, wie Contextual
Design und Scenario-Based Design. Beim Contextual Design [Holtzblatt and Beyer,
1998] liegt der Fokus darauf, den Kontext der Aktivitäten zu verstehen. Dies
betrifft vorgeschaltete, nachgelagerte oder übergeordnete Prozesse sowie den räum-
485

lichen und organisatorischen Kontext, in dem diese Aktivitäten stattfinden. Bzgl.
des räumlichen Kontextes sind z.B. Situationen besonders relevant, in denen mit
Lärm, Feuchtigkeit oder Staub zu rechnen ist, weil davon u. a. die Eignung von Einund
Ausgabegeräten abhängt. In ihrem Buch beschreiben sie so z.B. die Analyse
der Buchungs- und Bezahlungsvorgänge in Hotels und dazugehörigen Restaurants.
Eine schwer zu beantwortende Frage ist, wann Beobachtungen beendet werden sollten.
Die UI-Spezialisten sollten gründlich überlegen, was sie bisher nicht beobachtet
haben, um zu verstehen, auf welchen Gebieten weitere Beobachtungen eventuell zu
neuen Erkenntnissen führen würden.
Dass UI-Spezialisten in einem für sie neuen komplexen Anwendungsfeld alle
Beobachtungen richtig einordnen und interpretieren können, ist nicht zu erwarten.
Daher wird empfohlen, die wesentlichen Beobachtungsergebnisse schriftlich zusammenzufassen
und die Gesprächspartner zu bitten, die Ergebnisse zu überprüfen.
12.2.2 Interviews
Interviews sind gezielte Befragungen von potenziellen Benutzer oder anderen Stakeholdern
in Bezug auf ihre Aufgaben, Ansichten und Bedürfnisse. Die Ziele von
Interviews sind ähnlich zu denen einer Beobachtung. Oft werden Interviews nach
Beobachtungen durchgeführt und dienen dann in der Regel (auch) dazu, Fragen zu
diskutieren, die sich aus Beobachtungen ergeben haben. In der Regel ist man nicht
an Einzelmeinungen interessiert, sondern führt eine Serie von Interviews durch, um
ein möglichst repräsentatives Bild von Ansichten und Einschätzungen zu erhalten.
Dies führt teilweise auch dazu, dass kontroverse Ansichten zu einzelnen Fragen
deutlich werden.
Auch Interviews bedürfen einer sorgfältigen Planung. Dabei muss festgelegt werden,
was im Rahmen des Interviews diskutiert werden soll, wie das Interview ablaufen
soll, wie lange es dauern soll (günstig sind: 30 bis 60 Minuten). Bei längeren
Interviews sollten Pausen vorgesehen werden. Allzu großer Zeitdruck ist ausgesprochen
ungünstig. Die Terminplanung muss also darauf gerichtet sein, dass sowohl die
UI-Spezialisten als auch die Gesprächspartner einen kleinen zeitlichen Puffer haben.
Offene und geschlossene Fragen.
Die Detailplanung betrifft die konkreten Formulierungen der Fragen. Grundsätzlich
gibt es offene Fragen, die dem Gesprächspartner breite, quasi unbegrenzte Antwortmöglichkeiten
geben und geschlossene Fragen, bei denen die Antwortmöglichkeiten
stark begrenzt sind, z.B. Ja-Nein-Fragen. Beide Typen von Fragen sind in einem Interview
relevant. Mit geschlossenen Fragen lassen sich oft sehr effektiv relativ viele
Aspekte betrachten. Allerdings gewinnt man auf diese Weise keine tieferen Einsichten.
Offene Fragen geben dem Gesprächspartner mehr Möglichkeiten; führen
aber auch dazu, dass dieser gründlicher nachdenken muss. Oft ist es günstig, beide
486

Fragetypen gezielt zu kombinieren, z.B. indem zunächst erfragt wird, ob der Gesprächspartner
generell mit einer bisherigen technischen Lösung zufrieden ist und
dann nachgefragt wird, womit er speziell zufrieden oder unzufrieden ist.
Strukturierte, semi-strukturierte und offene Interviews.
Eng verknüpft mit der Art der Fragen ist die Art des Interviews. An einem Ende des
Spektrums stehen strukturierte Interviews. Dabei sind alle Fragen geschlossene Fragen
– sie sind wörtlich exakt vorformuliert. Mit derart fixierten Fragebögen arbeitet
man vor allem in der Markt- und Meinungsforschung.
Am anderen Ende des Spektrums ist ein offenes Interview lediglich durch eine
kurze Checkliste von Themen vorbereitet, die angesprochen werden sollen. Diese
Form des Interviews ist sehr anspruchsvoll für den UI-Spezialisten, da auf viele
Antworten spontan und flexibel reagiert werden muss. Semi-strukturierte Interviews
enthalten offene und geschlossene Fragen und nutzen vor allem bei offenen Fragen
gezielte Nachfragen. In der Praxis ist dieser Typ des Interviews am weitesten verbreitet
und am ergiebigsten.
Gesprächsführung.
Die Gesprächsführung bei derartigen Interviews ist nicht einfach, besonders in Situationen,
in denen sich die Beteiligten nicht kennen. Schwierig sind auch Situationen,
in denen sich die Partner in einem solchen Interview nicht als ebenbürtig empfinden,
z.B. wenn ein hochangesehener ärztlicher Direktor interviewt werden soll,
der evtl. erkennbar viel Wert auf seinen Status legt. Wichtig ist es auch, Benutzer und
deren Ängste zu berücksichtigen – diese sind oft von einer neuen technologischen
Unterstützung wenig begeistert. Sie fragen sich z.B, ob schwierige Anforderungen
(Angst vor Überforderung) auf sie zukommen, ob ihr Arbeitsplatz „wegrationalisiert“
werden soll.
Wichtig ist also, Vertrauen zu schaffen, Klarheit über die Ziele des Interviews
herzustellen und das Gespräch mit relativ einfachen Fragen zu eröffnen. Ein Interview
bietet im Unterschied zu schriftlichen Befragungen die Gelegenheit spontan
zu reagieren, bei interessanten Informationen nachzufragen oder sogar „nachzuhaken“.
Abhängig vom Temperament des Gesprächspartners und dessen Vertrautheit
mit den Fragen kann es teilweise schwierig sein, den Partner „zum Reden zu bringen“.
In anderen Fällen muss man eher abbremsen, damit in der vorgesehenen Zeit
auch tatsächlich alle wesentlichen Fragen angesprochen werden können. Für die ersten
Interviews muss generell mehr Zeit eingeplant werden; in späteren Interviews
ist mit weniger neuen Einsichten zu rechnen.
487

Erfassen von Problemfällen.
Ähnlich wie bei Beobachtungen ermöglichen Interviews auch wichtige Ausnahmesituationen
und Problemfälle zu verstehen, in denen von einem Standardvorgehen
abgewichen wird. Die Gesprächsführung sollte darauf abzielen, solche Problemfälle
zu antizipieren und gezielt nachzufragen. Diese Nachfragen können z.B. darauf
gerichtet sein, wie unter besonderem Zeitdruck gearbeitet und entschieden wird
(Was macht die Notaufnahme eines Krankenhauses wenn alle Operationsäle belegt
sind?), wie wird vorgegangen, wenn eine Person im Team nicht verfügbar ist oder
eine benötigte technische Unterstützung versagt. Professionelle Softwareentwickler
integrieren ein umfangreiches Exception handling, also die Reaktion auf Ausnahmen,
in ihre Quelltexte. In ähnlicher Weise sollen Ausnahmen beim Vorgehen der
Gesprächspartner in ihrer Domäne erkannt werden.
Flexibilität.
Prinzipiell muss in einem Interview nicht unbedingt eine feste Zahl an vordefinierten
Fragen „abgearbeitet“ werden, zumal der Ablauf eines solchen Gesprächs ja nur
in Grenzen vorhersehbar ist und das Nachfragen bei unerwarteten Antworten oft
besonders ergiebig ist. Daraus sollte man aber nicht schließen, dass die Mühe gezielt
konkrete Fragen vorzubereiten, nicht lohnenswert ist. Gerade Gesprächspartner,
die wenig Zeit haben und sehr effektives Arbeiten gewohnt sind, schätzen es
nicht, wenn der UI-Spezialist offenbar mühselig Fragen formuliert, die offensichtlich
nicht durchdacht waren und ein Gespräch führen, dass eher den Charakter einer
unverbindlichen Plauderei hat. Flexibilität in der Gesprächsführung ist also wichtig;
das Interview sollte nicht zu starr festgelegt sein, aber die Ziele des Interviews und
die daraus abgeleiteten Fragen müssen im Vorfeld durchdacht werden.
Praktisches Vorgehen.
Wie bei Beobachtungen stellt sich die Frage, ob das Gespräch aufgezeichnet werden
kann. Wenn eine akustische Aufzeichnung möglich ist, sollte auch angeboten
werden, die Aufnahme jederzeit auf Wunsch zu unterbrechen oder abzubrechen.
Falls das nicht angemessen erscheint oder nicht möglich ist, ist es günstig, wenn
das Interview von zwei Personen durchgeführt wird, wobei sich jeweils eine sich auf
die Notizen konzentriert und die andere auf die Gesprächsführung. Auch bei aufgezeichneten
Interviews ist es von Vorteil, wenn zwei Personen das Interview durchführen,
weil dadurch mit größerer Wahrscheinlichkeit relevante Nachfragen erfolgen.
Ähnlich wie bei Beobachtungen ermöglicht die Befragung im Team Beobachtungen
während des Interviews und die Interpretation des Interviews zu diskutieren.
Gerade, wenn Haltungen und Einstellungen zu bestimmten Fragen, im Mittelpunkt
stehen, kann es wichtig sein, gut zu beobachten, wie etwas gesagt wurde. Dabei ist
auch zu berücksichtigen, dass derartige Interviews einen offiziellen Charakter haben
488

– es ist also nicht verwunderlich, wenn Gesprächspartner dabei so antworten, wie
sie glauben, dass dies von ihnen erwartet wird und nicht unbedingt so, wie sie das
völlig unbefangen tun würden. Die akustische Aufzeichnung verstärkt tendenziell
bei Gesprächspartnern den Eindruck eines offiziellen Vorgangs, bei dem vor allem
korrekt (im Sinne der Erwartungen anderer) geantwortet werden sollte.
Ähnlich wie bei Beobachtungen ist auch bei Interviews die Frage, wann diese
Aktivität beendet werden sollte. Eine plausible und häufige Empfehlung lautet, dass
zwei bis drei Gesprächspartner jeder Stakeholder-Gruppe interviewt werden sollten.
Bei der Gestaltung eines e-Learning-Systems für Automonteure wären dies mindestens
die Gruppe der Automonteure, Mitarbeiter aus der Qualitätssicherung und Mitarbeiter
mit Leitungsverantwortung, die generell an der Einführung neuer Technologien
in ihrem Bereich beteiligt werden müssen. Im Contextual Design [Holtzblatt
and Beyer, 1998] spielen Interviews eine wichtige Rolle. Dort wird vorgeschlagen,
je zwei bis drei Stakeholder aus vier bis sechs repräsentativen Einrichtungen zu befragen.
Dies würde z.B. bedeuten, dass etwa 15 Assistenzärzte und 15 Fach- bzw.
Oberärzte aus fünf Krankenhäusern befragt werden müssten, um neue Software in
einem medizinischen Spezialbereich zu entwickeln. Die Verfügbarkeit dieser möglichen
Gesprächspartner schränkt diese Zahl normalerweise auf kleinere Werte ein.
Eine weitere Parallele zu Interviews besteht darin, dass es nicht selten zu Missverständnissen
kommt. Insofern sollte Zeit eingeplant werden, um die wesentlichen
Ergebnisse eines (semi-strukturierten oder offenen) Interviews zusammenzufassen,
um dem Gesprächspartner Gelegenheit zu geben, auf etwaige Missverständnisse
hinzuweisen.
12.2.3 Schriftliche Befragungen
Schriftliche Befragungen ermöglichen es, Meinungen und Bedürfnisse einer größeren
Gruppe von Benutzern zu erfassen. Dies ist teilweise sehr hilfreich, um die
Relevanz bestimmter Features für eine Software verlässlich einschätzen zu können
bzw. um zu erkennen, für welche Benutzergruppen bestimmte Features besonders
wichtig sind. Die erfolgreiche Gestaltung schriftlicher Befragungen ist allerdings
komplex und schwierig. Die Schwierigkeiten betreffen:
• die organisatorische Vorbereitung der Befragung,
• die Gestaltung von Fragebögen, sowie
• die Auswertung und Interpretation.
Diese Situation ist ähnlich wie bei der Vorbereitung von Interviews. Speziell
stark strukturierte Interviews müssen ähnlich vorbereitet werden wie schriftliche
Befragungen. Allerdings kommt hinzu, dass ungünstige Entscheidungen, die bei einem
Interview leicht korrigiert werden können, hier schwerwiegendere Folgen haben.
In der Vorbereitung sollte auch durchdacht werden, wie die Analyse und der
Entwurf von Lösungsvarianten parallel dazu durchgeführt werden kann, ehe alle Ergebnisse
vorliegen.
489

12.2.3.1 Organisatorische Vorbereitung der Befragung
Die organisatorische Vorbereitung dient vor allem zwei Zielen:
• Identifikation einer ausreichend großen Anzahl repräsentativer Benutzer inklusive
von Adressen bzw. Kontaktdaten,
• Motivation der Benutzer zur Teilnahme an der Befragung, damit eine ausreichend
hohe Rücklaufquote erreicht wird.
Was eine „ausreichend große Zahl“ an repräsentativen Benutzern ist, hängt vor
allem davon ab, wie die Daten ausgewertet werden sollen. Grundlegende Überlegungen
der Statistik machen klar, dass Ergebnisse statistisch sehr unsicher ist, wenn
die Stichprobe klein ist. Es muss berücksichtigt werden, dass selbst in günstigen
Fällen, die Rücklaufquote bei schriftlichen Befragungen weit unter 100% liegt –
die Stichprobe also wesentlich kleiner sein wird als die Anzahl der angeschriebenen
Personen.
Eine Firma wird über ihren Außendienst versuchen, möglichst viele Kundendaten
zu pflegen. Eventuell können Berufsverbände angesprochen werden, ob es Mitglieder
gibt, die der Weitergabe ihrer Daten für derartige Befragungen zustimmen.
Wichtig ist bei der Auswahl von Testpersonen der Grundsatz „Masse statt Klasse“.
Benötigt werden also Testpersonen, die tatsächlich als Benutzer in Frage kommen
– nicht andere, leichter zugängliche Personen, die in ihren Merkmalen nur entfernte
Ähnlichkeit mit den „echten“ Benutzern haben. Studenten eines Fachs sind z.B.
kein adäquater Ersatz für ausgebildete Spezialisten mit langjähriger Erfahrung (weder
persönliche Merkmale wie Alter, Familienstand und persönliche Werte noch Bedürfnisse
in Bezug auf technologische Unterstützung sind ähnlich). Die Motivation
der Benutzer zur Teilnahme zu erreichen, ist aus zwei Gründen wichtig:
• von der Motivation hängt die absolute Zahl an auszuwertenden Fragebögen ab
und
• die Rücklaufquote beeinflusst die Aussagekraft der Ergebnisse.
Der erste Aspekt ist offensichtlich: die statistische Aussagekraft einer Stichprobe
hängt von der Größe der Stichprobe ab. Der zweite Aspekt bedarf einer Erläuterung.
Die Aussagekraft von Befragungen steht und fällt damit, ob die Ergebnisse repräsentativ
sind, die Aussagen, die sich anhand der Stichprobe machen lassen also auf
die viel größere Gruppe der potenziellen Benutzer übertragen lassen. Eine Auswertung,
die sich auf 80 Personen bezieht, wobei 100 Personen angeschrieben wurden,
ist deutlich aussagekräftiger als eine Auswertung, bei der 80 von 500 angeschriebenen
Personen antworten. In vielen Fällen muss man annehmen, dass die Antworten
der an der Umfrage teilnehmenden Personen anders ausfallen als die Antworten
derjenigen, die die Befragung ignorieren. Personen, die glauben, dass sie von der zu
entwickelnden technischen Entwicklung keine Vorteile haben oder die dieser Entwicklung
gegenüber gleichgültig sind, werden an der Befragung tendenziell nicht
teilnehmen – diese Meinungen sind bei niedriger Rücklaufquote also unterrepräsentiert.
Technologiebegeisterte Personen, die den Eindruck gewinnen, hier auch ihre
Zukunft ein Stück mitzugestalten, werden eher überrepräsentiert sein.
490

Wie kann die Motivation nun beeinflusst werden? Grundsätzlich muss die Teilnahme
so einfach wie möglich sein; sie darf keinesfalls für den Befragten mit Kosten
verbunden sein und die Befragten müssen die Befragung als wichtig empfinden.
Erfahrungen zufolge hängt die Motivation von folgenden Faktoren ab:
• von der Unterstützung durch das eigene Management bzw. durch die Leitung
der Kundenorganisation (Amtsleiter, Geschäftsführer) signalisiert durch Inhalt
und Formulierung des Anschreibens,
• von der Leichtigkeit, den Fragebogen zurückzuschicken (adressierte und frankierte
Briefumschläge beilegen),
• vom Umfang des Fragebogens,
• von der Einfachheit den Fragebogen auszufüllen, insbesondere von Hinweisen
zum Ausfüllen,
• von der Nennung konkreter Ansprechpartnern mit Kontaktdaten und
• von der möglichen Kenntnis der Ergebnisse der Befragung.
Darüber hinaus werden Personen oft durch kleine Geschenke, z.B. Gutscheine
oder Teilnahme an Verlosungen zur Teilnahme, motiviert. Die zu erwartenden
Rücklaufquoten sind – selbst bei Berücksichtigung aller Aspekte – eher gering. Insbesondere,
wenn die Befragten keinen engen persönlichen Kontakt zu einer Firma
bzw. dem genannten Ansprechpartner haben, ist mit einer geringen Rücklaufquote
zu rechnen (oft unter 10 %, [Benyon et al., 2005]). Bei einer Befragung von Mitarbeitern
der gleichen Firma, z.B. einer Abteilung einer Bank oder Versicherung, sind
höhere Rücklaufquoten von etwa 30 % realistischerweise erreichbar. Wenn die Unterstützung
des Managements sehr ausgeprägt ist, sind auch deutlich höhere Werte
möglich.
12.2.3.2 Gestaltung von Fragebögen
Bei der Gestaltung von Fragebögen muss durchdacht werden:
• was erfragt wird,
• wie die Fragen formuliert sind,
• wie der Fragebogen gestaltet wird,
• welche Antworten möglich bzw. wahrscheinlich sind und
• wie die Auswertung der Antworten erfolgen soll.
Hinsichtlich der ersten Frage muss auch bedacht werden, welche persönlichen
Angaben erforderlich sind. Oft sind dies Angaben zu Alter und Geschlecht sowie
zur Qualifikation und Erfahrung mit ähnlichen Systemen und Technologien. Den
Kern der Befragung bilden Fragen, die Präferenzen, Einstellungen und Bedürfnisse
charakterisieren. Verständnisfragen der Entwickler hinsichtlich von Fakten und Zusammenhängen
im Anwendungsgebiet sollten nicht durch eine Befragung geklärt
werden. Wesentlich ist bei der Gestaltung, den Umfang der Befragung im Blick zu
behalten. Der Umfang muss dabei sowohl in Bezug auf
• die Zahl der Fragen (möglichst nicht mehr als 30),
491

• den physischen Umfang des Fragebogens (möglichst nicht mehr als eine Doppelseite)
und
• die Zeit, die Benutzer für das Ausfüllen benötigen (möglichst nicht mehr als 20
Minuten)
durchdacht werden. Die genannten Zahlen sind als Richtwerte zu verstehen.
Aus diesen Gründen wird es bei der Vorbereitung darum gehen, wichtige Fragen
zu sammeln, zu strukturieren und dann streng auszuwählen, damit der Umfang in
den genannten Grenzen bleibt. Bei dieser „Verdichtung“ ist es ideal, einen oder zwei
Benutzer zu Rate zu ziehen. Benutzer werden für einige Fragen eine eindeutige und
klare Antwort haben, bei der sich zeigt, dass diese Frage nicht von vielen Benutzern
im Rahmen einer Befragung beantwortet werden muss.
Formulierung der Fragen.
Die konkreten Fragestellungen müssen für Benutzer verständlich, eindeutig und
möglichst einfach sein. Ob dieses Ziel erreicht ist, kann meist nur durch einen Test
mit wenigen Benutzern eingeschätzt werden. Einfachheit ist sehr wichtig: Benutzer
füllen Fragebögen – wenn überhaupt – in der Regel ohne größere Aufmerksamkeit
aus. Wenn sie intensiv nachdenken müssten, brechen sie oft die Beantwortung der
Fragen ab oder geben eine Antwort, die nicht intensiv durchdacht und evtl. nicht
aussagekräftig ist.
Gestaltung des Fragebogens.
Bei der Gestaltung eines Fragebogens gibt es Parallelen zur Dialog- und Formulargestaltung.
Ein Fragebogen muss übersichtlich sein, er muss optisch gut strukturiert
sein und die Fragen müssen in einer sinnvollen Reihenfolge gestellt werden,
so dass man den Fragebogen günstig sequenziell abarbeiten kann. Bei Fragen, die
eine freie textuelle Antwort erfordern, muss sorgfältig durchdacht werden, wieviel
Platz zur Verfügung steht. Fragebögen können als Faltblatt gestaltet sein, so dass die
Zeilen relativ kurz sind. Details der Gestaltung und mögliche Varianten zu diskutieren,
führt hier zu weit. Besonders ausführlich werden diese Fragen in [Oppenheim,
2000] behandelt.
Auswertung von Befragungen.
Antwortmöglichkeiten müssen gründlich durchdacht werden, damit die Beantwortung
und die Auswertung möglichst einfach ist. In der Regel sollten Fragen so gestellt
sein, dass es einige Standardantworten gibt, die der Benutzer durch Ankreuzen
bequem markieren kann. Ob eine oder mehrere Antworten angekreuzt werden können,
muss deutlich formuliert werden („Mehrere Antworten sind möglich.“).
492

Oft werden Fragen so formuliert, dass eine Aussage gemacht wird, z.B. „Handies
machen das Leben leichter.“ oder „Die Software zur Lohnbuchhaltung deckt
alle wesentlichen Anforderungen ab“ und Testpersonen gebeten werden, ihre Haltung
(Zustimmung oder Ablehnung) zu dieser Aussage anzugeben. Dafür sind Skalen
notwendig, bei der starke Zustimmung und starke Ablehnung die jeweiligen Extrempunkte
definieren. Zu überlegen ist, wieviel Zwischenstufen betrachtet werden
sollen. Üblich ist es, fünf, sieben oder neun Möglichkeiten zu betrachten, so dass in
jedem Fall ein mittlerer Wert existiert, mit dem eine Testperson angeben kann, dass
sie nicht zustimmt und nicht ablehnt. Die Eingabe einer Testperson könnte durch
Ankreuzen erfolgen (nicht so günstig bei mehr als fünf Antwortmöglichkeiten) oder
durch Angabe einer Zahl. Vorbereitete Fragebögen für die Bewertung der Zufriedenheit
von Benutzern haben die University of Maryland 1 und die University of
Cork 2 vorbereitet, wobei beide Angebote kommerziell sind.
12.2.3.3 Beispiel: Befragung von Chirurgen
Am Anfang eines größeren öffentlich geförderten Forschungsprojektes im Bereich
„Computergestützte Chirurgie“ wurde eine schriftliche Befragung von Chirurgen
durchgeführt, um Bedürfnisse, Präferenzen und bisherige Erfahrungen von Chirurgen
zu verstehen. Zuvor wurden bereits einzelne Chirurgen befragt, Operationen
beobachtet und analysiert, so dass ein grundlegendes Verständnis auf Seiten der Entwickler
vorhanden war. Teilweise gingen Meinungen bzgl. der Relevanz bestimmter
Features aber stark auseinander, so dass eine breitere Basis für Entscheidungen notwendig
wurde.
Der an dem Projekt beteiligte Chirurgieprofessor hat dazu beim Bundesverband
der Deutschen Chirurgen ein Adressverzeichnis erfragt und – aufgrund der öffentlichen
Förderung des Projektes – auch erhalten. Dieses wurde daraufhin durchsucht,
welche Chirurgen auf den in diesem Projekt relevanten Bereich der Chirurgie (Chirurgie
im Bauchraum) spezialisiert sind. Dies traf auf 501 Chirurgen zu.
Es wurde ein Fragebogen entwickelt und gestaltet, wobei fünf persönliche Fragen
(Alter, Geschlecht, abgeschlossene Facharztweiterbildung, zusätzliche Spezialisierung,
Erfahrungen mit Computerunterstützung) gestellt wurden. Zusätzlich wurden
zunächst 19 weitere Fragen vorbereitet. Nach Diskussionen mit dem beteiligten
Chirurgieprofessor konnte diese Liste auf 16 verringert werden, wobei zusätzlich
Formulierungen der Fragen und die Antwortmöglichkeiten angepasst wurden. In einem
Vortest wurde der resultierende Fragebogen an 14 Chirurgen geschickt, die den
Projektbeteiligten gut bekannt waren, so dass 13 der 14 Fragebögen zügig ausgefüllt
und zurück geschickt wurden. Daraufhin wurde der Fragebogen erneut überarbeitet.
Die Fragen nach persönlichen Angaben wurden nicht verändert. Die Liste der
anderen Fragen wurde auf 14 reduziert. Dieser Fragebogen wurde an 487 Chirurgen
(501 abzüglich der 14 aus dem Vortest) verschickt, wobei adressierte und frankierte
1 http://lap.umd.edu/quis/, Zugriff: 22. April 2009
2 http://www.ucc.ie/hfrg/questionnaires/sumi/index.html, Zugriff: 22. April 2009
493

Rückumschläge beigefügt wurden. Der Fragebogen wurde als dreispaltiges Faltblatt
von einem technischen Redakteur gestaltet; die 14 Fragen in drei Gruppen strukturiert,
wobei Zwischenüberschriften diese Strukturierung explizit machten.
Im Anschreiben wurde darauf hingewiesen, dass auf Wunsch die Ergebnisse der
Befragung zugeschickt werden. Von 105 zurückgesendeten Fragebögen waren 102
vollständig ausgefüllt und konnten ausgewertet werden (Rücklaufquote: 21 %). Die
102 Personen waren repräsentativ in Bezug auf die Alters- und Geschlechtsverteilung
(Frauenanteil: 5 % – Chirurgie ist eine männliche Domäne).
Wesentliche Ergebnisse waren Bedürfnisse in Bezug auf eine Computerunterstützung
bei Tumoroperationen. Als wesentliche wünschenswerte Merkmale wurden
besonders häufig genannt: von 60 % der Testpersonen die (semi-)automatische
Dokumentation der computergestützten Planung auf Basis geeigneter Logging-
Funktion, von 62 % die Vermessung von 3D-Modellen der Patientenanatomie hinsichtlich
Größe von Tumoren und Abständen zu Risikostrukturen, von 64 % die
Möglichkeit einen geplanten Eingriff, präoperativ am 3D-Modell sozusagen virtuell
zu erproben. Sogar 92 % waren daran interessiert, anhand eines (frei drehbaren)
3D-Modells die Lage von Tumoren und Blutgefäßen einschätzen zu können. Der
Aufwand, der mit dieser Befragung verbunden war, war erheblich. Die Ergebnisse
haben sich allerdings als zuverlässig erwiesen und waren auch für verwandte Projekte
relevant, so dass sich der Aufwand letztlich gelohnt hat. Die Befragung und
ihre Ergebnisse sind in [Oldhafer et al., 2002] dokumentiert.
12.2.3.4 Befragung mittels e-Mail oder mittels webbasiertem Formular
Befragungen mittels e-Mail oder mittels Webbasiertem Formular sind auch möglich
und gewinnen an Bedeutung nicht zuletzt weil der Aufwand dafür wesentlich
geringer ist als für eine Befragung auf dem Postweg. Die zuvor für schriftliche Befragungen
genannten Aspekte sind hierbei im Wesentlichen auch gültig. Dem deutlich
geringeren Aufwand stehen allerdings auch Nachteile gegenüber. Tendenziell
sind Benutzer, die ohnehin viele Mails bekommen, noch weniger motiviert an einer
Befragung teilzunehmen als bei schriftlichen Befragungen. Wenn ein Fragebogen
offen auf einer Webseite zur Verfügung steht, besteht durchaus Aussicht auf eine
größere Anzahl an Testpersonen, die den Test ausfüllen. Allerdings besteht dann
keinerlei Kontrolle über die Auswahl der Testpersonen. Dies ist kritisch, weil damit
die Repräsentativität der Befragung nicht gegeben ist. Das Beispiel der Befragung
von Chirurgen zeigt auch, dass elektronische Befragungen noch nicht überall
möglich sind. Bei weitem nicht alle Chirurgen haben eine e-Mail-Adresse und von
denen, die eine Mail-Adresse haben, liest ein großer Teil die Mails extrem selten.
Befragungen, bei denen in einer Mail im ASCII-Text etwas anzukreuzen sind,
sind besonders einfach in der Vorbereitung. Allerdings sind die Möglichkeiten, ein
Layout zu gestalten, damit sehr begrenzt. Generell sollten Fragebögen, die elektronisch
beantwortet werden, möglichst kurz sein – die Arbeit am Bildschirm ist immer
noch unangenehmer als die Nutzung von Papier. Spezielle Vorkehrungen sind nötig,
damit Benutzer bei e-Mail-Befragungen anonym antworten können.
494

12.3 Repräsentation der Ergebnisse
Für die weitere Entwicklung, speziell die Definition von Anforderungen und die Arbeit
an den ersten Prototypen ist es wichtig, die Analyseergebnisse prägnant darzustellen.
Verbale Beschreibungen, z.B. Ist-Szenarien, und grafische Methoden, kommen
dafür in Frage, wobei naturgemäß jede Methode Stärken und Schwächen aufweist.
12.3.1 Repräsentation mittels Szenarien
Eine Variante der Repräsentation von Ergebnissen einer Aufgabenanalyse sind Szenarien,
speziell Ist-Szenarien, die die aktuelle Sicht aus Benutzersicht in natürlicher
Sprache beschreiben. Diese Repräsentation ist besonders gut für Diskussionen mit
den Benutzern geeignet, um sich zu vergewissern, dass die Situation korrekt dargestellt
wird und dass tatsächlich die relevanten Aspekte adressiert werden. Eine klare
Sprache mit einfachen Sätzen, Begriffen aus der Anwenderwelt und eine logische
Reihenfolge der Beschreibungen sind wichtig, um dieses Potenzial auszunutzen.
Zwei Beispiele sollen die Bedeutung von Szenarien in der Analysephase verdeutlichen.
Das erste Beispiel ist in ähnlicher Form in einem Workshop auf der
Mensch-und-Computer-Tagung 2007 vorgestellt worden und war Ausgangspunkt
für die Diskussion von Anforderungen. 3 Es bezieht sich auf die scheinbar leichte
Aufgabe der Gehaltsabrechnung, die sich aber doch als erstaunlich kompliziert herausgestellt
hat. Ein Ausschnitt eines solchen Szenarios lautet:
„Ich will das Gehalt für die neue Mitarbeiterin Frau Steden überweisen. Sie hatte
im letzten Monat einen Vorschuss bekommen, der mit der neuen Zahlung verrechnet
werden soll. Sie ist zwei Tage wegen Krankheit ihres Kindes zu Hause geblieben.
Wegen eines Einsatzes am Sonnabend fallen Wochenendarbeitszuschläge an.
Mit dem bisherigen System muss ich Rückzahlungen selbst errechnen und manuell
eingeben.“
Das zweite Beispiel ist noch komplizierter. Es betrifft den möglichen Einsatz
einer Computerunterstützung bei der Behandlung von Krebserkrankungen im Halsbereich.
Durch Teilnahme an Operationen, Operationsvorbesprechungen, Studium
von Krankenakten, Operationsprotokollen und die Teilnahme an Tumorboardbesprechungen
wurden viele Fakten erhoben und in Interviews geklärt. Die wesentlichen
Erkenntnisse wurden in einem 11-seitigen Szenario zusammengefasst, wobei
ein Patient mit fortgeschrittener Tumorerkrankung, die Rolle der an der Behandlung
beteiligten Ärzte, der Informationsfluss und die Behandlungsentscheidungen
im Mittelpunkt standen. Zur Illustration dient der Anfang dieses Szenarios:
3 Workshoptitel: Identifikation und Strukturierung von Benutzeranforderungen, Workshopleiter:
Cornelia Nees, Kostanija Petrovic, Chris Peters (alle SAP)
495

„Ein Patient kommt wegen Heiserkeit und Schluckbeschwerden in die Klinik.
Klinische HNO-Untersuchung. Zunächst wird der Mund- und Rachenraum inspiziert.
Es entsteht der Verdacht auf ein Stimmlippenkarzinom. Die Stimmlippenbeweglichkeit
rechts ist eingeschränkt. Anschließend werden die Halsweichteile des
Patienten nach auffälligen Lymphknoten abgetastet. Es besteht der Verdacht auf
rechtsseitige Lymphknotenmetastasierung. Zur weiteren Diagnostik und zur Beurteilung
der Lymphknoten wird der Patient zur Computertomographie geschickt. Ein
Termin hierfür ist innerhalb von 7-10 Tagen verfügbar. Am Tag nach dem CT soll
eine Panendoskopie (Einführung eines Endoskops in den Rachen.) zur Entnahme
einer Gewebeprobe durchgeführt werden. Computertomographie. Zur weiteren
Abklärung der Lymphknotensituation und der Tumorausdehnung wird ein CT des
Patienten aufgenommen. Zusammen mit den CT-Schichtbildern erhält der Chirurg
einen textuellen Befund des Radiologen, welcher die Art des Tumors, die Ausdehnung
des Tumors im CT sowie das Vorhandensein großer Halsmetastasen angibt.
Ein CT wird gegenüber der Kernspintomographie bevorzugt, weil der Verdacht auf
Knochen- oder Kehlkopfinfiltration besteht.“
Dieses Beispiel ist eines von mehreren Beispielen, szenariobasiert chirurgische
Planungs- und Trainingssysteme zu entwickeln. Die Szenarien haben intensive Diskussionen
über das aktuelle Vorgehen sowie über Möglichkeiten und Grenzen einer
Computerunterstützung ermöglicht. Die Szenarien sind dabei jeweils im Vorfeld der
Treffen verschickt worden, quasi als Hausaufgabe für die beteiligten Ärzte. Es wurden
mehrere Treffen vereinbart, die ausschließlich dem Ziel dienten, Szenarien zu
diskutieren, zu verfeinern und Anregungen für die Entwicklung zu sammeln.
Diese Erfahrungen sind in [Cordes et al.] zusammengefasst. Das konkrete Beispielszenario
war Bestandteil der Entwicklung des NeckSurgeryPlanners [Janke
et al., 2006], der zunächst als Forschungsprototyp konzipiert wurde und nach längerer
klinischer Erprobung mittlerweile zu einem Produkt weiterentwickelt wird.
12.3.2 Hierarchische Aufgabenanalyse
- Objektorientierte Analyse (HTA ist prozessorientiert und damit keine direkte Unterstützung
für einen objektorientierten Entwurf [Booch et al., 2007, Jacobson,
1992]. Da grafische Benutzungsschnittstellen in der Regel objektorientiert realisiert
werden, ist eine direktere Unterstützuung dafür in der Analysephase sinnvoll.
- die Hierarchie ist teilweise nur eine grobe Annäherung an die Realität. Diaper
and Stanton [2003] schlagen eine systemische Aufgabenanalyse vor, die unter
anderem den Zwang zu strikten Hierarchien vermeidet.
496

Performance-Modelle.
12.3.3 Prozessmodellierung und Workflow-Manangement
Die Beschreibung des Ist-Zustandes mittels Prozessmodellen ist weit verbreitet,
insbesondere für die Unterstützung organisatorischer Prozesse (Geschäftsprozessmodellierung),
in der Fabrikautomatisierung, aber auch in der computergestützten
Chirurgie. Die Modellierung von (Geschäfts-)prozessen ist oft Ausgangspunkt für
eine Reorganisation oder Optimierung, wobei eine Computerunterstützung oft einen
wesentlichen Aspekt darstellt. Die Prozessmodellierung ist nicht nur für eine Softwareentwicklung
relevant, sondern kann beispielsweise auch für Zertifizierungen
verwendet werden. Insofern sind gerade im betrieblichen Umfeld evtl. bereits Prozessmodelle
vorhanden, die zumindest partiell notwendige Informationen für die
User Interface-Entwicklung beinhalten. Neben der Charakterisierung von Aktivitäten
und Abhängigkeiten werden dabei häufig auch die Verantwortlichkeiten festgehalten.
Verbreitete Prozessmodelle sind
• zeitlich oder
• hierarchisch
organisiert.
Die zeitliche Organisation stellt Prozesse als Menge von Aktivitäten dar, die
zeitlich überlappen können. Eine grafische Darstellung mit horizontalen Aktivitäten
ist dafür üblich (auch „Schwimmbahndarstellung“ genannt). Ähnlich wie bei
einer performance-orientierten Aufgabenmodellierung dient die Erfassung der zeitlichen
Aspekte ggf. auch dazu, Potenzial für eine Beschleunigung zu identifizieren.
Setup- oder Rüstzeiten, Arbeitszeiten, Liege- und Ausfallzeiten sind daher typische
Begriffe einer Prozessmodellierung.
Eine logik-orientierte Darstellung betont dagegen logische Zusammenhänge zwischen
den Aktivitäten, wie z.B. das Verschmelzen von Aktivitäten oder Aufzweigungen
abhängig von bestimmten Entscheidungen bzw. Bedingungen.
Eine Gegenüberstellung beider Prozessmodelle anhand eines Beispiels aus der
Herzchirurgie ist in Abb. 12.4 dargestellt. Prozesse können mit einander verknüpft
sein, z.B. indem ein Prozess einen anderen initiiert. Bei der Modellierung derartiger
Verkettungen werden auch die Prozessschnittstellen beschrieben, so dass deutlich
ist, welche Daten, Materialien oder Informationen „übergeben“ werden. Auch eine
Vielzahl anderer Notationen und graphischer Darstellungen ist verbreitet, unter
anderem aus der Informatik bekannte Darstellungen, wie Programmablaufpläne.
Granularität.
Eine wichtige Frage bei der Prozessmodellierung betrifft die Granularität der Modelle.
Wie in anderen Bereichen auch kann die Detaillierung auf einem hohen Niveau
erfolgen und beinhaltet dann Aktivitäten, die relativ lange dauern oder auf einem
detaillierten Niveau, beispielsweise im Sekundenbereich. Der User Research-
497

Abb. 12.4: Als Ausgangspunkt für die Entwicklung chirurgischer Assistenzsysteme
wurden Prozessmodelle der Bypasschirurgie erstellt. Links die zeitlich orientierte
Darstellung, rechts die logikorientierte-Darstellung. (Mit freundlicher Genehmigung
von Oliver Burgert und Thomas Neumuth, ICCAS Leipzig).
Spezialist muss also bewusst entscheiden, welche Prozesse bzw. Teile von Prozessen
sehr detailliert beschrieben werden und welche stärker abstrahiert werden. Eine
Kombination verschiedener Granularitäten ist oft angemessen.
Die Geschäftsprozessmodellierung ist in typischen betrieblichen Kontexten weit
verbreitet. Dies gilt auch für Krankenhäuser, wo – mittels Softwareunterstützung
– komplexe Verwaltungs- und Abrechnungsprozesse durchlaufen werden (Verwaltung
von Untersuchungsterminen und -ergebnissen, Abrechnung mit Kostenträgern).
Erst in jüngster Zeit ist auch versucht worden, komplexe chirurgische Eingriffe
zu modellieren und zu optimieren. Eine Arbeitsgruppe an der Universität Leipzig
hat in 20 klinischen Projekten mit Partnern aus dem In- und Ausland auf Basis
von etwa 700 Beobachtungen Prozessmodelle für chirurgische Abläufe erstellt.
Diese Modelle sind hochkomplex, weil an Operationen neben den Chirurgen auch
Anästhesisten und andere Spezialisten beteiligt sind. Die gewählten Beispiele sind
besonders aufwändige und damit auch teure Eingriffe, wie z.B. Herzklappenoperationen
oder neurochirurgische Eingriffe. Es wird dabei nicht nur erfasst, welche
Handgriffe durchgeführt werden, sondern auch welche chirurgischen Strategien auf
Basis welcher Informationen ausgewählt werden.
Ähnlich wie in der traditionellen Geschäftsprozessmodellierung dienen diese
Modelle einerseits dazu, die bestehenden Prozesse optimal zu unterstützen, andererseits
aber auch dazu, die Prozesse zu hinterfragen und ggf. Verbesserungen anzuregen.
[?] und [?] geben einen guten Überblick über diese Arbeiten, die große
Beachtung gefunden haben.
Workflow-Management.
Basierend auf einer Modellierung von Abläufen ist eine spezielle technologische
oder informationstechnische Unterstützung dieser Abläufe möglich. Dafür ist der
Begriff Workflow-Management üblich. Für die Spezifikation dieser Systeme werden
ähnliche Notationen genutzt, wie für die Prozessmodellierung. Eine weitreichende
technologische oder informationstechnischer Workflowunterstützung ist nicht unproblematisch,
weil sie unter Umständen nicht flexibel genug ist, um auf notwendige
Änderungen reagieren zu können. Starre Prozesse laden außerdem nicht dazu
ein, kreativ über Verbesserungen nachzudenken.
498

12.4 Analyse von Benutzern
Neben der Aufgabe ist es wichtig, Benutzer kennen zu lernen und zu verstehen. Dabei
steht im Vordergrund zu eruieren, welche Vorkenntnisse, Erfahrungen und Erwartungen
typische Benutzer haben, welche kulturellen Hintergründe zu beachten
sind. Die Verteilung der Benutzer auf Altersgruppen und Geschlechter und ihre typische
Ausbildung sind weitere Aspekte dieser Analyse. Ziel ist es typische Klassen
von Benutzern mit ähnlichen Eigenschaften zu identifizieren, so dass die Entwicklung
gezielt auf diese Benutzer zugeschnitten werden kann.
Die Analyse von Benutzern bietet nicht nur eine wichtige Orientierung für den
Systementwurf, sondern gibt auch Hinweise auf einen möglichen Schulungsbedarf.
Der Erfolg einer Software, mit der komplexe Probleme gelöst werden, hängt auch
davon ab, dass der Bedarf an Schulungs- und Trainingsmaßnahmen korrekt eingeschätzt
wird.
12.4.1 Gruppen von Benutzern
Auf verschiedenen Ebenen muss verstanden werden, welche Arten von Benutzern
relevant sind (vgl. [Herczeg, 2009a]). Eine Ebene betrifft die Erfahrung der Benutzer
mit dem System.
Klassifikation von Benutzern nach Erfahrung.
Bezüglich der Erfahrung wird unterschieden zwischen:
• Anfängern,
• Gelegenheitsbenutzern,
• routinierten Benutzern und
• Experten
Anfänger beginnen ein System zu nutzen und versuchen, aufgrund von Erfahrungen
mit anderen, als ähnlich wahrgenommenen Systemen zum Erfolg zu kommen.
Gelegenheitsbenutzer nutzen ein System relativ selten, so dass sich kaum ausgeprägte
Gewohnheiten entwickeln und Besonderheiten leicht vergessen werden.
Routinierte Benutzer arbeiten häufig und lange mit einem System und kennen es
dementsprechend gut. Die effiziente Nutzung der Funktionen wird für diese Gruppe
wichtiger als unmittelbar verständliche Bedienelemente. Experten sind routinierte
Benutzer, die ein System „ausreizen“, also bis an die Grenzen gehen wollen,
möglichst stark automatisieren und häufig intensiv individualisieren. Benutzer unterscheiden
sich in ihren Bedürfnissen an die Benutzungsschnittstelle erheblich abhängig
von dieser Einteilung.
Für eine konkrete Systementwicklung ist wichtig abzuschätzen, welche dieser
Benutzergruppen tatsächlich vorkommt und wie sich etwa das zahlenmäßige Ver-
499

hältnis darstellt. Bei einem Bankautomaten oder einem Fahrscheinautomat wird es
vor allem Gelegenheitsbenutzer geben. Bei einem öffentlichen Informationsservice
z.B. über Sehenswürdigkeiten oder Quartiere wird dies ähnlich sein – dauerhafte
tägliche Benutzung ist nicht zu erwarten. Bei professionellen Systemen, die den
Kern einer spezialisierten Berufstätigkeit unterstützen sollen, spielen routinierte Benutzer
und Experten dagegen eine entscheidende Rolle.
Klassifikation von Benutzern nach organisatorischen Rollen.
In der Regel müssen verschiedene Klassen von Benutzern betrachtet werden. An
Hochschulen wird z.B. Software genutzt, um Informationen über Studienpläne verfügbar
zu machen, z.B. auf der Basis des World Wide Web. Diese Software wird
von Studenten benutzt, die sich einen Stundenplan zusammenstellen wollen. Lehrende
können sich auf diese Weise darüber informieren, wann ihre eigenen Veranstaltungen
bzw. die ihrer Kollegen stattfinden. Im Prüfungsamt und in den Sekretariaten
wird die Software genutzt, um Statistiken zu erstellen und Berichte vorzubereiten.
Jede Benutzergruppe hat andere Ziele, sucht nach anderen Kriterien, hat unterschiedliche
Vorkenntnisse und eine unterschiedliche Einstellung zu Computern.
So sind Studenten in der Regel jung, haben sehr gute Augen und können auch relativ
viele Details bzw. kleine Schrift gut wahrnehmen. Dies könnte genutzt werden,
um möglichst viele Informationen auf einen Blick verfügbar zu machen. Für die
60jährige Sachbearbeiterin im Prüfungsamt mit evtl. deutlich reduzierter visueller
Wahrnehmung stellt die gleiche Darstellung von Informationen unter Umständen eine
Überforderung dar. Bei der Analyse von Benutzern muss festgestellt werden, wie
viele Benutzer den Gruppen angehören, wie häufig sie die Software nutzen und welche
Bedürfnisse bzw. Merkmale besonders relevant sind. Da aus Kapazitätsgründen
nicht alle Bedürfnisse aller Gruppen berücksichtigt werden können, müssen Prioritäten
gesetzt werden – im geschilderten Beispiel hoffentlich in der Weise, dass die
Bedürfnisse der Studenten die höchste Priorität besitzen.
Bei betrieblicher Software sind organisatorische Rollen der Benutzer oft sehr
klar definiert. Stellenbeschreibungen geben Hinweise auf das Niveau der Tätigkeiten
und die Qualifikation der Mitarbeiter. Allerdings reicht die Analyse der Benutzergruppen
„nach Aktenlage“ keinesfalls aus, um ein Verständnis aller relevanten
Aspekte zu gewinnen.
12.4.2 Aspekte der Analyse
Folgende Aspekte der Anwender sollten erfasst werden:
1. Alter, Geschlecht
2. Körperliche Fähigkeiten, Behinderungen
3. Ausbildung (allgemeines Ausbildungsniveau und spezifische Schulungen)
500

4. Motivation
5. Computervertrautheit
6. Vertrautheit mit dem Problem bzw. Anwendungsgebiet
7. Intensität der Anwendung (Wie oft und wie intensiv wurden vergleichbare Aufgaben
mit anderen Systemen oder manuell erledigt?)
8. Kulturkreis (z.B. unterschiedliche Semantik von Farben und Icons)
Die Zugehörigkeit zu verschiedenen Gruppen bzgl. dieser Aspekte kann unterschiedliche
kognitive und motorische Fähigkeiten bedingen. Dies kann z.B. folgende
Eigenschaften betreffen:
1. Lernen und Problemlösung (eher systematische Herangehensweise oder Ausprobieren)
2. Entscheidungsfähigkeit
3. Strategien für das Suchen und Auswählen
Diese wiederum werden von verschiedenen Faktoren beeinflusst, wie:
1. Ablenkung (Wodurch werden Benutzer häufig abgelenkt?, Wie lange arbeiten
sie durchschnittlich hintereinander?)
2. Menge der zu merkenden Informationen
3. Kenntnis von Ergebnissen
4. Monotonie, Langeweile
5. Angst, Furcht, Isolierung
Die Diskrepanz zwischen denjenigen, die eine Benutzungsschnittstelle entwerfen
und entwickeln und den späteren Benutzern ist häufig sehr groß in Bezug auf die
obigen Kriterien. Daher ist es für Entwickler schwierig, Bedienung und Dokumentation
auf dem „richtigen“ Niveau zu realisieren und zu erklären. Ein konkretes Beispiel:
wenn eine Benutzergruppe überwiegend geschult darin ist, „blind“ und sehr
schnell mit der Tastatur zu arbeiten, ist eine Benutzungsschnittstelle, bei der alle
wesentlichen Aktionen über Mausklicks realisiert sind, nicht passend.
12.4.3 Ethnografische Studien
Die oben genannten Aspekte bzw. Fragen werden in den meisten Fällen in Interviews
geklärt. Konkrete Fragestellungen und passende Antwortmöglichkeiten sind
einigen Usability Engineering-Büchern dargestellt, z.B. in [Mayhew, 1999]. Teilweise
reicht eine derartige Vorgehensweise nicht aus, um das Verhalten von Benutzern
tiefgründig zu verstehen. In solchen Fällen sind ethnografische Studien, bei denen
einzelne Benutzer über einen längeren Zeitraum beobachtet und befragt werden,
um ihren Lebensstil zu verstehen. Derartige Studien werden auch als Milieustudien
bezeichnet. Diese aufwändige Vorgehensweise ist z.B. notwendig, wenn interaktive
Systeme für eine gänzlich unvertraute Region bzw. Bevölkerungsgruppe entwickelt
wird, z.B. mobile Gesundheitsdienste für afrikanische Länder [White, 2008, Marsden,
2008] oder Spiele für relativ kleine Kinder.
501

12.4.4 Personas: Fiktive Benutzer
Eine besonders intensive Benutzeranalyse wurde 1999 von Cooper [1999] vorgeschlagen.
COOPER empfiehlt fiktive Benutzer umfassend zu charakterisieren, um
auf dieser Basis Entwurfsentscheidungen zu diskutieren. Diese umfassenden Beschreibungen
beinhalten auch das Freizeitverhalten, Haltungen dieser fiktiven Benutzer,
die nicht unmittelbar für das zu entwerfende System relevant sind. Sie werden
Persona’s genannt. Pruitt and Grudin [2003] nennen u.a. das Leseverhalten und
Lernstile als wichtige Bestandteile von Persona-Beschreibungen. Herczeg [2009a]
erwähnt die Familienverhältnisse, Sprachkenntnisse, Nationalität, Ausbildung und
Beruf. Persona’s beinhalten Zitate, die die Haltung der fiktiven Person deutlich
machen. Diskussionen über Auswirkungen von Design-Entscheidungen werden dadurch
sehr konkret, auch etwas emotionaler als wenn es um mutmaßliche prozentuale
Anteile einer Zielgruppe geht.
Persona’s werden hier erwähnt, weil sie in der Industrie mittlerweile relativ verbreitet
sind, weil umfassende Erfahrungen und Erfahrungsberichte existieren, die
deutlich machen, dass es sich um eine praktikable und praxisrelevante Methode handelt.
Ähnlich wie Aufgabenmodelle und Workflowdiagramme auf Daten der Aufgabenanalyse
basieren, steht und fällt der Wert von Personas mit ihrer Zuverlässigkeit
und Valididität und damit mit den Daten, auf denen sie aufbauen. Negative Erfahrungen
in der Nutzung von Persona’s beziehen sich vor allem auf Beschreibungen,
bei denen kein ausreichender und klarer Bezug zu Daten vorhanden ist.
Pruitt and Grudin [2003] schlagen vor, Daten aus der Marktforschung, Daten
von Beobachtungen und Befragungen der Benutzer dafür zu nutzen. Persona’s charakterisieren
vorrangig die Benutzer, während Szenarien vorrangig die Aktivitäten
charakterisieren, ohne Benutzer mehr als dafür notwendig zu beschreiben. Um Persona’s
effektiv für die weitere Entwicklung zu nutzen, empfiehlt es sich, diese nicht
nur verbal zu beschreiben, sondern mittels Postern und Flyer auch visuell auf diese
Beschreibungen aufmerksam zu machen, wobei Fotos der repräsentierten Benutzer
eine sinnvolle Ergänzung darstellen. Offensichtlich ist, dass Persona’s genutzt
werden, um die typischen Benutzergruppen zu charakterisieren. Im Sinne einer Abgrenzung,
die für Design-Entscheidungen auch wichtig ist, wird auch vorgeschlagen
Anti-Persona’s zu entwickeln – Benutzer, auf die die Entwicklung nicht zugeschnitten
ist [Cooper et al., 2007, Pruitt and Grudin, 2003].
Wie bei jeder Methode ist die Frage nach Aufwand und Nutzen zu stellen. In der
Regel sollten nicht mehr als vier bis sechs Personas entwickelt werden, da sonst der
Aufwand sehr groß wird, ohne dass dem ein vergleichbarer Nutzen gegenüber steht.
Wer hier zum ersten Mal von Persona’s liest, ist möglicherweise befremdet von
einer derartigen Vorgehensweise. Die Frage, inwiefern fiktive Personenbeschreibungen,
einen Softwareentwurf signifikant verbessern können, ist nicht von der Hand
zu weisen. Pruitt and Grudin [2003] weisen darauf hin, dass Menschen schon in
der frühen Kindheit erlernen, die Reaktion anderer Menschen auf ihr Verhalten vorherzusagen
und diese Fähigkeit intensiv nutzen und im Laufe des Lebens ständig
weiterentwickeln. Wenn man sich diesbezüglich grob verschätzt, bleibt dies als kri-
502

tische Situation in der Erinnerung haften und wir sind bestrebt, daraus zu lernen.
Die Nutzung von Persona’s nutzt diese ausgeprägte menschliche Fähigkeit.
Beispiel.
Pruitt and Grudin [2003] beschreiben ihre Erfahrungen anhand von zwei Projekten,
wobei die Entwicklung von Persona’s in einem Projekt erst spät begann und ohne
nennenswerte Ressourcen durchgeführt wurde, während in dem anderen Projekt dafür
Ressourcen in nennenswertem Umfang bereit gestellt wurden. Insofern diente
das erste Projekt eher dazu, die Methode kennenzulernen und es gelang noch nicht
in großem Umfang die Entwicklung dadurch zu prägen.
Die zweite größere Entwicklung soll kurz beschrieben werden, obwohl sie hinsichtlich
ihrer Größe nicht repräsentativ ist. Für die Weiterentwicklung von MICRO-
SOFT WINDOWS wurde ein Team von 22 Personen gebildet, das – neben anderen
Aktivitäten – Persona-Beschreibungen erstellt und verbreitet hat. Diese Personenn
hatten substanzielle Erfahrungen mit anderen Analyseaktivitäten. Die Arbeit an den
Persona’s diente nicht dazu, andere Analyseaktivitäten zu ersetzen, sondern war als
Ergänzung gedacht, die z.B. mit entsprechenden Szenarien „verlinkt“ wurde.
Sehr sorgfältig wurden eine Reihe essenzieller Fragen diskutiert. Dies betrifft
insbesondere:
• das Verhältnis von fiktiven Bestandteilen zu datenbasierten Informationen,
• den Inhalt der Persona-Beschreibungen,
• die Auswahl der Persona’s,
• die Validierung der Persona’s und
• die Beurteilung des durch die Persona’s erreichten Ergebnisse.
Speziell die Auswahl der Persona’s ist eine schwierige Entscheidung. Bei einem
Produkt für einen Weltmarkt mit sehr heterogener Verteilung der Benutzer sind
viele Aspekte zu beachten: Persona’s könnten so gewählt werden, dass sie regionale
Unterschiede, Altersunterschiede, Geschlechtsunterschiede oder Unterschiede in
kognitiven und motorischen Fähigkeiten veranschaulichen. Um die Anzahl der Persona’s
auf ein sinnvolles und übersichtliches Maß zu begrenzen, konnte nicht eine
Persona für jede Ausprägung dieser Merkmale definiert werden.
Interviews, Workshops mit Fokusgruppen, Feldstudien und Marktanalysen waren
die wesentlichsten Quellen für die Persona-Beschreibungen. Diese Rohdaten
wurden für jede Persona in einem sogenannten „Foundation“-Dokument festgehalten.
Fotos von Microsoft-Mitarbeitern wurden erstellt, um die Persona’s visuell anzureichern.
Sechs Persona’s wurden definiert, wobei jeweils zwei Teammitglieder
für eine Persona verantwortlich waren. Die Persona’s wurden mit den Rohdaten auf
vielfältige Weise verlinkt, um die Bezüge deutlich zu machen.
Die Erfahrungen wurden als sehr positiv beschrieben, wobei folgende Aspekte
als wesentlich angesehen wurden. Persona’s helfen:
• die Entwurfsentscheidungen zu diskutieren,
• die Entwurfsaktivitäten auf relevante Aspekte zu fokussieren,
503

• das Bewusstsein aller Beteiligten für Benutzer zu schärfen,
• reichhaltige Informationen über Benutzer an alle an der Entwicklung Beteiligten
(Entwickler, technische Redakteure, Manager, Tester, Marketingexperten)
zu kommunizieren und
• Marketinganalysen und andere Daten aus der Analyse, prägnant zusammenzufassen.
Insbesondere der erste Aspekt wurde bereits von Cooper [1999] betont. Diskussionen
der Art „Würde Alan dieses Feature benutzen?“ sind typisch. Um diese Diskussionen
konstruktiv zu gestalten, wurden für wichtige Features auf Basis der unterschiedlichen
Persona’s Punkte für die Relevanz vergeben, so dass eine prioritätsgewichtete
Tabelle von Features entsteht. Für den praktischen Nutzen spricht, dass
viele Entwurfsdokumente, u.a. die Spezifikationen, die Storyboards und Entwurfsentscheidungen
explizit auf die Persona’s Bezug genommen haben.
Diskussion.
Persona’s können und sollten mit anderen Methoden kombiniert werden. Insbesondere
reicht eine Persona-fokussierte Diskussion nicht aus, um komplexe Abhängigkeiten
von Aufgaben und Teilaufgaben zu verstehen. Persona’s können sowohl in
die szenariobasierte Entwicklung als auch in die kontext-basierte Entwicklung integriert
werden. Die Nutzung von Persona’s in einer partizipativen Entwicklung wird
in [Grudin and Pruitt, 2002] beschrieben. Weitere Beispiele und eine weiterführende
Diskussion zu Persona’s findet sich auch in [Herczeg, 2009a]. Cooper et al.
[2007] diskutiert ausführlich, welche Persona’s benötigt werden. Neben den Repräsentanten
der wichtigsten Benutzergruppen (primary persona’s) werden z.B. auch
Persona’s erwähnt, die solche Benutzer charakterisieren, die von einem System profitieren,
ohne es direkt zu nutzen (served persona’s).
12.5 Rahmenbedingungen
Gutes User Interface Engineering bedeutet, die Aspekte einer „guten“ Benutzungsschnittstelle
zu identifizieren, die von den Entwicklern direkt beeinflusst werden
können. Außerdem müssen andere Einflüsse oder Vorgaben identifiziert werden, die
als Rahmenbedingungen, zu beachten sind.
12.5.1 Direkte Vorgaben
Folgende Vorgaben werden häufig gemacht:
504

1. Hardware. Die Hardware-Plattform wird oft vorgegeben. Entweder aus Kostengründen
oder um die Kompatibilität mit der existierenden Umgebung zu erreichen,
ist der „Spielraum“ für die Entwicklung zumeist stark eingeschränkt.
2. Ein-/Ausgabegeräte. Nicht alle üblichen Ein- und Ausgabegeräte können in allen
Umgebungen benutzt werden. Beispielsweise gibt es Leitwarten, in denen
keine Tastaturen vorhanden sein dürfen, und Arbeitsplätze, an denen „keine
Hand frei“ ist. So müssen Navigationssysteme im Auto auch ohne Tastatureingabe
funktionieren.
3. Software-Plattform/Entwicklungsplattform. Beide können häufig nicht selbst
gewählt werden, da eine strategische Entscheidung für bestimmte Plattformen
entweder beim Auftraggeber oder auch bei der eigenen Firma die Auswahl bestimmt.
Der erforderliche Funktionsumfang bestimmt auch die Wahl der Werkzeuge
mit.
4. Preis/Implementierungsaufwand. Harte Kostenvorgaben lassen die Diskrepanz
zwischen möglichen, guten Lösungsideen und real umsetzbaren Lösungen wachsen.
5. Zeitvorgaben. Ähnliches gilt für Zeitvorgaben, die insbesondere die Experimentiermöglichkeiten
einschränken und dazu führen, dass sich die Entwickler auf
eher Bewährtes oder Bekanntes beschränken.
Ob die Erfüllung dieser Vorgaben möglich ist, kann bei Vertragsverhandlungen
mit Ja/Nein-Fragen leicht geprüft werden. Oft haben sie k.o.-Bedeutung, d.h. eine
mit „Nein“ beantwortete Frage (z.B. die Preis- oder Zeitvorgaben können nicht eingehalten
werden) beendet das gesamte Projekt.
Um sich gegen unliebsame Überraschungen abzusichern, müssen die Rahmenbedingungen
frühzeitig und vollständig eruiert und schriftlich fixiert werden. Dies
kann schwierig sein, da die Auftraggeber diese Vorgaben oft nicht rechtzeitig oder
vollständig machen können oder sie sogar während der Entwicklung ändern wollen.
Oft haben die Entwickler durchaus Möglichkeiten, diese Vorgaben zu hinterfragen
oder zu beeinflussen. Der Funktionsumfang ist oft variabler als angenommen, ebenso
Software- oder auch Hardware-Vorgaben.
Eine intensive Diskussions- und Konzeptphase sollte daher am Anfang jeder
Entwicklung stehen. Sie sollte nicht nur mit den Auftraggebern, sondern auch mit
den späteren Kunden/Benutzern geführt werden. Häufig sind Missverständnisse und
Konflikte auf ungenügende Kommunikation in diesen frühen Projektphasen zurückzuführen.
12.5.2 Unscharfe Vorgaben
Während die zuvor besprochene Gruppe von Vorgaben direkte und einfach überprüfbare
Konsequenzen hat, führt ein zweiter Typ von Vorgaben zu solchen Anforderungen
an die Benutzungsschnittstelle, deren Einhaltung nur graduell bewertet
werden können. Diese Bewertungen sind noch dazu oft vom subjektiven Empfinden
des Benutzers oder Auftraggebers abhängig. Zu diesen Kriterien gehören:
505

1. Portabilität. Oft sollen Implementierung und Schnittstellen derart realisiert werden,
dass sie leicht auf andere Plattformen portierbar sind, auch wenn diese
Portierung momentan noch nicht realisiert wird. Portierbarkeit ist bei Benutzungsschnittstellen
häufig schwieriger als bei Anwendungssoftware in einer
Standardsprache.
2. Veränderbarkeit. Es sollten Vorkehrungen für eine schnelle, unkomplizierte und
gut abgrenzbare Variation der Benutzungsschnittstelle getroffen werden. Dies
kann in einer absehbaren Änderung des Funktionsumfangs, aber auch in besseren
Anpassungsmöglichkeiten an Benutzerwünsche begründet sein.
3. Internationalisierbarkeit. Die Option, Texte und Schriften verschiedenen Sprachen
anzupassen, kann beim Entwurf wesentlich unterstützt werden. Ein variables
Geometriemanagement bei dem die Ausrichtung der Bedienelementein
Dialogenund Formularennicht durch fixe Positionen vorgegeben ist, spielt ein
wichtige Rolle, um diese Dialoge in einer anderen Sprache (mit einer anderen
Größe für Beschriftungen) nicht völlig neu entwickeln zu müssen. Zu diesem
Zweck unterstützen viele Werkzeuge relative Angaben (Widget1 ist links
an Widget2 und oben an Widget3 ausgerichtet), die erst zur Laufzeit in exakte
Koordinaten umgerechnet werden.
4. Sicherheit. Für sicherheitskritische Anwendungen (Luft- und Raumfahrt, Kraftwerke
usw.) ist fehlerfreie Bedienung, häufiges Rückversichern und Prüfen ungleich
wichtiger als für andere unkritische Anwendungsbereiche.
5. Künstlerische Gestaltung, Medieneinsatz. Vorgaben der Gestaltungsmittel, bzw.
hinsichtlich Umfang und Art in der die vorhandenen Medien eingesetzt werden.
Diese Vorgaben betreffen auch die Zusammenarbeit mit Designern sowie den
Gebrauch von Farbe und Fonts (siehe auch Styleguides).
6. Das Einhalten von Standardisierungund Styleguidesumfasst die Vorgabe von
Bedienelementenals Typ (z.B. Menüauswahl) oder das zu verwendende ToolkitindexWindow-
Manager!Motif, firmen- oder projektbezogene Richtlinien, Ergonomie- und andere
Normen Eine besondere Verbreitung hat der SAA/CUA-Standard(Systems
Applications Architecture/Common User Access) von IBM erfahren (IBM [1991]),
der die Grundlage für die Systeme von IBM und MICROSOFT bildete.
7. Die Möglichkeit, firmeninterne Styleguidesin das Werkzeug zu integrieren.
Diese Anforderungen an die Benutzungsschnittstelle werden meist vom Auftraggeber
direkt vorgegeben. Bleiben obige Punkte offen, sollten sie trotzdem von den
Entwicklern berücksichtigt und auf ihre Bedeutung im konkreten Projekt hin untersucht
werden. Einige der oben genannten Punkte, z.B. die Sicherheitsaspekte, sind
insbesondere als Zielvorgaben für Tests bedeutsam.
12.6 Anforderungsanalyse
Die Ergebnisse der Aufgabenanalyse sollten intensiv und kreativ ausgewertet werden.
Die bisherige Art und Weise, Aufgaben zu erledigen, muss nicht optimal sein.
506

Es muss nach Ergänzungen, Alternativen und Verbesserungsmöglichkeiten gesucht
werden. Benutzer können erklären, wie etwas bisher erledigt wird, was ihnen wichtig
erscheint, und lokale Verbesserungen vorschlagen – eine grundlegende Optimierung
von Prozessen kann dagegen nicht von den Benutzern erwartet werden.
Wenn diesbezügliche Ideen auftauchen, werden diese mit Benutzern und Auftraggebern
diskutiert. Die Gelegenheit einer Softwareentwicklung sollte genutzt
werden, um den Prozess der Aufgabenabarbeitung zu überdenken und gegebenenfalls
zu optimieren. Es versteht sich von selbst, dass dieser Vorgang von den Auftraggebern
und Benutzern geführt werden sollte, denn sie sind die Experten auf ihrem
Gebiet. Der unbefangene Blick eines Außenstehenden kann allerdings helfen,
die eine oder andere Schwachstelle zu identifizieren.
Insbesondere, wenn eine qualitativ neue Lösung angestrebt wird, z.B. Ersatz einer
manuellen Lösung, können viele Aufgaben erledigt werden, die in der bisherigen
Arbeit gar nicht denkbar waren und somit auch nicht Bestandteil von Aufgabenbeschreibungen
sein können. Wenn man sich in solchen Situationen zu stark
auf die bisherige Art der Erledigung von Aufgaben stützt, „zementiert“ man unter
Umständen nicht mehr zeitgemäße Strukturen.
12.6.1 Funktionale und nicht-funktionale Anforderungen
12.6.2 Szenariobasierte Beschreibung von Anforderungen
Die szenariobasierte Methode ist auch in der Beschreibung von Anforderungen von
großem Wert, weil sie eine Diskussion mit den Anwendern sehr gut unterstützt und
für Entwickler die nötigen Hintergrundinformationen liefert. Die in der Anforderungsanalyse
aufgestellten Szenarien sind dann Grundlage für die Entwicklung und
die Evaluierung, die sich auf die Bewertung der Realisierung dieser Szenarien konzentriert.
Die szenariobasierte Beschreibung von Anforderungen wird sehr präzise
und praxisorientiert in [Benyon et al., 2005] beschrieben, wobei eine schrittweise
Verfeinerung und Konkretisierung erfolgt. Benyon et al. [2005] unterscheiden vier
Typen von Szenarien, die in verschiedenen Stadien im Designprozess Anwendung
finden:
1. User Stories werden genutzt, um auf hoher Ebene zu beschreiben, wie die Benutzer
mit dem geplanten System arbeiten, einschließlich der Einbettung des
Systems in den Kontext. Insbesondere enthalten sie Begründungen und Motive
der Handelnden („Um die Auswahl geeigneter Fahrzeuge weiter einzuschränken,
wird bei der Suche noch der Kilometerstand angegeben und die Suche auf
Händler im Umkreis von 20 km eingeschränkt.“).
2. Die User Stories werden durch einen Prozess der Abstraktion und Zusammenfassung
zu Conceptual Scenarios erweitert. Diese werden genutzt, um die Anforderungen
des Systems klarer zu definieren. So werden in dieser Phase die
genutzten Eingabegeräte, Bestandteile
507

3. Für die Umsetzung der Designideen, für das Prototyping sowie für die Evaluierung
eines Systems können aus einem Conceptual Scenario mehrere Concrete
Scenarios generiert werden, die notwendig sind, um einen bestimmten Sachverhalt
bzw. eine spezielle Funktion genau zu erklären. Sie erfassen für das jeweilige
Teilproblem spezifische Besonderheiten und die Umstände, unter denen sie
auftreten.
4. Mehrere Concrete Scenarios werden wiederum zu Use Cases zusammengefasst,
welche die Interaktion zwischen den Anwendern und dem Programm präzise
beschreiben. Die erstellten Use Cases sollten die komplette Funktionalität des
Systems sowie alle notwendigen Interaktionen einschließen.
Abb. 12.5: Abhängigkeiten und Verwaltung der Szenarien. Gegenüber dem Vorschlag
von Benyon et al. haben wir bildhafte Komponenten integriert, Abhängigkeiten
explizit erfasst und eine redundanzarme Struktur (durch die Nutzung von Core
und Common Components) entwickelt
Konkrete Beispiele für den Einsatz von Szenarien in dieser Phase beziehen sich
wiederum auf die Gestaltung chirurgischer Trainingssysteme. Dabei müssen neben
dem Verständnis komplexer Anwendungsprobleme die Lerninhalte und Lernziele
definiert, strukturiert und angemessen vermittelt werden. Das Verständnis des oft
impliziten Expertenwissens und die Bewertung des Lernerfolgs sind besondere Herausforderungen.
Die Szenarien erwiesen sich für das Design der Trainingsschritte
und bei der Auswahl und Beschreibung der Trainingsfälle als hilfreich
„Ein Facharzt möchte für seine Subspezialisierung Abdominalchirurgie die Vorgehensweise
für die Planung onkologischer Eingriffe (Krebsoperationen) an der Leber
vertiefen. Weil er sich mit diesem Gebiet lange nicht intensiver beschäftigt hat,
wählt er im LIVERSURGERYTRAINER zunächst einen einfachen Fall: die Resektion
eines Tumors in peripherer Lage. Er macht sich mit den Patientendaten und der
Anamnese des Patienten vertraut. Er erfährt, dass der Patient an mehreren Tumorerkrankungen
litt, die chirurgisch und durch Chemotherapien behandelt wurden.“
(Aus [Cordes et al., 2007])
508