Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
se:usability [2008-02-23 18:30] stefan |
se:usability [2008-02-23 19:25] stefan |
||
---|---|---|---|
Zeile 9: | Zeile 9: | ||
* Leistung | * Leistung | ||
* Aufgabenunterstützung | * Aufgabenunterstützung | ||
+ | * 3 Säulen | ||
+ | * Usability Workshop | ||
+ | * Site Visits/User Interviews | ||
+ | * Usability Evaluation | ||
* Was wurde bei Usability falsch gemacht? | * Was wurde bei Usability falsch gemacht? | ||
* Design | * Design | ||
Zeile 29: | Zeile 33: | ||
* Gruppierung der Aufgaben (Priorisierung) -> Task Map, Navigation Map | * Gruppierung der Aufgaben (Priorisierung) -> Task Map, Navigation Map | ||
* Darstellung und Interaktionen ableiten | * Darstellung und Interaktionen ableiten | ||
+ | * User performance | ||
+ | * Benutzer müssen schneller/besser mehr/neue Aufgaben lösen können | ||
+ | * Hilfe bei Problemlösung anbieten, Anfänger/Experten berücksichtigen | ||
+ | * Fokus auf Performance -> alles zu berücksichtigen geht nicht! | ||
+ | * Warum? schnellerer Einstieg, geringere Trainigs-/Supportkosten, erhöhte Effizienz/Kundenzufriedenheit, Fehlervermeidung | ||
* Wozu methodisches Vorgehen? | * Wozu methodisches Vorgehen? | ||
+ | * divide and conquer | ||
* "Magie" aus dem Prozess nehmen -> durch mehr Menschen durchführbar, delegierbar, kommunizierbar (Management) | * "Magie" aus dem Prozess nehmen -> durch mehr Menschen durchführbar, delegierbar, kommunizierbar (Management) | ||
* Definierte Methoden sind lehr- und erlernbar und wiederholbar | * Definierte Methoden sind lehr- und erlernbar und wiederholbar | ||
Zeile 39: | Zeile 49: | ||
* generalisiert | * generalisiert | ||
* Konzentration auf das Wesentliche | * Konzentration auf das Wesentliche | ||
- | * Task Map | + | * **Task Map** |
* Enthält alle Task Cases mit ihren Beziehungen zueinander. | * Enthält alle Task Cases mit ihren Beziehungen zueinander. | ||
* Ziel ist, die Tasks zusammenzubringen, die zusammengehören um eine Aufgabe zu lösen (interaction, simple navigation) | * Ziel ist, die Tasks zusammenzubringen, die zusammengehören um eine Aufgabe zu lösen (interaction, simple navigation) | ||
* Ergebnis: Mehrere Task-Cluster | * Ergebnis: Mehrere Task-Cluster | ||
- | * Navigation Map | + | * **Navigation Map** |
* Enthält alle Task-Cluster und die zwischen ihnen vorgesehenen Navigationspfade | * Enthält alle Task-Cluster und die zwischen ihnen vorgesehenen Navigationspfade | ||
* Ziel ist, die Navigation im Programm zu vereinfachen, insb. für die zentralen Aufgaben | * Ziel ist, die Navigation im Programm zu vereinfachen, insb. für die zentralen Aufgaben | ||
* Ergebnis: Erste Struktur des Programms. | * Ergebnis: Erste Struktur des Programms. | ||
+ | * Prototypen | ||
+ | * Verfeinerung und Bewertung des Designs | ||
+ | * Planung vor der Implementierung | ||
+ | * Feedback von Benutzern einholen | ||
+ | * Verschiedene Ansätze evaluieren | ||
+ | * **Abstract Prototype** | ||
+ | * Füllt die Lücke zwischen Task-Modell und Implementierung: sonst müssten Daten/Aktionen und grafischer Entwurf in einem Schritt erledigt werden | ||
+ | * bringt Daten/Aktionen in eine logische Reihenfolge/Anordnung | ||
+ | * **Visual Prototype** | ||
+ | * Erste Version (passiv): Visualisierung der im AP festgelegten Reihenfolge, **Test der Interaktion mit dem Benutzer**, Optimierung des Designs (Idealvorstellung der Oberfläche) | ||
+ | * Zweite Version (aktiv): Machbarkeit zeigen, Vorführung beim Kunden -> Vorlage für die Entwicklung | ||
+ | * Usability Workshops | ||
+ | * Anforderungen -> Usability Workshop -> Entwicklungsspezifikation | ||
+ | * Produkt-, Projektmanager, Entwickler, Usability-Spezialist | ||
+ | * Interviews/Site Visits werden durchgeführt | ||
+ | * Benutzer sollen nur sagen, warum sie etwas tun, nicht wie | ||
+ | * Unvorbereitetes, stummes Zuschauen bei der Arbeit kann neue Verbesserungspotentiale aufdecken | ||
+ | * "low tech": Flipcharts, Karten, Pinnwände | ||
+ | * Vorteile: Alles ist sichtbar, begrenzter Platz -> Fokus auf zentrale Fragen, taktile Sinneswahrnehmung, einfache Arbeit (verschieben/verwerfen) und kostengünstiges Material | ||
+ | * Die **Software-Architektur** muss Usability-Aspekte berücksichtigen, da sonst evtl. benötigte Daten/Aktionen nicht an den vorgesehenen Stellen angeboten werden können | ||
+ | * **Usability Inspection** | ||
+ | * Strukturierter Prozess mit Benutzer, Designer und Entwickler | ||
+ | * Kann bereits auf Papierprototypen angewandt werden | ||
+ | * Ziel: Defekte identifizieren, nicht beheben/diskutieren! | ||
+ | * Dem Benutzer wird ein Ziel vorgegeben, nicht der Weg! | ||
+ | * Wird für bestimmte Szenarien durchgespielt (mit 3-4 unterschiedlichen Benutzern je Szenario -> allgemeine Defekte finden) | ||
+ | * Design Rules/Principles | ||
+ | * Structure/Workflow (Microsoft U) | ||
+ | * Logical Organization according to task | ||
+ | * Association/Disassociation (lines, color, shape etc.) | ||
+ | * Organization (white space, borders, alignment, size etc.) | ||
+ | * Dialog boxes are bad! | ||
===== Exercises ===== | ===== Exercises ===== |