Bedienbarkeit/Benutzbarkeit - auf Matthias-Draeger.info
Bedienbarkeit/Benutzbarkeit - auf Matthias-Draeger.info
Bedienbarkeit/Benutzbarkeit - auf Matthias-Draeger.info
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Vorlesung "Anwendungssysteme"<br />
<strong>Bedienbarkeit</strong>/<strong>Benutzbarkeit</strong><br />
Prof. Dr. Lutz Prechelt<br />
Freie Universität Berlin, Institut für Informatik<br />
http://www.inf.fu-berlin.de/inst/ag-se/<br />
• Begriff "<strong>Benutzbarkeit</strong>"<br />
• Entwicklungsprinzipien<br />
• Direkter Kontakt zu Benutzern<br />
• <strong>Benutzbarkeit</strong>stesten<br />
• Iterativer Entwurf<br />
• Integrierter Entwurf<br />
• Fallstudie zur Verwendung der<br />
Prinzipien<br />
• Ratschläge an Organisationen<br />
• Ergebnisse von<br />
<strong>Benutzbarkeit</strong>sprüfungen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 1 / 37
Aspekte von Technikgestaltung<br />
• Technische Zweckmäßigkeit:<br />
• extern sichtbar: Plattformanforderungen, Installierbarkeit,<br />
L<strong>auf</strong>zeiteffizienz, Speichereffizienz, Funktionalität, Flexibilität<br />
• intern: geringer Konstruktions<strong>auf</strong>wand, gute Wartbarkeit,<br />
Wiederverwendbarkeit, etc.<br />
• Wünschbarkeit:<br />
• Gewährleistung allgemeiner passiver Anforderungen<br />
• z.B. Sicherheit, Verlässlichkeit, evtl. Schutz der Privatsphäre<br />
• Gestaltung gemäß spezifischer Wirkungs-Wünsche<br />
• z.B. Vermeidung negativer Wirkungen wie soziale Isolation, Monotonisierung<br />
von Arbeit, Erzeugung von Stress etc.<br />
• Die Forderung nach guter <strong>Benutzbarkeit</strong> liegt an der Schnittstelle<br />
dieser zwei Bereiche<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 2 / 37
<strong>Benutzbarkeit</strong><br />
• <strong>Benutzbarkeit</strong> bedeutet, dass eine Software ihre Benutzer/innen<br />
gut dabei unterstützt, die gewünschten Arbeitsgänge zu erledigen<br />
• Verständlichkeit<br />
• Erlernbarkeit<br />
• <strong>Bedienbarkeit</strong><br />
• <strong>Benutzbarkeit</strong> ist ein Teilaspekt von Brauchbarkeit<br />
• Brauchbarkeit fordert z.B. zusätzlich, dass überhaupt die "richtigen"<br />
Anforderungen realisiert sind<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 3 / 37
<strong>Benutzbarkeit</strong> und Konstruktionsprozess<br />
• Gute <strong>Benutzbarkeit</strong> kann nur erzielt werden, wenn ein geeigneter<br />
Software-Entwicklungsprozess verfolgt wird<br />
• Insbesondere im Bereich der Benutzungsschnittstelle<br />
(user interface, UI)<br />
• Das Vorgehen dafür ist im Prinzip bekannt,<br />
wird aber in der Praxis verblüffend selten eingehalten<br />
• Wir betrachten nun zuerst eine Fallstudie über diesen Effekt<br />
• "Warum wird so selten ein geeigneter Prozess durchgeführt?"<br />
• und betrachten anschließend einige Elemente dieses Prozesses<br />
genauer<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 4 / 37
Entwicklungsprinzipien<br />
für gute <strong>Benutzbarkeit</strong><br />
1. Direkter Kontakt zu Benutzer/inne/n<br />
2. Frühes und fortl<strong>auf</strong>endes <strong>Benutzbarkeit</strong>stesten<br />
3. Iterativer Entwurf<br />
4. Integrierter Entwurf<br />
• Diese Liste stammt von Gould und Lewis<br />
• J.D. Gould, C.H. Lewis: "Designing for usability: Key principles and<br />
what designers think",<br />
Proc. CHI'83 Conf. on Human Factors in Computing Systems,<br />
pp.50–83, ACM, 1983<br />
• Es gibt aber diverse ähnliche andere<br />
• Sehen wir uns kurz die Beschreibungen und Begründungen an:<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 5 / 37
1. Direkter Kontakt zu Benutzern<br />
Beschreibung:<br />
• Entwerfer brauchen von Anfang an direkten Kontakt zu<br />
Endbenutzer/inne/n<br />
• z.B. mittels Interviews, Beobachtung, Umfragen,<br />
direkter Partizipation im Arbeitsprozess<br />
Begründung:<br />
• Nur so können sie deren relevante Eigenarten verstehen:<br />
• Denkgewohnheiten und -fertigkeiten, Verhalten, Einstellungen<br />
• sowie die Eigenschaften der Aufgaben,<br />
die die Benutzer/innen erledigen sollen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 6 / 37
2. Frühes und fortl<strong>auf</strong>endes<br />
<strong>Benutzbarkeit</strong>stesten<br />
Beschreibung:<br />
• Echte Benutzer/innen verwenden die Software<br />
• oder Prototypen der SW<br />
• Die Entwickler/innen beobachten dies und holen Feedback ein<br />
• Beide entwickeln Verbesserungsvorschläge evtl. gemeinsam<br />
Begründung:<br />
• Liefert die besten Einsichten in Probleme und Lösungen<br />
• Liefert gute Motivation, die Software nochmal umzubauen<br />
• Kein anderer Ansatz zum Entwurf gut benutzbarer Software<br />
funktioniert zufrieden stellend<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 7 / 37
3. Iterativer Entwurf<br />
Beschreibung:<br />
• Die Entwicklung durchläuft viele Zyklen von Entwicklung,<br />
<strong>Benutzbarkeit</strong>stest, Bewertung, Entwurfsänderung<br />
Begründung:<br />
• Die <strong>Benutzbarkeit</strong>sprobleme kommen nur nach und nach zum<br />
Vorschein<br />
• ein Problem verdeckt oft viele andere, bis es beseitigt wird<br />
• Korrekturen können neue Probleme hervorrufen<br />
• und tun dies auch sehr oft<br />
Entwicklung<br />
Entwurfsänderung<br />
<strong>Benutzbarkeit</strong>stest<br />
Bewertung<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 8 / 37
4. Integrierter Entwurf<br />
Beschreibung:<br />
• Alle <strong>Benutzbarkeit</strong>s-Aspekte müssen zeitlich parallel und inhaltlich<br />
gemeinsam (in einer Hand) entwickelt werden<br />
• Benutzungsschnittstelle, Lehreinheiten, Hilfesystem/Dokumentation<br />
Begründung:<br />
• Andernfalls würden viele Lösungen den Endbenutzern nie wirklich<br />
zugute kommen<br />
• weil sie erläuterungsbedürftig sind ( Dokumentation)<br />
• Andernfalls werden viele Probleme übersehen (z.B. Erlernbarkeit)<br />
• Andernfalls können viele Probleme nicht adäquat gelöst werden<br />
• z.B. kann ein <strong>Benutzbarkeit</strong>sproblem evtl. nicht in der SW gelöst<br />
werden, aber mit einem geeigneten Training abgemildert<br />
• dafür muss die Erkenntnis aus <strong>Benutzbarkeit</strong>stests zu den Autor/inn/en<br />
der Trainings übermittelt werden.<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 9 / 37
Akzeptanz<br />
und Verwendung der Prinzipien<br />
• Auf Befragen stufen erfahrene Entwickler/innen diese Prinzipien<br />
meist als "offensichtlich" ein<br />
• Tatsächlich werden sie aber nur sehr unvollständig angewandt:<br />
• Wenig direkte Einbindung von Benutzer/inne/n<br />
• Selten werden mehrere Iterationen vorgesehen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 10 / 37
Gründe für die Nichtverwendung<br />
• Entwickler/innen glauben, Benutzer/innen wüssten nicht was sie<br />
brauchen<br />
• Stimmt oft anfangs,<br />
• löst sich aber mit einem Prototyp schnell<br />
• Entwickler/innen glauben, dass sich Entwurfsprobleme durch<br />
Überlegen lösen lassen<br />
• Kann gelegentlich gelingen, aber meist übersieht man etwas<br />
• Entwickler/innen glauben, die richtige Lösung <strong>auf</strong> Anhieb finden zu<br />
können<br />
• Kann gelegentlich gelingen, aber meist übersieht man etwas<br />
• Entwickler/innen verweisen <strong>auf</strong> Halsstarrigkeit von Benutzer/inne/n<br />
• Stimmt manchmal anfangs,<br />
• wird aber durch echte Zusammenarbeit meist <strong>auf</strong>gebrochen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 11 / 37
Fallstudie: Poltrock und Grudin<br />
• Steven E. Poltrock, Jonathan Grudin:<br />
"Organisational obstacles to interface design and development:<br />
Two participant observer studies",<br />
ACM Transactions on Computer-Human Interaction 1(1):52–80,<br />
March 1994<br />
• reprinted in Computers and Controversy (2nd ed.) as<br />
"Interface development in a large organization:<br />
An observational study"<br />
Jonathan Grudin<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 12 / 37
Kontext und Methode<br />
• Große Softwarefirma<br />
• Entwicklungseinheit mit 70 Personen<br />
• Baut neue Version eines wichtigen, international vertriebenen<br />
Produkts<br />
• Forscher wurde für 1 Monat Mitglied einer UI-Gruppe<br />
• nahm an der Entwicklung teil<br />
• interviewte 25 Personen innerhalb und außerhalb der Gruppe<br />
User Interface<br />
(Bedienschnittstelle,<br />
Benutzungsschnittstelle)<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 13 / 37
Entwicklungsgeschichte<br />
des Softwareprodukts<br />
• Ein CAD-Programm<br />
• Ursprünglich eine Hochschulentwicklung<br />
• Seit 5 Jahren erfolgreich am Markt<br />
• Fortentwicklung wurde allmählich<br />
immer schwieriger<br />
• vor längerem war schon einmal ein<br />
Projekt zur kompletten Neuentwicklung<br />
begonnen worden, wurde aber nach<br />
1 Jahr abgebrochen<br />
• 2 Jahre Schwanken zwischen Neuentwickeln und Weiterpflegen<br />
• Dringlichkeit wurde deutlich, Personalausstattung erhöht<br />
• einige Verbesserungen erzielt, aber keine langfristige Lösung<br />
• Hoher Grad von Entscheidungsunfähigkeit:<br />
• Rücknahme von Entscheidungen aus Marketinggründen,<br />
• mehrfache Reorganisationen und Personalkürzungen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 14 / 37
Entwicklungsgeschichte:<br />
Der Super-Entwerfer<br />
• Dann wurde ein "Superentwerfer" ins Team gebracht:<br />
• aus der Supportgruppe eines anderen Standorts<br />
• hervorragende technische Fähigkeiten<br />
• hatte Erfahrung mit der Anpassung des Produkts für einen großen<br />
Kunden; viel Kontakt mit Manager/inne/n und Endbenutzer/inne/n<br />
• Er überzeugte einen Vizepräsidenten davon, binnen 1 Jahr eine<br />
sehr gute neue Version bauen zu können<br />
• hatte eine klare Vision<br />
• begann, sich einfach Mitarbeiter/innen zu suchen und ohne<br />
Zustimmung ihrer Manager/innen Aufgaben zu geben<br />
• täglicher Abgleich von Fortschritt und Problemen<br />
• volle Rückendeckung vom Vizepräsidenten half gegen die Beschwerden<br />
• Ergebnis: Sehr erfolgreiche neue Version entwickelt<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 15 / 37
Entwicklungsgeschichte: Fortgang<br />
• Dieses Verfahren wurde jedoch nicht <strong>auf</strong>recht erhalten<br />
• Zustand bei Beginn der Studie:<br />
• Der Vizepräsident war weg<br />
• Der Superentwerfer ging gerade weg<br />
• Neueingestellte Manager hatten Fokus <strong>auf</strong> Standard-<br />
Entwicklungspraktiken mit maximaler Überwachung des Entwurfs und<br />
viel Koordination<br />
• bewerteten Zuverlässigkeits- und Planungsziele höher als Innovation<br />
• Neues Team zur Entwicklung der Benutzungsschnittstelle<br />
• Keine Produktbenutzer/innen unter den Entwickler/inne/n<br />
• Auch keine Erfahrung in der Zusammenarbeit mit Kund/inn/en<br />
• Keine Möglichkeit zur Einbeziehung von Endbenutzer/inne/n<br />
• Keine <strong>Benutzbarkeit</strong>stests waren geplant<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 16 / 37
Organisationsstruktur<br />
• ungefähr so<br />
vorgefunden<br />
• mit gewissen<br />
Abweichungen<br />
• Prinzip 4<br />
(integrierte<br />
Entwicklung) ist<br />
direkt verletzt!<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 17 / 37
Theorie der<br />
UI-Entwicklung dieser Organisation<br />
• Marketingabteilung arbeitet mit Vertriebsabteilung ("sales") und<br />
Kunden, um die Marktanforderungen zu verstehen.<br />
• Außerdem mit Kundendienst ("field support")<br />
• Entwurfsabteilung ("designers") empfängt diese und arbeitet mit<br />
Kunden, um die technischen Details der Anforderungen zu<br />
verstehen<br />
• Entwicklung ("development") bekommt eine komplette, aber<br />
abstrakte Funktionsspezifikation von Design<br />
Schlechte Idee!<br />
• entwickelt konkrete UI-Spezifikation (dann: Begutachtung, Bau)<br />
• muss nicht selbst mit Endbenutzer/inne/n arbeiten<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 18 / 37
Praxis der UI-Entwicklung<br />
• Wahrnehmung der Insassen: "The general consensus is<br />
that our Marketing group is next to worthless"<br />
• Aussage eines Endbenutzers<br />
• ein Entwickler traf ihn <strong>auf</strong> einer Messe<br />
• "Wie ihr über Produktfeatures entscheidet ist wirklich eine Schande:<br />
Ich kann nur mit Marketing reden.<br />
Marketing versteht nicht, was ich will.<br />
Design versteht nicht, was Marketing <strong>auf</strong>geschrieben hat.<br />
Dann kriegt es Entwicklung, weiß nicht, was es bedeuten soll,<br />
weiß nicht, wo es herkommt,<br />
und kann mich nicht kontaktieren, um zu fragen."<br />
• Die Entwickler/innen versuchen das Problem zu umgehen:<br />
• Sie reden mit dem Kundendienst (Entwurfsdurchsichten etc.)<br />
• Leider wurde der dann in die Marketing-Abteilung verlagert und die<br />
sperrte diese Interaktionen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 19 / 37
Problem 1: Rollenkonflikt für Marketing<br />
• Die Aufgabe der Marketingabteilung ist es, zu definieren, was<br />
gebraucht wird, um das Produkt zu verk<strong>auf</strong>en<br />
• Dazu reden Sie unter anderem mit Kunden<br />
• Aber meist mit den Entscheider/inne/n, nicht mit den Benutzer/inne/n<br />
• Das ist jedoch weitaus zu grob, um eine im Detail nützliche<br />
Systemgestaltung vorzugeben<br />
• von gut benutzbar ganz zu schweigen<br />
• zumal weder das Personal von Marketing noch die Entscheider/innen<br />
bei den Kunden viel von UI-Gestaltung verstehen<br />
• Genaue Funktionsdefinition erfordert also separate<br />
Kommunikationskanäle<br />
• erst recht UI-Definition<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 20 / 37
Problem 2: Kein Kontakt<br />
zwischen Entwicklung und Benutzern<br />
• Marketingabteilung über Entwicklungsabteilung:<br />
• "Die Entwicklung kann keine benutzerfreundliche Software bauen, denn<br />
die wissen gar nicht, was ein Benutzer ist."<br />
• Entwicklungsabteilung über Designabteilung:<br />
• "Sie geben uns eine Lösung vor und sagen nicht, was eigentlich das<br />
Problem ist."<br />
• Entwicklungsabteilung über Kontakte zu Kundendienst:<br />
• "Gerade vorhin habe ich mit einem über ein Feature gesprochen; was<br />
er denkt, wie das aussehen sollte. Jetzt weiß ich, dass ich alles<br />
wegwerfen und von vorn anfangen muss."<br />
• Lösungsversuche der Entwicklungsabteilung:<br />
• Unterhielt <strong>info</strong>rmelle Kontakte zu Kunden<br />
• aber meist wiederum nur zu Entscheider/inne/n<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 21 / 37
Folgen<br />
für die Anwendung der 4 Prinzipien<br />
1. Direkter Kontakt zu Benutzern<br />
• Fehlt. Das ist das Ausgangsproblem<br />
2. Frühes und fortl<strong>auf</strong>endes <strong>Benutzbarkeit</strong>stesten<br />
• Ist folglich allenfalls mit unechten Benutzer/inne/n möglich<br />
3. Iterativer Entwurf<br />
• Ist nur mäßig nützlich, da man kein qualifiziertes Feedback hat<br />
4. Integrierter Entwurf<br />
• Wird von der Organisationsstruktur extrem erschwert<br />
• Diskussion siehe nächste Folien<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 22 / 37
Frühes<br />
und fortl<strong>auf</strong>endes <strong>Benutzbarkeit</strong>stesten<br />
• Entwicklungsabteilung präsentierte ihre Benutzungsschnittstelle vor<br />
Vertreter/inne/n der anderen Abteilungen<br />
• Problem: "Unqualifizierte Leute machen einen H<strong>auf</strong>en Kommentare<br />
über alles mögliche, das ihnen gerade dazu einfällt."<br />
• "Wenn man ein Architekturmodell vorstellt, hat kaum jemand dazu was<br />
zu sagen. Aber wenn man Bildschirmentwürfe zeigt, bekommt man so<br />
viele Meinungen wie Leute im Raum sind."<br />
• Am nützlichsten war noch, als zwei Mitarbeiter/innen des<br />
Kundendienstes das Produkt so ausprobierten, wie sie glaubten,<br />
dass Endbenutzer/innen es verwenden würden<br />
• (Sie fanden dabei außerdem mehr Defekte als die Qualitätssicherung<br />
es tat)<br />
• Dies war aber kein Bestandteil des regulären Entwicklungsprozesses<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 23 / 37
Integrierter Entwurf<br />
• Diese Organisation hatte eine lange Tradition der getrennten<br />
Entwicklung von HW, SW, Dokumentation und Training<br />
• Die ganze Kommunikation sollte eigentlich über Spezifikationen<br />
statt finden<br />
• Das ist für Benutzungsschnittstellen jedoch sehr schwierig:<br />
"Man kann nicht in Worten ausdrücken, was man vorhat, wenn man ein<br />
bestimmtes UI entwirft. Man kann zwar eine Spezifikation davon<br />
<strong>auf</strong>schreiben, aber keiner weiß, ob die richtig ist, bevor er sie benutzt<br />
hat."<br />
• Diese Organisationsform erzeugt auch Widerstände gegen<br />
Iterationen<br />
• oder führt dazu, dass Dokumentation und Lehrmaterial erst sehr spät<br />
erstellt werden<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 24 / 37
Lösungsvorschläge eines Entwicklers<br />
• Rolle von Marketing:<br />
• "Marketing sollte eine Richtung vorgeben; Gebiete die zu verbessern<br />
sind. Und dann ein paar Kunden nennen, mit denen wir direkt<br />
zusammen arbeiten können."<br />
• Art und Rolle von Benutzerkontakt:<br />
• "Es wäre gut, wenn jede Entwickler ein paar Stunden pro Jahr direkt<br />
zugucken könnte, wie Endbenutzer die SW verwenden.<br />
Nur zugucken. Sehen, was der Benutzer tut, und<br />
hören, wo und was er grummelt."<br />
• "Man muss zuerst mal verstehen, was Benutzer überhaupt erreichen<br />
wollen. Wie sie es angehen, ihren Tag strukturieren.<br />
Mit einem solchen Überblick bekommt man auch Ideen, wie man ihnen<br />
am besten helfen kann."<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 25 / 37
Ratschläge an Softwareorganisationen<br />
• Trage den Mitarbeitern möglichst nur Dinge <strong>auf</strong>, die sie gut können<br />
• Viele Tätigkeiten können nur von einem Team mit verschiedenen Rollen<br />
bewältigt werden<br />
• Sie einer Person zuzuweisen führt zu schlechten Ergebnissen und zu<br />
Reibungsverlusten<br />
• Sorge für kurze Kommunikationspfade<br />
• Sorge für eine zentrale Entscheidungsinstanz<br />
• Hindere die Mitarbeiter/innen nicht, das zu tun, was nötig ist!<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 26 / 37
Ende der Fallstudie<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 27 / 37
Ergebnisse von <strong>Benutzbarkeit</strong>sprüfungen<br />
Fallen überwiegend in vier Kategorien:<br />
• Defekte:<br />
• Eine Funktion tut eindeutig etwas anderes als vorgesehen<br />
• Funktionslücken:<br />
• Eine eindeutig benötigte Funktionalität ist gar nicht vorhanden<br />
• Verständnisprobleme:<br />
• Lernproblem: Das Konzept einer Funktion oder Bedienweise ist<br />
schwierig zu erfassen<br />
• Benutzungsproblem: Eine Darstellung ist auch für geübte Benutzer oft<br />
mehrdeutig und provoziert Fehler; eine Eingabeweise provoziert Fehler<br />
• Bedienschwierigkeiten:<br />
• Eine Funktion ist zu umständlich zu benutzen<br />
• Eine Bedienweise provoziert Fehler<br />
• (Die Zuordnung kann mehrdeutig sein)<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 28 / 37
Ergebnisse: Beispiel<br />
<strong>Benutzbarkeit</strong>sprüfung eines<br />
Web-Ladens für Gartenartikel<br />
http://ucs.ist.psu.edu,<br />
Case study "Garden-com"<br />
Bereich: Produktkatalog<br />
• Defekte, Funktionslücken: --<br />
• Verständnisprobleme (Erlernen):<br />
• Mehrdeutigkeit zwischen "Community" und "Meine Sachen"<br />
• Benutzer verwenden nicht Link "Varianten" wenn ein angezeigtes<br />
Produkt ihnen nicht direkt passt<br />
• Verständnisprobleme (Benutzen):<br />
• Man sucht oft im falschen Teil des Produktbaums<br />
• Kategorienamen im Baum sind anders als dann angezeigt<br />
• Sinnarme Kategorienamen (z.B. "Geschenke")<br />
• Bedienschwierigkeiten: --<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 29 / 37
Beispiel-Ergebnisse: Suchfunktion<br />
Bereich: Suchfunktion<br />
• Defekte: --<br />
• Funktionslücken: --<br />
• Verständnisprobleme (Erlernen):<br />
• Wenn ein Suchfilter angewendet wurde, wird das nicht direkt angezeigt<br />
• Verständnisprobleme (Benutzen):<br />
• Es ist unklar, was die Suchfunktion alles abdeckt<br />
• Suche verlangt oft ganz bestimmten Suchbegriff; zu unflexibel<br />
• Bedienschwierigkeiten:<br />
• Benutzer geben oft falsch geschriebene Suchbegriffe ein (und merken<br />
dann evtl. nicht, dass das der Grund für leere Suchergebnisse ist)<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 30 / 37
Beispiel-Ergebnisse: Eink<strong>auf</strong>skorb<br />
Bereich: Eink<strong>auf</strong>skorb-Funktion ("Schubkarre")<br />
• Defekte:<br />
• Anfänglich ist als Menge für einen Artikel immer "0" gewählt<br />
• Benutzer können Artikeleigenschaften (z.B. Größe) <strong>auf</strong> unmögliche<br />
Werte ändern<br />
• Funktionslücken: --<br />
• Verständnisprobleme (Erlernen):<br />
• Benutzer finden die Eink<strong>auf</strong>skorb-Funktion oft nicht<br />
• Benutzer finden die Funktion "Entferne Artikel" nicht und<br />
löschen statt dessen die ganze Bestellung<br />
• Verständnisprobleme (Benutzen):<br />
• Die Auswahl eines Stoffes wird immer mit "Kissen-Bezugsstoff"<br />
abgefragt, auch wenn der Artikel gar keine Kissen hat<br />
• Bedienschwierigkeiten: --<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 31 / 37
Beispiel-Ergebnisse: Bezahlen<br />
Bereich: Bezahl-Funktion<br />
• Defekte: --<br />
• Funktionslücken: --<br />
• Wenn ein Benutzer versehentlich seine Bestellung löscht, gibt es keinen<br />
Weg, sie zurück zu bekommen<br />
• Verständnisprobleme (Erlernen):<br />
• Benutzer klicken oft ohne Wirkung <strong>auf</strong> Kreditkarten-Symbol<br />
• Verständnisprobleme (Benutzen): --<br />
• Bedienschwierigkeiten: --<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 32 / 37
Beispiel-Ergebnisse: Hilfesystem<br />
Bereich: Online-Hilfesystem<br />
• Defekte: --<br />
• Funktionslücken: --<br />
• Es gibt kein Hilfesystem, obwohl Benutzer eines erwarten und<br />
es auch brauchen.<br />
• Verständnisprobleme (Erlernen): --<br />
• Verständnisprobleme (Benutzen): --<br />
• Bedienschwierigkeiten: --<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 33 / 37
Beispiel-Ergebnisse: Sonstiges<br />
Bereich: Sonstiges<br />
• Defekte: --<br />
• Funktionslücken: --<br />
• Verständnisprobleme (Erlernen): --<br />
• Verständnisprobleme (Benutzen):<br />
• Der Farbunterschied zwischen neuen und bereits benutzten Links ist zu<br />
gering<br />
• Bedienschwierigkeiten:<br />
• Es ist umständlich und schwierig, einen Artikel zu finden/zu bestellen,<br />
der außerhalb des Eink<strong>auf</strong>sbereichs erwähnt wird<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 34 / 37
Zusammenfassung<br />
• Software mit guter <strong>Benutzbarkeit</strong> zu bauen verlangt<br />
• direkten Kontakt zu Benutzern sowie<br />
• iterative Entwicklung mit fortl<strong>auf</strong>enden <strong>Benutzbarkeit</strong>sprüfungen<br />
• Leider ist das in konkreten SW-Organisationen<br />
oft schwer zu gewährleisten<br />
• Die Ergebnisse von <strong>Benutzbarkeit</strong>sprüfungen<br />
fallen in diverse Kategorien und<br />
geben gute Hinweise für Verbesserungen<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 35 / 37
Literatur<br />
• Usability Body of Knowledge<br />
• http://www.usabilitybok.org<br />
• Gute und sehr übersichtliche Erläuterung der wichtigen Konzepte:<br />
• Erhebungs- und Evaluationsmethoden<br />
• Entwurfsprinzipien<br />
• Organisations- und Fortbildungsfragen<br />
• verwandte Wissensgebiete, Institutionen<br />
• Enthält weitere Literaturverweise<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 36 / 37
Danke!<br />
Lutz Prechelt, prechelt@inf.fu-berlin.de [12] 37 / 37