TU Wien:Socially Embedded Computing VU (Ganhör)/Stoffzusammenfassung SS15-User-Centered-Design

Aus VoWi
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