Benutzer-Werkzeuge
se:usability
Unterschiede
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-01-14 16:10] stefan |
se:usability [2008-02-23 19:53] stefan |
||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | ===== Klausur ===== | ||
| + | * **Usability** bezeichnet das Ausmaß zu dem ein Programm von festgelegten Benutzern verwendet werden kann, um festgelegte Ziele effektiv, effizient und zufriedenstellend in einem gegebenen Kontext zu erreichen. | ||
| + | * Kontext: Benutzer, Ausgabe, Ausstattung | ||
| + | * Maße: Effektivität, Effizienz, Zufriedenheit | ||
| + | * **Ergonomie** ist sowohl eine wissenschaftliche Disziplin, die sich mit dem Verständnis von Interaktionen zwischen Menschen und Systemen beschäftigt, als auch der Beruf, der die Theorie, Prinzipien, Daten und Methoden anwendet, um die Leistung eines Systems und das Wohlbefinden des Menschen, der damit arbeitet, zu optimieren. | ||
| + | * Usability konzentriert sich auf: | ||
| + | * Benutzung | ||
| + | * Aufgabe | ||
| + | * Leistung | ||
| + | * Aufgabenunterstützung | ||
| + | * 3 Säulen | ||
| + | * Usability Workshop | ||
| + | * Site Visits/User Interviews | ||
| + | * Usability Evaluation (Methode: Usability Inspection) | ||
| + | * Was wurde bei Usability falsch gemacht? | ||
| + | * Design | ||
| + | * Prozess | ||
| + | * Benutzer | ||
| + | * Kurz gesagt: Usability wurde als unwichtig abgetan, Produkt konzentriert sich nicht auf Aufgaben der Benutzer | ||
| + | * Usage-centered Product Design | ||
| + | * Spezifikation aus Kundensicht | ||
| + | * Die vier Usability-Aspekte stehen im Vordergrund | ||
| + | * Modellgetrieben | ||
| + | * Offen für Innovationen | ||
| + | * Iterationen sind möglich, aber nicht Ziel! | ||
| + | * Technologie wird komplett außen vor gelassen | ||
| + | * Abgrenzung **User**-centered Design | ||
| + | * Ablauf | ||
| + | * Benutzer identifizieren (gegen Systemakteure abgrenzen) | ||
| + | * Benutzerrollen modellieren | ||
| + | * Aufgaben (Task Cases) identifizieren (etwas, das Akteure in ihren Rollen tun: **was** und **warum**?) | ||
| + | * User intention <-> System responsibility | ||
| + | * Gruppierung der Aufgaben (Priorisierung) -> Task Map, Navigation Map | ||
| + | * 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) | ||
| + | * 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 ===== | ||
se/usability.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
