TU Wien:Socially Embedded Computing VU (Ganhör)/Stoffzusammenfassung SS15-User-Centered-Design
Zur Navigation springen
Zur Suche springen
User centered design[Bearbeiten | Quelltext bearbeiten]
Wer ist der User?[Bearbeiten | Quelltext bearbeiten]
- Wie sieht er/sie aus?
- Wie alt ist er/sie?
- Was sind seine/ihre Interessen?
- Was mag er/sie?
- Was mag er/sie nicht?
Wicked vs. Tame Problems[Bearbeiten | Quelltext bearbeiten]
Horst Rittel unterschied zwischen Problemklassen.
- “wicked”: schwer zu identifizieren (z.B.: Atomkraftwerke, Privatsphärendiskussion,...)
- "tamed”: einfach zu identifizieren (Probleme die genau beschrieben werden können, ggT-Algorithmus)
Wicked Problems[Bearbeiten | Quelltext bearbeiten]
"... class of social system problems which are illformulated, where the information is confusing, where many [shareholders] have conflicting values, and where the ramifications (Auswirkungen) in the whole system are thoroughly confusing"
- kreative Problemlösung vs. rationale Problemlösung
- kreative Problemlösung kann wicked problems in tamed problems wandeln
Horst Rittel[Bearbeiten | Quelltext bearbeiten]
- hat den Begriff wicked Problem geprägt
- einfache Probleme (=Probleme die schon definiert sind), sind leicht zu lösen, da das definieren des Problems an sich schon die Lösung definiert
- die Definition eines Problems ist subjektiv. Aus Sicht eines Betrachters. Wenn man ein Problem definiert, sind alle Stakeholder, Experten und Designer auf gleichem Wissensstand (oder Unwissensstand)
- manche Probleme können nicht gelöst werden, da Stakeholder der Definition nicht zustimmen können. -> wicked problems
- einfache Probleme zu lösen kann zu einer Verbesserung führen, jedoch zu keiner Innovation
Wie können wicked problems gelöst werden?[Bearbeiten | Quelltext bearbeiten]
- da eine Person alleine nicht alle Variablen (existierende, wünschenswerte Zustände) verfolgen kann, braucht es zur Vereinfachung eines wicked problems in ein tamed problem mehrere Personen
- diese Personen müssen miteinander reden, nachdenken & diskutieren
- diese Personen müssen Ziele und Handlungen vereinbaren, wie diese Ziele erreicht werden. Das benötigt wissen über die Handlungen, nicht nur Fakten
- Argumentation ist der Schlüssel und womöglich die einzige Methode wicked Problems zu bändigen
- Wicked Problems zu lösen ist ein politischer Prozess
- Design ist politisch
Warum scheitern Projekte?[Bearbeiten | Quelltext bearbeiten]
- unrealistische, undeutliche Projektziele
- ungenaue Abschätzungen der benötigten Ressourcen
- schlecht definierte Vorraussetzungen(Requirements)
- schlechte Berichterstattung über den Projektstatus
- unmanaged risks
- schlechte Kommunikation zwischen Kunden, Entwicklern und Benutzern
- Benutzung von unausgereiften Technologien
- Unfähigkeit die Komplexität des Projekts zu bewältigen
- schlampige Entwicklung
- schlechtes Projektmanagement
- Stakeholderpolitik
- kommerzieller Druck
User centered design kann helfen, einige dieser Punkte zu entschärfen.
Methoden des User centered designs[Bearbeiten | Quelltext bearbeiten]
Sketching[Bearbeiten | Quelltext bearbeiten]
Einfache Methode, den Usern erste Statements zu (noch unvollkommenen) Ideen zu entlocken.
- kein existierendes System
- einfach anzuwenden
- geläufige Sprache
- einfach zu Verändern
- Grundstock für alle Beteiligten
- Wireframing
Wizard of Oz[Bearbeiten | Quelltext bearbeiten]
Eine Methode, um ein funktionierendes System "vorzutäuschen".
- kein existierendes System
- Mensch (wizard) simuliert das System
- Interaktion durch ein technisches Interface
Scenarios[Bearbeiten | Quelltext bearbeiten]
Eine Methode, um frei zu diskutieren, was wäre, wenn ein bestimmter Fall einträte.
- was wäre, wenn...
- geläufige Sprache für Techniker und Benutzer
- Benutzer, Ziele, Hintergrund, Vereinbarungen
- wiederholen, verfeinern, ändern von Szenarien
- mit allgemeinem Ziel starten, mit spezifizierter Aufgabe enden
Prototyping[Bearbeiten | Quelltext bearbeiten]
Unfertige Implementierungen schnell einsetzen, um früh eine Rückmeldung zu bekommen.
- kontinuierliche Iteration und Erweiterung
- explorative Prototypen
- visuelle Prototypen
- funktionale Prototypen
- Papierprototpen
- low-fi, hi-fi
Storytelling[Bearbeiten | Quelltext bearbeiten]
Erzählung nutzen...
- um Konflikte zu lösen
- um die Vergangenheit zu interpretieren
- um die Zukunft zu gestalten
- um zu begründen
Videoanalyse[Bearbeiten | Quelltext bearbeiten]
- Testpersonen suchen und einweisen (ethische Regeln,...)
- Videogerät platzieren und Situation filmen (Blickwinkel, Aufnahmekapazität,...)
- Videoaufnahme durchführen
- Videoaufnahme analysieren (quantitative, qualitative Analyse)
- Problem: User verhalten sich (möglicherweise) anders, wenn Sie beobachtet werden.
Wann wird User centered design benötigt?[Bearbeiten | Quelltext bearbeiten]
- immer wenn es benötigt wird
- um menschliche Faktoren einzubinden
- für arbeitswissenschaftliches Wissen
- um menschliche Arbeitsbedingungen zu verbessern
- um den Nutzerkontext zu verstehen und zu spezifizieren
- um den User und organisatorische Vorraussetzungen zu spezifizieren
- um Designlösungen zu entwickeln
- um Design gegen die Vorraussetzungen zu testen
Probleme[Bearbeiten | Quelltext bearbeiten]
- UCD ist nicht Problemlöser für alles
- UCD kann aber einige Problemfelder vermeiden und andere entschärfen
- Benutzer können falsch liegen
- Benutzer können gegen Veränderungen resistent sein
- Benutzer können Nachteile vermuten (z.B.: von technischen Systemen ersetzt zu werden)
- Benutzerziele vs. Spezifikationsziele