Bedienbarkeit/Benutzbarkeit - auf Matthias-Draeger.info

Vorlesung "Anwendungssysteme" 

Bedienbarkeit/Benutzbarkeit 

Prof. Dr. Lutz Prechelt 

Freie Universität Berlin, Institut für Informatik 

http://www.inf.fu-berlin.de/inst/ag-se/ 

• Begriff "Benutzbarkeit" 

• Entwicklungsprinzipien 

• Direkter Kontakt zu Benutzern 

• Benutzbarkeitstesten 

• Iterativer Entwurf 

• Integrierter Entwurf 

• Fallstudie zur Verwendung der 

Prinzipien 

• Ratschläge an Organisationen 

• Ergebnisse von 

Benutzbarkeitsprüfungen 

Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 1 / 37

Aspekte von Technikgestaltung 

• Technische Zweckmäßigkeit: 

• extern sichtbar: Plattformanforderungen, Installierbarkeit, 

Laufzeiteffizienz, Speichereffizienz, Funktionalität, Flexibilität 

• intern: geringer Konstruktionsaufwand, gute Wartbarkeit, 

Wiederverwendbarkeit, etc. 

• Wünschbarkeit: 

• Gewährleistung allgemeiner passiver Anforderungen 

• z.B. Sicherheit, Verlässlichkeit, evtl. Schutz der Privatsphäre 

• Gestaltung gemäß spezifischer Wirkungs-Wünsche 

• z.B. Vermeidung negativer Wirkungen wie soziale Isolation, Monotonisierung 

von Arbeit, Erzeugung von Stress etc. 

• Die Forderung nach guter Benutzbarkeit liegt an der Schnittstelle 

dieser zwei Bereiche 


Benutzbarkeit 

• Benutzbarkeit bedeutet, dass eine Software ihre Benutzer/innen 

gut dabei unterstützt, die gewünschten Arbeitsgänge zu erledigen 

• Verständlichkeit 

• Erlernbarkeit 

• Bedienbarkeit 

• Benutzbarkeit ist ein Teilaspekt von Brauchbarkeit 

• Brauchbarkeit fordert z.B. zusätzlich, dass überhaupt die "richtigen" 

Anforderungen realisiert sind 


Benutzbarkeit und Konstruktionsprozess 

• Gute Benutzbarkeit kann nur erzielt werden, wenn ein geeigneter 

Software-Entwicklungsprozess verfolgt wird 

• Insbesondere im Bereich der Benutzungsschnittstelle 

(user interface, UI) 

• Das Vorgehen dafür ist im Prinzip bekannt, 

wird aber in der Praxis verblüffend selten eingehalten 

• Wir betrachten nun zuerst eine Fallstudie über diesen Effekt 

• "Warum wird so selten ein geeigneter Prozess durchgeführt?" 

• und betrachten anschließend einige Elemente dieses Prozesses 

genauer 


Entwicklungsprinzipien 

für gute Benutzbarkeit 

1. Direkter Kontakt zu Benutzer/inne/n 

2. Frühes und fortlaufendes Benutzbarkeitstesten 

3. Iterativer Entwurf 

4. Integrierter Entwurf 

• Diese Liste stammt von Gould und Lewis 

• J.D. Gould, C.H. Lewis: "Designing for usability: Key principles and 

what designers think", 

Proc. CHI'83 Conf. on Human Factors in Computing Systems, 

pp.50–83, ACM, 1983 

• Es gibt aber diverse ähnliche andere 

• Sehen wir uns kurz die Beschreibungen und Begründungen an: 


1. Direkter Kontakt zu Benutzern 

Beschreibung: 

• Entwerfer brauchen von Anfang an direkten Kontakt zu 

Endbenutzer/inne/n 

• z.B. mittels Interviews, Beobachtung, Umfragen, 

direkter Partizipation im Arbeitsprozess 

Begründung: 

• Nur so können sie deren relevante Eigenarten verstehen: 

• Denkgewohnheiten und -fertigkeiten, Verhalten, Einstellungen 

• sowie die Eigenschaften der Aufgaben, 

die die Benutzer/innen erledigen sollen 


2. Frühes und fortlaufendes 

Benutzbarkeitstesten 

Beschreibung: 

• Echte Benutzer/innen verwenden die Software 

• oder Prototypen der SW 

• Die Entwickler/innen beobachten dies und holen Feedback ein 

• Beide entwickeln Verbesserungsvorschläge evtl. gemeinsam 

Begründung: 

• Liefert die besten Einsichten in Probleme und Lösungen 

• Liefert gute Motivation, die Software nochmal umzubauen 

• Kein anderer Ansatz zum Entwurf gut benutzbarer Software 

funktioniert zufrieden stellend 



Beschreibung: 

• Die Entwicklung durchläuft viele Zyklen von Entwicklung, 

Benutzbarkeitstest, Bewertung, Entwurfsänderung 

Begründung: 

• Die Benutzbarkeitsprobleme kommen nur nach und nach zum 

Vorschein 

• ein Problem verdeckt oft viele andere, bis es beseitigt wird 

• Korrekturen können neue Probleme hervorrufen 

• und tun dies auch sehr oft 

Entwicklung 

Entwurfsänderung 

Benutzbarkeitstest 

Bewertung 



Beschreibung: 

• Alle Benutzbarkeits-Aspekte müssen zeitlich parallel und inhaltlich 

gemeinsam (in einer Hand) entwickelt werden 

• Benutzungsschnittstelle, Lehreinheiten, Hilfesystem/Dokumentation 

Begründung: 

• Andernfalls würden viele Lösungen den Endbenutzern nie wirklich 

zugute kommen 

• weil sie erläuterungsbedürftig sind ( Dokumentation) 

• Andernfalls werden viele Probleme übersehen (z.B. Erlernbarkeit) 

• Andernfalls können viele Probleme nicht adäquat gelöst werden 

• z.B. kann ein Benutzbarkeitsproblem evtl. nicht in der SW gelöst 

werden, aber mit einem geeigneten Training abgemildert 

• dafür muss die Erkenntnis aus Benutzbarkeitstests zu den Autor/inn/en 

der Trainings übermittelt werden. 


Akzeptanz 

und Verwendung der Prinzipien 

• Auf Befragen stufen erfahrene Entwickler/innen diese Prinzipien 

meist als "offensichtlich" ein 

• Tatsächlich werden sie aber nur sehr unvollständig angewandt: 

• Wenig direkte Einbindung von Benutzer/inne/n 

• Selten werden mehrere Iterationen vorgesehen 


Gründe für die Nichtverwendung 

• Entwickler/innen glauben, Benutzer/innen wüssten nicht was sie 

brauchen 

• Stimmt oft anfangs, 

• löst sich aber mit einem Prototyp schnell 

• Entwickler/innen glauben, dass sich Entwurfsprobleme durch 

Überlegen lösen lassen 

• Kann gelegentlich gelingen, aber meist übersieht man etwas 

• Entwickler/innen glauben, die richtige Lösung auf Anhieb finden zu 

können 

• Kann gelegentlich gelingen, aber meist übersieht man etwas 

• Entwickler/innen verweisen auf Halsstarrigkeit von Benutzer/inne/n 

• Stimmt manchmal anfangs, 

• wird aber durch echte Zusammenarbeit meist aufgebrochen 


Fallstudie: Poltrock und Grudin 

• Steven E. Poltrock, Jonathan Grudin: 

"Organisational obstacles to interface design and development: 

Two participant observer studies", 

ACM Transactions on Computer-Human Interaction 1(1):52–80, 

March 1994 

• reprinted in Computers and Controversy (2nd ed.) as 

"Interface development in a large organization: 

An observational study" 

Jonathan Grudin 


Kontext und Methode 

• Große Softwarefirma 

• Entwicklungseinheit mit 70 Personen 

• Baut neue Version eines wichtigen, international vertriebenen 

Produkts 

• Forscher wurde für 1 Monat Mitglied einer UI-Gruppe 

• nahm an der Entwicklung teil 

• interviewte 25 Personen innerhalb und außerhalb der Gruppe 

User Interface 

(Bedienschnittstelle, 

Benutzungsschnittstelle) 


Entwicklungsgeschichte 

des Softwareprodukts 

• Ein CAD-Programm 

• Ursprünglich eine Hochschulentwicklung 

• Seit 5 Jahren erfolgreich am Markt 

• Fortentwicklung wurde allmählich 

immer schwieriger 

• vor längerem war schon einmal ein 

Projekt zur kompletten Neuentwicklung 

begonnen worden, wurde aber nach 

1 Jahr abgebrochen 

• 2 Jahre Schwanken zwischen Neuentwickeln und Weiterpflegen 

• Dringlichkeit wurde deutlich, Personalausstattung erhöht 

• einige Verbesserungen erzielt, aber keine langfristige Lösung 

• Hoher Grad von Entscheidungsunfähigkeit: 

• Rücknahme von Entscheidungen aus Marketinggründen, 

• mehrfache Reorganisationen und Personalkürzungen 


Entwicklungsgeschichte: 

Der Super-Entwerfer 

• Dann wurde ein "Superentwerfer" ins Team gebracht: 

• aus der Supportgruppe eines anderen Standorts 

• hervorragende technische Fähigkeiten 

• hatte Erfahrung mit der Anpassung des Produkts für einen großen 

Kunden; viel Kontakt mit Manager/inne/n und Endbenutzer/inne/n 

• Er überzeugte einen Vizepräsidenten davon, binnen 1 Jahr eine 

sehr gute neue Version bauen zu können 

• hatte eine klare Vision 

• begann, sich einfach Mitarbeiter/innen zu suchen und ohne 

Zustimmung ihrer Manager/innen Aufgaben zu geben 

• täglicher Abgleich von Fortschritt und Problemen 

• volle Rückendeckung vom Vizepräsidenten half gegen die Beschwerden 

• Ergebnis: Sehr erfolgreiche neue Version entwickelt 


Entwicklungsgeschichte: Fortgang 

• Dieses Verfahren wurde jedoch nicht aufrecht erhalten 

• Zustand bei Beginn der Studie: 

• Der Vizepräsident war weg 

• Der Superentwerfer ging gerade weg 

• Neueingestellte Manager hatten Fokus auf Standard- 

Entwicklungspraktiken mit maximaler Überwachung des Entwurfs und 

viel Koordination 

• bewerteten Zuverlässigkeits- und Planungsziele höher als Innovation 

• Neues Team zur Entwicklung der Benutzungsschnittstelle 

• Keine Produktbenutzer/innen unter den Entwickler/inne/n 

• Auch keine Erfahrung in der Zusammenarbeit mit Kund/inn/en 

• Keine Möglichkeit zur Einbeziehung von Endbenutzer/inne/n 

• Keine Benutzbarkeitstests waren geplant 


Organisationsstruktur 

• ungefähr so 

vorgefunden 

• mit gewissen 

Abweichungen 

• Prinzip 4 

(integrierte 

Entwicklung) ist 

direkt verletzt! 


Theorie der 

UI-Entwicklung dieser Organisation 

• Marketingabteilung arbeitet mit Vertriebsabteilung ("sales") und 

Kunden, um die Marktanforderungen zu verstehen. 

• Außerdem mit Kundendienst ("field support") 

• Entwurfsabteilung ("designers") empfängt diese und arbeitet mit 

Kunden, um die technischen Details der Anforderungen zu 

verstehen 

• Entwicklung ("development") bekommt eine komplette, aber 

abstrakte Funktionsspezifikation von Design 

Schlechte Idee! 

• entwickelt konkrete UI-Spezifikation (dann: Begutachtung, Bau) 

• muss nicht selbst mit Endbenutzer/inne/n arbeiten 


Praxis der UI-Entwicklung 

• Wahrnehmung der Insassen: "The general consensus is 

that our Marketing group is next to worthless" 

• Aussage eines Endbenutzers 

• ein Entwickler traf ihn auf einer Messe 

• "Wie ihr über Produktfeatures entscheidet ist wirklich eine Schande: 

Ich kann nur mit Marketing reden. 

Marketing versteht nicht, was ich will. 

Design versteht nicht, was Marketing aufgeschrieben hat. 

Dann kriegt es Entwicklung, weiß nicht, was es bedeuten soll, 

weiß nicht, wo es herkommt, 

und kann mich nicht kontaktieren, um zu fragen." 

• Die Entwickler/innen versuchen das Problem zu umgehen: 

• Sie reden mit dem Kundendienst (Entwurfsdurchsichten etc.) 

• Leider wurde der dann in die Marketing-Abteilung verlagert und die 

sperrte diese Interaktionen 


Problem 1: Rollenkonflikt für Marketing 

• Die Aufgabe der Marketingabteilung ist es, zu definieren, was 

gebraucht wird, um das Produkt zu verkaufen 

• Dazu reden Sie unter anderem mit Kunden 

• Aber meist mit den Entscheider/inne/n, nicht mit den Benutzer/inne/n 

• Das ist jedoch weitaus zu grob, um eine im Detail nützliche 

Systemgestaltung vorzugeben 

• von gut benutzbar ganz zu schweigen 

• zumal weder das Personal von Marketing noch die Entscheider/innen 

bei den Kunden viel von UI-Gestaltung verstehen 

• Genaue Funktionsdefinition erfordert also separate 

Kommunikationskanäle 

• erst recht UI-Definition 


Problem 2: Kein Kontakt 

zwischen Entwicklung und Benutzern 

• Marketingabteilung über Entwicklungsabteilung: 

• "Die Entwicklung kann keine benutzerfreundliche Software bauen, denn 

die wissen gar nicht, was ein Benutzer ist." 

• Entwicklungsabteilung über Designabteilung: 

• "Sie geben uns eine Lösung vor und sagen nicht, was eigentlich das 

Problem ist." 

• Entwicklungsabteilung über Kontakte zu Kundendienst: 

• "Gerade vorhin habe ich mit einem über ein Feature gesprochen; was 

er denkt, wie das aussehen sollte. Jetzt weiß ich, dass ich alles 

wegwerfen und von vorn anfangen muss." 

• Lösungsversuche der Entwicklungsabteilung: 

• Unterhielt informelle Kontakte zu Kunden 

• aber meist wiederum nur zu Entscheider/inne/n 


Folgen 

für die Anwendung der 4 Prinzipien 

1. Direkter Kontakt zu Benutzern 

• Fehlt. Das ist das Ausgangsproblem 

2. Frühes und fortlaufendes Benutzbarkeitstesten 

• Ist folglich allenfalls mit unechten Benutzer/inne/n möglich 


• Ist nur mäßig nützlich, da man kein qualifiziertes Feedback hat 


• Wird von der Organisationsstruktur extrem erschwert 

• Diskussion siehe nächste Folien 


Frühes 

und fortlaufendes Benutzbarkeitstesten 

• Entwicklungsabteilung präsentierte ihre Benutzungsschnittstelle vor 

Vertreter/inne/n der anderen Abteilungen 

• Problem: "Unqualifizierte Leute machen einen Haufen Kommentare 

über alles mögliche, das ihnen gerade dazu einfällt." 

• "Wenn man ein Architekturmodell vorstellt, hat kaum jemand dazu was 

zu sagen. Aber wenn man Bildschirmentwürfe zeigt, bekommt man so 

viele Meinungen wie Leute im Raum sind." 

• Am nützlichsten war noch, als zwei Mitarbeiter/innen des 

Kundendienstes das Produkt so ausprobierten, wie sie glaubten, 

dass Endbenutzer/innen es verwenden würden 

• (Sie fanden dabei außerdem mehr Defekte als die Qualitätssicherung 

es tat) 

• Dies war aber kein Bestandteil des regulären Entwicklungsprozesses 


Integrierter Entwurf 

• Diese Organisation hatte eine lange Tradition der getrennten 

Entwicklung von HW, SW, Dokumentation und Training 

• Die ganze Kommunikation sollte eigentlich über Spezifikationen 

statt finden 

• Das ist für Benutzungsschnittstellen jedoch sehr schwierig: 

"Man kann nicht in Worten ausdrücken, was man vorhat, wenn man ein 

bestimmtes UI entwirft. Man kann zwar eine Spezifikation davon 

aufschreiben, aber keiner weiß, ob die richtig ist, bevor er sie benutzt 

hat." 

• Diese Organisationsform erzeugt auch Widerstände gegen 

Iterationen 

• oder führt dazu, dass Dokumentation und Lehrmaterial erst sehr spät 

erstellt werden 


Lösungsvorschläge eines Entwicklers 

• Rolle von Marketing: 

• "Marketing sollte eine Richtung vorgeben; Gebiete die zu verbessern 

sind. Und dann ein paar Kunden nennen, mit denen wir direkt 

zusammen arbeiten können." 

• Art und Rolle von Benutzerkontakt: 

• "Es wäre gut, wenn jede Entwickler ein paar Stunden pro Jahr direkt 

zugucken könnte, wie Endbenutzer die SW verwenden. 

Nur zugucken. Sehen, was der Benutzer tut, und 

hören, wo und was er grummelt." 

• "Man muss zuerst mal verstehen, was Benutzer überhaupt erreichen 

wollen. Wie sie es angehen, ihren Tag strukturieren. 

Mit einem solchen Überblick bekommt man auch Ideen, wie man ihnen 

am besten helfen kann." 


Ratschläge an Softwareorganisationen 

• Trage den Mitarbeitern möglichst nur Dinge auf, die sie gut können 

• Viele Tätigkeiten können nur von einem Team mit verschiedenen Rollen 

bewältigt werden 

• Sie einer Person zuzuweisen führt zu schlechten Ergebnissen und zu 

Reibungsverlusten 

• Sorge für kurze Kommunikationspfade 

• Sorge für eine zentrale Entscheidungsinstanz 

• Hindere die Mitarbeiter/innen nicht, das zu tun, was nötig ist! 


Ende der Fallstudie 


Ergebnisse von Benutzbarkeitsprüfungen 

Fallen überwiegend in vier Kategorien: 

• Defekte: 

• Eine Funktion tut eindeutig etwas anderes als vorgesehen 

• Funktionslücken: 

• Eine eindeutig benötigte Funktionalität ist gar nicht vorhanden 

• Verständnisprobleme: 

• Lernproblem: Das Konzept einer Funktion oder Bedienweise ist 

schwierig zu erfassen 

• Benutzungsproblem: Eine Darstellung ist auch für geübte Benutzer oft 

mehrdeutig und provoziert Fehler; eine Eingabeweise provoziert Fehler 

• Bedienschwierigkeiten: 

• Eine Funktion ist zu umständlich zu benutzen 

• Eine Bedienweise provoziert Fehler 

• (Die Zuordnung kann mehrdeutig sein) 


Ergebnisse: Beispiel 

Benutzbarkeitsprüfung eines 

Web-Ladens für Gartenartikel 

http://ucs.ist.psu.edu, 

Case study "Garden-com" 

Bereich: Produktkatalog 

• Defekte, Funktionslücken: -- 

• Verständnisprobleme (Erlernen): 

• Mehrdeutigkeit zwischen "Community" und "Meine Sachen" 

• Benutzer verwenden nicht Link "Varianten" wenn ein angezeigtes 

Produkt ihnen nicht direkt passt 

• Verständnisprobleme (Benutzen): 

• Man sucht oft im falschen Teil des Produktbaums 

• Kategorienamen im Baum sind anders als dann angezeigt 

• Sinnarme Kategorienamen (z.B. "Geschenke") 

• Bedienschwierigkeiten: -- 


Beispiel-Ergebnisse: Suchfunktion 

Bereich: Suchfunktion 

• Defekte: -- 

• Funktionslücken: -- 


• Wenn ein Suchfilter angewendet wurde, wird das nicht direkt angezeigt 


• Es ist unklar, was die Suchfunktion alles abdeckt 

• Suche verlangt oft ganz bestimmten Suchbegriff; zu unflexibel 


• Benutzer geben oft falsch geschriebene Suchbegriffe ein (und merken 

dann evtl. nicht, dass das der Grund für leere Suchergebnisse ist) 


Beispiel-Ergebnisse: Einkaufskorb 

Bereich: Einkaufskorb-Funktion ("Schubkarre") 

• Defekte: 

• Anfänglich ist als Menge für einen Artikel immer "0" gewählt 

• Benutzer können Artikeleigenschaften (z.B. Größe) auf unmögliche 

Werte ändern 



• Benutzer finden die Einkaufskorb-Funktion oft nicht 

• Benutzer finden die Funktion "Entferne Artikel" nicht und 

löschen statt dessen die ganze Bestellung 


• Die Auswahl eines Stoffes wird immer mit "Kissen-Bezugsstoff" 

abgefragt, auch wenn der Artikel gar keine Kissen hat 



Beispiel-Ergebnisse: Bezahlen 

Bereich: Bezahl-Funktion 



• Wenn ein Benutzer versehentlich seine Bestellung löscht, gibt es keinen 

Weg, sie zurück zu bekommen 


• Benutzer klicken oft ohne Wirkung auf Kreditkarten-Symbol 

• Verständnisprobleme (Benutzen): -- 



Beispiel-Ergebnisse: Hilfesystem 

Bereich: Online-Hilfesystem 



• Es gibt kein Hilfesystem, obwohl Benutzer eines erwarten und 

es auch brauchen. 

• Verständnisprobleme (Erlernen): -- 

• Verständnisprobleme (Benutzen): -- 



Beispiel-Ergebnisse: Sonstiges 

Bereich: Sonstiges 



• Verständnisprobleme (Erlernen): -- 


• Der Farbunterschied zwischen neuen und bereits benutzten Links ist zu 

gering 


• Es ist umständlich und schwierig, einen Artikel zu finden/zu bestellen, 

der außerhalb des Einkaufsbereichs erwähnt wird 


Zusammenfassung 

• Software mit guter Benutzbarkeit zu bauen verlangt 

• direkten Kontakt zu Benutzern sowie 

• iterative Entwicklung mit fortlaufenden Benutzbarkeitsprüfungen 

• Leider ist das in konkreten SW-Organisationen 

oft schwer zu gewährleisten 

• Die Ergebnisse von Benutzbarkeitsprüfungen 

fallen in diverse Kategorien und 

geben gute Hinweise für Verbesserungen 


Literatur 

• Usability Body of Knowledge 

• http://www.usabilitybok.org 

• Gute und sehr übersichtliche Erläuterung der wichtigen Konzepte: 

• Erhebungs- und Evaluationsmethoden 

• Entwurfsprinzipien 

• Organisations- und Fortbildungsfragen 

• verwandte Wissensgebiete, Institutionen 

• Enthält weitere Literaturverweise 


Danke!

Bedienbarkeit/Benutzbarkeit - auf Matthias-Draeger.info

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?