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:57] stefan |
se:usability [2008-02-23 19:53] stefan |
||
---|---|---|---|
Zeile 9: | Zeile 9: | ||
* Leistung | * Leistung | ||
* Aufgabenunterstützung | * Aufgabenunterstützung | ||
+ | * 3 Säulen | ||
+ | * Usability Workshop | ||
+ | * Site Visits/User Interviews | ||
+ | * Usability Evaluation (Methode: Usability Inspection) | ||
* 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 52: | Zeile 62: | ||
* Feedback von Benutzern einholen | * Feedback von Benutzern einholen | ||
* Verschiedene Ansätze evaluieren | * Verschiedene Ansätze evaluieren | ||
- | * Abstract Prototype | + | * **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 | * 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 | * bringt Daten/Aktionen in eine logische Reihenfolge/Anordnung | ||
- | * Visual Prototype | + | * **Visual Prototype** |
* Erste Version (passiv): Visualisierung der im AP festgelegten Reihenfolge, **Test der Interaktion mit dem Benutzer**, Optimierung des Designs (Idealvorstellung der Oberfläche) | * 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 | * Zweite Version (aktiv): Machbarkeit zeigen, Vorführung beim Kunden -> Vorlage für die Entwicklung | ||
Zeile 66: | Zeile 76: | ||
* "low tech": Flipcharts, Karten, Pinnwände | * "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 | * 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) | ||
+ | * Problem: Legacy User | ||
+ | * 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! | ||
+ | * Basic Design Rules | ||
+ | * support progressive usage (!) | ||
+ | * provide user assistance (!) | ||
+ | * learn from other errors | ||
+ | * follow trends | ||
+ | * good visual organization | ||
+ | * communication with users | ||
===== Exercises ===== | ===== Exercises ===== |