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:07] 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 18: | Zeile 22: | ||
* Die vier Usability-Aspekte stehen im Vordergrund | * Die vier Usability-Aspekte stehen im Vordergrund | ||
* Modellgetrieben | * Modellgetrieben | ||
+ | * Offen für Innovationen | ||
+ | * Iterationen sind möglich, aber nicht Ziel! | ||
* Technologie wird komplett außen vor gelassen | * Technologie wird komplett außen vor gelassen | ||
- | * Offen für Innovationen | + | * Abgrenzung **User**-centered Design |
- | * Definierte Methoden sind lehr- und erlernbar | + | |
- | * Abgrenzung User-centered Design | + | |
* Ablauf | * Ablauf | ||
* Benutzer identifizieren (gegen Systemakteure abgrenzen) | * Benutzer identifizieren (gegen Systemakteure abgrenzen) | ||
* Benutzerrollen modellieren | * Benutzerrollen modellieren | ||
- | * Aufgaben identifizieren | + | * Aufgaben (Task Cases) identifizieren (etwas, das Akteure in ihren Rollen tun: **was** und **warum**?) |
- | * Gruppierung der Aufgaben (Priorisierung) | + | * User intention <-> System responsibility |
+ | * 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? | ||
+ | * divide and conquer | ||
+ | * "Magie" aus dem Prozess nehmen -> durch mehr Menschen durchführbar, delegierbar, kommunizierbar (Management) | ||
+ | * Definierte Methoden sind lehr- und erlernbar und wiederholbar | ||
+ | * es wird nur modelliert, was benötigt wird | ||
+ | * Gute Modelle | ||
+ | * frei von Technologie | ||
+ | * abstrakt | ||
+ | * einfach | ||
+ | * generalisiert | ||
+ | * Konzentration auf das Wesentliche | ||
+ | * **Task Map** | ||
+ | * 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) | ||
+ | * Ergebnis: Mehrere Task-Cluster | ||
+ | * **Navigation Map** | ||
+ | * 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 | ||
+ | * 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 ===== |