SlideShare ist ein Scribd-Unternehmen logo
1 von 65
Downloaden Sie, um offline zu lesen
1 Usability Engineering – Vorlesung 1
Vorlesung 5
VU 183.123
Sommersemester 2012
Christoph Wimmer
Usability Engineering
2 Usability Engineering – Vorlesung 1 2
Übersicht
 Nielsen‘s Heuristiken
 User Research – Was, wie, wieso?
3 Usability Engineering – Vorlesung 1
Nielsen‘s Heuristiken
4 Usability Engineering – Vorlesung 1 4
Nielsen‘s Heuristiken
 Visibility of the system status
 Match between the system and the real world
 User control & freedom
 Consistency & standards
 Error prevention
 Recognition rather than recall
 Flexibility and efficiency of use
 Aesthetic and minimal design
 Help users recognize, diagnose, and recover from
errors
 Help and documentation
5 Usability Engineering – Vorlesung 1 5
Visibility of the system status
 The system should always keep users
informed about what is going on, through
appropriate feedback within reasonable time.
> Doit
What’s
it
doing?
> Doit
This will take
5 minutes...
Time
for
coffee.
6 Usability Engineering – Vorlesung 1 6
Visibility of the system status
 Information an den User
 ... darüber, dass eine Aktion ausgeführt wird/
wurde
 ... über das Ergebnis einer Aktion
 ... über den aktuellen Status und welche
Operationen möglich sind (Feedforward)
7 Usability Engineering – Vorlesung 1 7
Visibility of the system status
 Antwortzeit des Systems berücksichtigen
 0,1 Sek: kein spezieller Indikator notwendig
 1,0 Sek: User verliert das Gefühl von direkter,
unmittelbarer Interaktion
 > 10 Sek: User verliert Fokus, Status Indikator
benutzen
http://www.useit.com/papers/responsetime.html
8 Usability Engineering – Vorlesung 1 8
Match between the system and the real world
 The system should speak the users' language,
with words, phrases and concepts familiar to
the user, rather than system-oriented terms.
Follow real-world conventions, making
information appear in a natural and logical
order.
9 Usability Engineering – Vorlesung 1 9
Match between the system and the real world
 Unreflektierte Nachbildung von physischen
Interfaces kann problematisch sein
10 Usability Engineering – Vorlesung 1 10
User control & freedom
 Users often choose system functions by
mistake and will need a clearly marked
"emergency exit" to leave the unwanted state
without having to go through an extended
dialogue. Support undo and redo.
 Exits schaffen, wenn User Fehler machen
 z.B.: Link zur Startseite auf jeder Webseite
 z.B.: Standard-Einstellungen wiederherstellen
11 Usability Engineering – Vorlesung 1 11
User control & freedom
 Undo und Redo unterstützen
 „Never use a warning when you mean undo“
 Google Mail – Nachricht löschen:
 Google Mail – Label löschen:
12 Usability Engineering – Vorlesung 1 12
User control & freedom
 Dem User keine fixen Pfade vorgeben
 Beispiel: Wizards
13 Usability Engineering – Vorlesung 1 13
Consistency & Standards
 Users should not have to wonder whether
different words, situations, or actions mean
the same thing. Follow platform conventions.
14 Usability Engineering – Vorlesung 1 14
Consistency & Standards
 Dieselben Kontrollelemente an derselben
Stelle des Screens/Dialogs anzeigen
 Vorhersagbarkeit
 Konsistenz von Sprache und Grafiken
 Konsistentes graphisches Erscheinungsbild
(z.B. Widgets)
 Konsistenz von Input
 Konsistente Syntax durch das komplette
System
15 Usability Engineering – Vorlesung 1 15
Consistency & Standards
 Plattformkonventionen: Windows User
Experience Interaction Guidelines, Apple
Human Interface Guidelines, ...
 Unternehmensinterne Styleguides
 Design Patterns, Best Practices,
Konkurrenzanalyse
16 Usability Engineering – Vorlesung 1 16
Error prevention
 Even better than good error
messages is a careful design
which prevents a problem
from occurring in the first
place. Either eliminate error-
prone conditions or check for
them and present users with
a confirmation option before
they commit to the action.
 Verhindern von Fehlern, bevor
diese Überhaupt auftreten
Datum:
Tag Monat Jahr
Tag Monat Jahr
27.	
  1.	
  2012?	
  
27.	
  Jänner	
  2012?	
  
01/27/12?	
  
...	
  ??	
  
17 Usability Engineering – Vorlesung 1 17
Error prevention
Korrekte Eingabe erzwingen:
Eingabe flexibel verarbeiten: Kann schief gehen:
18 Usability Engineering – Vorlesung 1 18
Recognition rather than recall
 Minimize the user's memory load by making
objects, actions, and options visible. The user
should not have to remember information
from one part of the dialogue to another.
Instructions for use of the system should be
visible or easily retrievable whenever
appropriate.
19 Usability Engineering – Vorlesung 1 19
Recognition rather than recall
20 Usability Engineering – Vorlesung 1 20
Recognition rather than recall
Farbe Form
21 Usability Engineering – Vorlesung 1 21
Flexibility and efficiency of use
 Accelerators - unseen by
the novice user - may
often speed up the
interaction for the expert
user such that the system
can cater to both
inexperienced and
experienced users. Allow
users to tailor frequent
actions.
22 Usability Engineering – Vorlesung 1 22
Flexibility and efficiency of use
 Erfahrene Benutzer sollen Tasks schneller und
effizienter ausführen können als unerfahrene
Benutzer (man soll sich verbessern können)
 Kenntnis von solchen Shortcuts darf nicht
vorausgesetzt werden
23 Usability Engineering – Vorlesung 1 23
Aesthetic and minimalist design
 Dialogues should not contain information
which is irrelevant or rarely needed. Every
extra unit of information in a dialogue
competes with the relevant units of
information and diminishes their relative
visibility.
 Auch: „Attractive Things Work Better“
– Donald Norman
Siehe auch:
http://www.interaction-design.org/encyclopedia/visual_aesthetics.html
24 Usability Engineering – Vorlesung 1 24
Aesthetic and minimalist design
 Artikel: Rot
 Navigation: Lila
 Werbung: Grün
 Related Stories: Gelb
25 Usability Engineering – Vorlesung 1 25
Help users recognize, diagnose, and
recover from errors
 Error messages should be expressed in plain
language (no codes), precisely indicate the
problem, and constructively suggest a
solution.
26 Usability Engineering – Vorlesung 1 26
Help users recognize, diagnose, and
recover from errors
 Was ist passiert?
 Welche Teile des
Systems sind
betroffen?
 Was ist die Ursache?
 Wie kann ich das
Problem beheben?
27 Usability Engineering – Vorlesung 1 27
Help and documentation
 Even though it is better if the system can be
used without documentation, it may be
necessary to provide help and documentation.
Any such information should be easy to
search, focused on the user's task, list
concrete steps to be carried out, and not be
too large.
28 Usability Engineering – Vorlesung 1 28
Help and documentation
 Hilfe ist kein Ersatz für schlechte Usability!
 Einfach zu durchsuchen
 Kontextabhängig
 gerade durchgeführter Task => Hilfe
 Es sollen konkrete Schritte erklärt werden, die
der User durchführen kann
 Nicht zu umfangreich
29 Usability Engineering – Vorlesung 1
User Research
30 Usability Engineering – Vorlesung 1 30
User Centered Design
 Früher Fokus
auf Benutzer
und deren
Aufgaben
 Empirische
Beobachtung
Idee
Evaluierung Design
User Research
Prototyping
• Sketching
• Paper Prototyping
• Wizard of Oz
• …
• Heuristische
Evaluierung
• Usability Test
• Thinking Aloud
• …
31 Usability Engineering – Vorlesung 1 31
Kluft zwischen Designer und Benutzer
 Level 1: Der Designer ist der
Benutzer
 Level 2: Der Designer versteht
das Produkt
 Level 3: Design für eine fremde
Domäne
32 Usability Engineering – Vorlesung 1 32
User Research
 Etwas von den Benutzern lernen...
 Kritische Aspekte untersuchen
 Offene Fragen beantworten
 Neue Ideen finden
 Datenerhebung durch...
 Befragung
 Beobachtung
33 Usability Engineering – Vorlesung 1 33
Herausforderung...
34 Usability Engineering – Vorlesung 1 34
Herausforderung...
35 Usability Engineering – Vorlesung 1 35
To design an easy-to-use
interface, pay attention to
what users do, not what
they say. Self reported
claims are unreliable, as
are user speculations
about future behaviour.
- Jakob Nielsen
36 Usability Engineering – Vorlesung 1 36
Teilnehmer
 Erhebung von Benutzer-Requirements
 nicht Stakeholder-Requirements
 Benutzer sind Personen, die mit dem System
arbeiten
 Stakeholder sind Personen oder
Organisationen, welche von dem System
betroffen sind und direkten oder indirekten
Einfluss auf System Requirements haben
 Benutzer sind auch Stakeholder (aber nicht
die einzigen)
37 Usability Engineering – Vorlesung 1 37
Teilnehmer
 Wer sind die Benutzer?
 Bestehende Hierarchien durchbrechen, um die
richtigen Teilnehmer zu erreichen
 Bereitschaft: Teilnehmer sollten freiwillig und
gerne mitmachen
 Vertraulichkeit und Sicherheit: Im Vorhinein
abklären und notwendige Befugnisse einholen
 Verfügbarkeit: Zeitlich, geographisch
 Die Teilnehmer im vorhinein kontaktieren und
einen Termin vereinbaren
 Ggf. Kompensation für ihre Zeit
38 Usability Engineering – Vorlesung 1 38
Wozu User Research?
 Einbindung der Benutzer ist einer der
bedeutendsten Faktoren für Erfolg oder
Scheitern eines Software-
Entwicklungsprojekts
 Standish Group CHAOS Report (1995):
 Project Success Factor #1: User Involvement
 Project Challenged Factors:
1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
39 Usability Engineering – Vorlesung 1 39
Wozu User Research?
 Management von Erwartungen
 Realistische Erwartungen
 Keine bösen Überraschungen oder
Enttäuschung
 Co-Ownership
 Benutzer nehmen aktiv am
Entwicklungsprozess teil
 Verringert Widerstand gegen Veränderungen
 Erhöht spätere Akzeptanz
40 Usability Engineering – Vorlesung 1 40
...aber: Users are not Designers!
 „No amount of data analysis can make up for
a lack of talent.“ (Jeffrey Zeldman)
 „Users (and their data) should be there to
inform designers, not substitute for
them.“ (Dan Saffer)
Es geht nicht darum Designer zu ersetzen!
41 Usability Engineering – Vorlesung 1 41
User Research Methoden
42 Usability Engineering – Vorlesung 1 42
Welche Methode?
http://www.useit.com/alertbox/user-research-methods.html
43 Usability Engineering – Vorlesung 1 43
Welche Methode?
http://www.useit.com/alertbox/user-research-methods.html
44 Usability Engineering – Vorlesung 1 44
User Research im Designprozess
 Idealfall: Iterativ in kleinen Schritten
Quelle: Adaptive Path
45 Usability Engineering – Vorlesung 1
Contextual Inquiry
46 Usability Engineering – Vorlesung 1 46
Definition Usability
 „Usability eines Produktes ist das Ausmaß, in
dem es von einem bestimmten Benutzer
verwendet werden kann, um bestimmte Ziele
in einem bestimmten Kontext effektiv,
effizient und zufriedenstellend zu
erreichen.“ (ISO 9241)
47 Usability Engineering – Vorlesung 1 47
Nutzungskontext
48 Usability Engineering – Vorlesung 1 48
Nutzungskontext
“When people research technology [they
often start at] the point at which someone
picks up the telephone or starts typing on the
keyboard. For me that’s already far too down
in the process. You want to know; Where
does that PC live in someone’s home? How
did they acquire it? What else is around it?
And even one step back further than that:
What do people care about? What motivates
them? What gets them up in the morning?
What do they do when they get up in the
morning?” – Genevieve Bell
49 Usability Engineering – Vorlesung 1 49
Nutzungskontext
“Always design a thing by considering it in its
next larger context - a chair in a room, a
room in a house, a house in an environment,
an environment in a city plan.”
– Eliel Saarinen
50 Usability Engineering – Vorlesung 1 50
Quelle: Giant Ant
51 Usability Engineering – Vorlesung 1 51
Contextual Inquiry
 Spezielle Form von Interviews
 Direkt im Kontext der Benutzer
 Beobachten von realen Benutzern, die reale
Aufgaben in ihrer Arbeitsumgebung ausführen
 Wissen über die Problemdomäne, (Arbeits-)
Kultur, physische und soziale Grenzen sammeln
 Vertrauen zu Benutzern aufbauen, die eventuell
später das Produkt evaluieren
 Dieses Wissen kann benutzt werden um im
Entwicklungsprozess fundierte und damit bessere
Entscheidungen zu treffen.
52 Usability Engineering – Vorlesung 1 52
Thoughtless Acts
 Menschen interagieren oft unerwartet oder
unbewusst mit ihrer Umwelt
 Solche Dinge lassen sich meist nicht
außerhalb des realen Nutzungskontexts
erfassen
 Liefern Möglichkeiten für Verbesserungen
oder neue Designs
53 Usability Engineering – Vorlesung 1 53
54 Usability Engineering – Vorlesung 1 54
55 Usability Engineering – Vorlesung 1
http://www.flickr.com/groups/thoughtlessacts/
56 Usability Engineering – Vorlesung 1 56
Vier Prinzipen von Contextual Inquiry
1. Kontext
 Aktuelle Erfahrungen vs. Zusammengefasste
Erfahrungen
 Konkrete Daten vs. Abstrakte Daten
2. Partnership
 Beziehung zum Benutzer herstellen
 Benutzer ist Experte in seiner Arbeit
3. Interpretation
 Der Beobachtung eine Bedeutung geben
4. Fokus
 Zuhören, Erkunden und Eingrenzen auf eine klares
Ziel
57 Usability Engineering – Vorlesung 1 57
Kontext
 Verstehen der Arbeit in der natürlichen
Umgebung
 Zum Benutzer gehen
 Arbeit dort beobachten, wo sie normalerweise
erledigt wird
 Die Benutzer interviewen, während sie arbeiten
 Entdecken von Details und Problemen vor Ort
bei der Arbeit
 Beobachten und Aufzeichnen von konkreten,
handfesten Daten
58 Usability Engineering – Vorlesung 1 58
Kontext
 Welche Faktoren bestimmen den Kontext des
Benutzers?
 Physischer Arbeitsplatz
 Art der Arbeit – Aufgaben, Abläufe
 Ziele der Arbeit
 Sprache des Benutzers
 Benutzte Hilfsmittel
 Physische Artefakte
 Platzierung von Objekten
 Häufig vs. selten benutzt
 Andere Benutzer und wie sie zusammenarbeiten
 Organisation in der Firma
 Kulturelle Einflüsse
 Ziele des Unternehmens
59 Usability Engineering – Vorlesung 1 59
Partnership
 Beziehung zum Benutzer herstellen
 Unterdrücken der eigenen Erwartungen und
Vorstellungen
 Der Benutzer ist der Experte - er ist die einzige
Person, die wirklich alles über seine Arbeit weiß
 Wie erreicht man „Partnership“?
 Den Benutzer die Konversation leiten lassen
 Offene Fragen verwenden
 Zuhören
 Non-verbale Kommunikation
beachten
 Erwarten, etwas zu lernen
60 Usability Engineering – Vorlesung 1 60
Interpretation
 Der Beobachtung eine Bedeutung geben
 Gemeinsam mit dem Benutzer
 Aktives Beobachten vor Ort
 Verifizierte Interpretationen hervorheben:
 Ein Faktum sollte immer mit einer Referenz zur
Transkription oder Video versehen sein
 Alles was markiert ist sind konkrete Daten
 Alles andere sind nicht verifizierte
Interpretationen
61 Usability Engineering – Vorlesung 1 61
Fokus
 Perspektive einbringen
 Auf einen Fokus beschränken hilft meist mehr
Details zu sehen
 Ein zu enger Fokus birgt das Risiko, dass man
etwas übersieht
 Das Setzen eines Fokus hat verschiedene
Vorteile:
 Bestimmt die Auswahl der Teilnehmer
 Hilft bei limitierter Interviewzeit
 Lenkt Fragen ans Ziel
 Schafft Verständnis und lenkt die Konversation
62 Usability Engineering – Vorlesung 1 62
Beobachtung
 Aufgaben, Abläufe und Tätigkeiten
 Rolle des Benutzers in der Organisation
 Verantwortungen innerhalb der Rolle
 Formen der Kommunikation
 Organisation der physischen
Arbeitsumgebung
 Sämtliche Hilfsmittel und Werkzeuge
 Ziele und Bedürfnisse
 Schwierigkeiten und erprobte Lösungsansätze
mit vorhandenen Werkzeugen
 Struktur von verwendeten Daten
63 Usability Engineering – Vorlesung 1 63
Aufzeichnungen
 Sichergehen, dass alles aufgezeichnet wird:
 Arbeitsprozess und Aufgaben
 Probleme bei der Arbeit
 Benutzte Tools
 Designideen und Bestätigungen
 Sprache des Benutzers
 Beobachtung
 Gute Notizen machen!
 Auch wenn man Audio und Video Equipment
dabei hat
64 Usability Engineering – Vorlesung 1 64
65 Usability Engineering – Vorlesung 1
designing comfort
deco.inso.tuwien.ac.at deco@inso.tuwien.ac.at

Weitere ähnliche Inhalte

Ähnlich wie usability_vorlesung_5.pdf

UCD, Mobility Kongress Würzburg 3. Juli 2013
UCD, Mobility Kongress Würzburg 3. Juli 2013UCD, Mobility Kongress Würzburg 3. Juli 2013
UCD, Mobility Kongress Würzburg 3. Juli 2013Netcetera
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Markus Unterauer
 
German UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD BaukastenGerman UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD BaukastenUSECON
 
Werkstattgespräch Agile Requirements Engineering
Werkstattgespräch Agile Requirements EngineeringWerkstattgespräch Agile Requirements Engineering
Werkstattgespräch Agile Requirements EngineeringuxHH
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Renate Pinggera
 
Don't make me think about my Unternehmensanwendung
Don't make me think about my UnternehmensanwendungDon't make me think about my Unternehmensanwendung
Don't make me think about my UnternehmensanwendungGunnar Tacke
 
IBM Lotus Notes Domino Security mit ITIL | C.Habermueller
IBM Lotus Notes Domino Security mit ITIL | C.HabermuellerIBM Lotus Notes Domino Security mit ITIL | C.Habermueller
IBM Lotus Notes Domino Security mit ITIL | C.HabermuellerChristian Habermueller
 
Domino Security mit ITIL | C.Habermueller
Domino Security mit ITIL | C.HabermuellerDomino Security mit ITIL | C.Habermueller
Domino Security mit ITIL | C.HabermuellerChristian Habermueller
 
Usability Engineering
Usability  EngineeringUsability  Engineering
Usability EngineeringNina Rebele
 
Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Martin Gaedke
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?HOOD Group
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDSwissQ Consulting AG
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungMarc Müller
 
Zeix e healthsummit_2013_v1-1_slideshare
Zeix e healthsummit_2013_v1-1_slideshareZeix e healthsummit_2013_v1-1_slideshare
Zeix e healthsummit_2013_v1-1_slideshareZeix AG
 
Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....
Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....
Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....soultank AG
 
Szenarien userstories usecases
Szenarien userstories usecasesSzenarien userstories usecases
Szenarien userstories usecasesMaria Mory
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungErnest Wallmueller
 

Ähnlich wie usability_vorlesung_5.pdf (20)

UCD, Mobility Kongress Würzburg 3. Juli 2013
UCD, Mobility Kongress Würzburg 3. Juli 2013UCD, Mobility Kongress Würzburg 3. Juli 2013
UCD, Mobility Kongress Würzburg 3. Juli 2013
 
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Syst...
 
UX in Business Apps
UX in Business AppsUX in Business Apps
UX in Business Apps
 
German UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD BaukastenGerman UPA Konferenz - Der IxD Baukasten
German UPA Konferenz - Der IxD Baukasten
 
Werkstattgespräch Agile Requirements Engineering
Werkstattgespräch Agile Requirements EngineeringWerkstattgespräch Agile Requirements Engineering
Werkstattgespräch Agile Requirements Engineering
 
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)
 
Don't make me think about my Unternehmensanwendung
Don't make me think about my UnternehmensanwendungDon't make me think about my Unternehmensanwendung
Don't make me think about my Unternehmensanwendung
 
IBM Lotus Notes Domino Security mit ITIL | C.Habermueller
IBM Lotus Notes Domino Security mit ITIL | C.HabermuellerIBM Lotus Notes Domino Security mit ITIL | C.Habermueller
IBM Lotus Notes Domino Security mit ITIL | C.Habermueller
 
Domino Security mit ITIL | C.Habermueller
Domino Security mit ITIL | C.HabermuellerDomino Security mit ITIL | C.Habermueller
Domino Security mit ITIL | C.Habermueller
 
Usability Engineering
Usability  EngineeringUsability  Engineering
Usability Engineering
 
Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]Agile (Software-) Prozesse - Quo Vadis? [in German]
Agile (Software-) Prozesse - Quo Vadis? [in German]
 
Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?Agilität im Systems Engineering – geht das?
Agilität im Systems Engineering – geht das?
 
Scrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADEDScrum Rocks, Testing Sucks ?! RELOADED
Scrum Rocks, Testing Sucks ?! RELOADED
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
 
Zeix e healthsummit_2013_v1-1_slideshare
Zeix e healthsummit_2013_v1-1_slideshareZeix e healthsummit_2013_v1-1_slideshare
Zeix e healthsummit_2013_v1-1_slideshare
 
Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....
Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....
Scrum und User Centered Design – wie geht das?, Usability Coffee, Zug, 21.08....
 
Szenarien userstories usecases
Szenarien userstories usecasesSzenarien userstories usecases
Szenarien userstories usecases
 
Softwaretests: Motivation und Überblick
Softwaretests: Motivation und ÜberblickSoftwaretests: Motivation und Überblick
Softwaretests: Motivation und Überblick
 
Abenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-WartungAbenteuer Qualität in der SW-Wartung
Abenteuer Qualität in der SW-Wartung
 

usability_vorlesung_5.pdf

  • 1. 1 Usability Engineering – Vorlesung 1 Vorlesung 5 VU 183.123 Sommersemester 2012 Christoph Wimmer Usability Engineering
  • 2. 2 Usability Engineering – Vorlesung 1 2 Übersicht  Nielsen‘s Heuristiken  User Research – Was, wie, wieso?
  • 3. 3 Usability Engineering – Vorlesung 1 Nielsen‘s Heuristiken
  • 4. 4 Usability Engineering – Vorlesung 1 4 Nielsen‘s Heuristiken  Visibility of the system status  Match between the system and the real world  User control & freedom  Consistency & standards  Error prevention  Recognition rather than recall  Flexibility and efficiency of use  Aesthetic and minimal design  Help users recognize, diagnose, and recover from errors  Help and documentation
  • 5. 5 Usability Engineering – Vorlesung 1 5 Visibility of the system status  The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. > Doit What’s it doing? > Doit This will take 5 minutes... Time for coffee.
  • 6. 6 Usability Engineering – Vorlesung 1 6 Visibility of the system status  Information an den User  ... darüber, dass eine Aktion ausgeführt wird/ wurde  ... über das Ergebnis einer Aktion  ... über den aktuellen Status und welche Operationen möglich sind (Feedforward)
  • 7. 7 Usability Engineering – Vorlesung 1 7 Visibility of the system status  Antwortzeit des Systems berücksichtigen  0,1 Sek: kein spezieller Indikator notwendig  1,0 Sek: User verliert das Gefühl von direkter, unmittelbarer Interaktion  > 10 Sek: User verliert Fokus, Status Indikator benutzen http://www.useit.com/papers/responsetime.html
  • 8. 8 Usability Engineering – Vorlesung 1 8 Match between the system and the real world  The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
  • 9. 9 Usability Engineering – Vorlesung 1 9 Match between the system and the real world  Unreflektierte Nachbildung von physischen Interfaces kann problematisch sein
  • 10. 10 Usability Engineering – Vorlesung 1 10 User control & freedom  Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.  Exits schaffen, wenn User Fehler machen  z.B.: Link zur Startseite auf jeder Webseite  z.B.: Standard-Einstellungen wiederherstellen
  • 11. 11 Usability Engineering – Vorlesung 1 11 User control & freedom  Undo und Redo unterstützen  „Never use a warning when you mean undo“  Google Mail – Nachricht löschen:  Google Mail – Label löschen:
  • 12. 12 Usability Engineering – Vorlesung 1 12 User control & freedom  Dem User keine fixen Pfade vorgeben  Beispiel: Wizards
  • 13. 13 Usability Engineering – Vorlesung 1 13 Consistency & Standards  Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  • 14. 14 Usability Engineering – Vorlesung 1 14 Consistency & Standards  Dieselben Kontrollelemente an derselben Stelle des Screens/Dialogs anzeigen  Vorhersagbarkeit  Konsistenz von Sprache und Grafiken  Konsistentes graphisches Erscheinungsbild (z.B. Widgets)  Konsistenz von Input  Konsistente Syntax durch das komplette System
  • 15. 15 Usability Engineering – Vorlesung 1 15 Consistency & Standards  Plattformkonventionen: Windows User Experience Interaction Guidelines, Apple Human Interface Guidelines, ...  Unternehmensinterne Styleguides  Design Patterns, Best Practices, Konkurrenzanalyse
  • 16. 16 Usability Engineering – Vorlesung 1 16 Error prevention  Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error- prone conditions or check for them and present users with a confirmation option before they commit to the action.  Verhindern von Fehlern, bevor diese Überhaupt auftreten Datum: Tag Monat Jahr Tag Monat Jahr 27.  1.  2012?   27.  Jänner  2012?   01/27/12?   ...  ??  
  • 17. 17 Usability Engineering – Vorlesung 1 17 Error prevention Korrekte Eingabe erzwingen: Eingabe flexibel verarbeiten: Kann schief gehen:
  • 18. 18 Usability Engineering – Vorlesung 1 18 Recognition rather than recall  Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
  • 19. 19 Usability Engineering – Vorlesung 1 19 Recognition rather than recall
  • 20. 20 Usability Engineering – Vorlesung 1 20 Recognition rather than recall Farbe Form
  • 21. 21 Usability Engineering – Vorlesung 1 21 Flexibility and efficiency of use  Accelerators - unseen by the novice user - may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
  • 22. 22 Usability Engineering – Vorlesung 1 22 Flexibility and efficiency of use  Erfahrene Benutzer sollen Tasks schneller und effizienter ausführen können als unerfahrene Benutzer (man soll sich verbessern können)  Kenntnis von solchen Shortcuts darf nicht vorausgesetzt werden
  • 23. 23 Usability Engineering – Vorlesung 1 23 Aesthetic and minimalist design  Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.  Auch: „Attractive Things Work Better“ – Donald Norman Siehe auch: http://www.interaction-design.org/encyclopedia/visual_aesthetics.html
  • 24. 24 Usability Engineering – Vorlesung 1 24 Aesthetic and minimalist design  Artikel: Rot  Navigation: Lila  Werbung: Grün  Related Stories: Gelb
  • 25. 25 Usability Engineering – Vorlesung 1 25 Help users recognize, diagnose, and recover from errors  Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
  • 26. 26 Usability Engineering – Vorlesung 1 26 Help users recognize, diagnose, and recover from errors  Was ist passiert?  Welche Teile des Systems sind betroffen?  Was ist die Ursache?  Wie kann ich das Problem beheben?
  • 27. 27 Usability Engineering – Vorlesung 1 27 Help and documentation  Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
  • 28. 28 Usability Engineering – Vorlesung 1 28 Help and documentation  Hilfe ist kein Ersatz für schlechte Usability!  Einfach zu durchsuchen  Kontextabhängig  gerade durchgeführter Task => Hilfe  Es sollen konkrete Schritte erklärt werden, die der User durchführen kann  Nicht zu umfangreich
  • 29. 29 Usability Engineering – Vorlesung 1 User Research
  • 30. 30 Usability Engineering – Vorlesung 1 30 User Centered Design  Früher Fokus auf Benutzer und deren Aufgaben  Empirische Beobachtung Idee Evaluierung Design User Research Prototyping • Sketching • Paper Prototyping • Wizard of Oz • … • Heuristische Evaluierung • Usability Test • Thinking Aloud • …
  • 31. 31 Usability Engineering – Vorlesung 1 31 Kluft zwischen Designer und Benutzer  Level 1: Der Designer ist der Benutzer  Level 2: Der Designer versteht das Produkt  Level 3: Design für eine fremde Domäne
  • 32. 32 Usability Engineering – Vorlesung 1 32 User Research  Etwas von den Benutzern lernen...  Kritische Aspekte untersuchen  Offene Fragen beantworten  Neue Ideen finden  Datenerhebung durch...  Befragung  Beobachtung
  • 33. 33 Usability Engineering – Vorlesung 1 33 Herausforderung...
  • 34. 34 Usability Engineering – Vorlesung 1 34 Herausforderung...
  • 35. 35 Usability Engineering – Vorlesung 1 35 To design an easy-to-use interface, pay attention to what users do, not what they say. Self reported claims are unreliable, as are user speculations about future behaviour. - Jakob Nielsen
  • 36. 36 Usability Engineering – Vorlesung 1 36 Teilnehmer  Erhebung von Benutzer-Requirements  nicht Stakeholder-Requirements  Benutzer sind Personen, die mit dem System arbeiten  Stakeholder sind Personen oder Organisationen, welche von dem System betroffen sind und direkten oder indirekten Einfluss auf System Requirements haben  Benutzer sind auch Stakeholder (aber nicht die einzigen)
  • 37. 37 Usability Engineering – Vorlesung 1 37 Teilnehmer  Wer sind die Benutzer?  Bestehende Hierarchien durchbrechen, um die richtigen Teilnehmer zu erreichen  Bereitschaft: Teilnehmer sollten freiwillig und gerne mitmachen  Vertraulichkeit und Sicherheit: Im Vorhinein abklären und notwendige Befugnisse einholen  Verfügbarkeit: Zeitlich, geographisch  Die Teilnehmer im vorhinein kontaktieren und einen Termin vereinbaren  Ggf. Kompensation für ihre Zeit
  • 38. 38 Usability Engineering – Vorlesung 1 38 Wozu User Research?  Einbindung der Benutzer ist einer der bedeutendsten Faktoren für Erfolg oder Scheitern eines Software- Entwicklungsprojekts  Standish Group CHAOS Report (1995):  Project Success Factor #1: User Involvement  Project Challenged Factors: 1. Lack of User Input 2. Incomplete Requirements & Specifications 3. Changing Requirements & Specifications
  • 39. 39 Usability Engineering – Vorlesung 1 39 Wozu User Research?  Management von Erwartungen  Realistische Erwartungen  Keine bösen Überraschungen oder Enttäuschung  Co-Ownership  Benutzer nehmen aktiv am Entwicklungsprozess teil  Verringert Widerstand gegen Veränderungen  Erhöht spätere Akzeptanz
  • 40. 40 Usability Engineering – Vorlesung 1 40 ...aber: Users are not Designers!  „No amount of data analysis can make up for a lack of talent.“ (Jeffrey Zeldman)  „Users (and their data) should be there to inform designers, not substitute for them.“ (Dan Saffer) Es geht nicht darum Designer zu ersetzen!
  • 41. 41 Usability Engineering – Vorlesung 1 41 User Research Methoden
  • 42. 42 Usability Engineering – Vorlesung 1 42 Welche Methode? http://www.useit.com/alertbox/user-research-methods.html
  • 43. 43 Usability Engineering – Vorlesung 1 43 Welche Methode? http://www.useit.com/alertbox/user-research-methods.html
  • 44. 44 Usability Engineering – Vorlesung 1 44 User Research im Designprozess  Idealfall: Iterativ in kleinen Schritten Quelle: Adaptive Path
  • 45. 45 Usability Engineering – Vorlesung 1 Contextual Inquiry
  • 46. 46 Usability Engineering – Vorlesung 1 46 Definition Usability  „Usability eines Produktes ist das Ausmaß, in dem es von einem bestimmten Benutzer verwendet werden kann, um bestimmte Ziele in einem bestimmten Kontext effektiv, effizient und zufriedenstellend zu erreichen.“ (ISO 9241)
  • 47. 47 Usability Engineering – Vorlesung 1 47 Nutzungskontext
  • 48. 48 Usability Engineering – Vorlesung 1 48 Nutzungskontext “When people research technology [they often start at] the point at which someone picks up the telephone or starts typing on the keyboard. For me that’s already far too down in the process. You want to know; Where does that PC live in someone’s home? How did they acquire it? What else is around it? And even one step back further than that: What do people care about? What motivates them? What gets them up in the morning? What do they do when they get up in the morning?” – Genevieve Bell
  • 49. 49 Usability Engineering – Vorlesung 1 49 Nutzungskontext “Always design a thing by considering it in its next larger context - a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” – Eliel Saarinen
  • 50. 50 Usability Engineering – Vorlesung 1 50 Quelle: Giant Ant
  • 51. 51 Usability Engineering – Vorlesung 1 51 Contextual Inquiry  Spezielle Form von Interviews  Direkt im Kontext der Benutzer  Beobachten von realen Benutzern, die reale Aufgaben in ihrer Arbeitsumgebung ausführen  Wissen über die Problemdomäne, (Arbeits-) Kultur, physische und soziale Grenzen sammeln  Vertrauen zu Benutzern aufbauen, die eventuell später das Produkt evaluieren  Dieses Wissen kann benutzt werden um im Entwicklungsprozess fundierte und damit bessere Entscheidungen zu treffen.
  • 52. 52 Usability Engineering – Vorlesung 1 52 Thoughtless Acts  Menschen interagieren oft unerwartet oder unbewusst mit ihrer Umwelt  Solche Dinge lassen sich meist nicht außerhalb des realen Nutzungskontexts erfassen  Liefern Möglichkeiten für Verbesserungen oder neue Designs
  • 53. 53 Usability Engineering – Vorlesung 1 53
  • 54. 54 Usability Engineering – Vorlesung 1 54
  • 55. 55 Usability Engineering – Vorlesung 1 http://www.flickr.com/groups/thoughtlessacts/
  • 56. 56 Usability Engineering – Vorlesung 1 56 Vier Prinzipen von Contextual Inquiry 1. Kontext  Aktuelle Erfahrungen vs. Zusammengefasste Erfahrungen  Konkrete Daten vs. Abstrakte Daten 2. Partnership  Beziehung zum Benutzer herstellen  Benutzer ist Experte in seiner Arbeit 3. Interpretation  Der Beobachtung eine Bedeutung geben 4. Fokus  Zuhören, Erkunden und Eingrenzen auf eine klares Ziel
  • 57. 57 Usability Engineering – Vorlesung 1 57 Kontext  Verstehen der Arbeit in der natürlichen Umgebung  Zum Benutzer gehen  Arbeit dort beobachten, wo sie normalerweise erledigt wird  Die Benutzer interviewen, während sie arbeiten  Entdecken von Details und Problemen vor Ort bei der Arbeit  Beobachten und Aufzeichnen von konkreten, handfesten Daten
  • 58. 58 Usability Engineering – Vorlesung 1 58 Kontext  Welche Faktoren bestimmen den Kontext des Benutzers?  Physischer Arbeitsplatz  Art der Arbeit – Aufgaben, Abläufe  Ziele der Arbeit  Sprache des Benutzers  Benutzte Hilfsmittel  Physische Artefakte  Platzierung von Objekten  Häufig vs. selten benutzt  Andere Benutzer und wie sie zusammenarbeiten  Organisation in der Firma  Kulturelle Einflüsse  Ziele des Unternehmens
  • 59. 59 Usability Engineering – Vorlesung 1 59 Partnership  Beziehung zum Benutzer herstellen  Unterdrücken der eigenen Erwartungen und Vorstellungen  Der Benutzer ist der Experte - er ist die einzige Person, die wirklich alles über seine Arbeit weiß  Wie erreicht man „Partnership“?  Den Benutzer die Konversation leiten lassen  Offene Fragen verwenden  Zuhören  Non-verbale Kommunikation beachten  Erwarten, etwas zu lernen
  • 60. 60 Usability Engineering – Vorlesung 1 60 Interpretation  Der Beobachtung eine Bedeutung geben  Gemeinsam mit dem Benutzer  Aktives Beobachten vor Ort  Verifizierte Interpretationen hervorheben:  Ein Faktum sollte immer mit einer Referenz zur Transkription oder Video versehen sein  Alles was markiert ist sind konkrete Daten  Alles andere sind nicht verifizierte Interpretationen
  • 61. 61 Usability Engineering – Vorlesung 1 61 Fokus  Perspektive einbringen  Auf einen Fokus beschränken hilft meist mehr Details zu sehen  Ein zu enger Fokus birgt das Risiko, dass man etwas übersieht  Das Setzen eines Fokus hat verschiedene Vorteile:  Bestimmt die Auswahl der Teilnehmer  Hilft bei limitierter Interviewzeit  Lenkt Fragen ans Ziel  Schafft Verständnis und lenkt die Konversation
  • 62. 62 Usability Engineering – Vorlesung 1 62 Beobachtung  Aufgaben, Abläufe und Tätigkeiten  Rolle des Benutzers in der Organisation  Verantwortungen innerhalb der Rolle  Formen der Kommunikation  Organisation der physischen Arbeitsumgebung  Sämtliche Hilfsmittel und Werkzeuge  Ziele und Bedürfnisse  Schwierigkeiten und erprobte Lösungsansätze mit vorhandenen Werkzeugen  Struktur von verwendeten Daten
  • 63. 63 Usability Engineering – Vorlesung 1 63 Aufzeichnungen  Sichergehen, dass alles aufgezeichnet wird:  Arbeitsprozess und Aufgaben  Probleme bei der Arbeit  Benutzte Tools  Designideen und Bestätigungen  Sprache des Benutzers  Beobachtung  Gute Notizen machen!  Auch wenn man Audio und Video Equipment dabei hat
  • 64. 64 Usability Engineering – Vorlesung 1 64
  • 65. 65 Usability Engineering – Vorlesung 1 designing comfort deco.inso.tuwien.ac.at deco@inso.tuwien.ac.at