Human Factors - User Centered Design

Wie der Name schon sagt, wird beim User Centered Design Prozess der Benutzer in den Mittelpunkt der Betrachtung gestellt.

Dies erscheint als Forderung vordergründig trivial. Betrachtet man jedoch die heute etablierten Entwicklungsprozesse, so stehen meist noch immer fachliche (business processes) und technische Anforderungen im Fokus der Software Entwicklung. Der Benutzer wird oft erst in der Testphase oder gar beim Release der Software miteinbezogen.

Im User Centered Design wird dagegen versucht, eine auf die Benutzerzielgruppe maßgeschneiderte Lösung zu entwickeln. Für alle die mit klassischen Softwareentwicklungsprozessen vertraut sind, wir befinden uns der Requirements Phase.
Dabei wird in etwa so vorgegangen:

Informationen gewinnen: User / Task Analysis

• Analyse und Modellierung der Benutzer und ihrer Ziele, Aufgaben und Arbeitsstile (goals / tasks/working styles)
• Mittel:
  
• Dokumente analysieren (Manuals, Beschreibungen, Regeln, Business Processes...)
• Fragebögen (Factual vs. Opinion, multiple choice, numeric / text open-end questions)
  
• semi-structured Interviews in der Arbeitsumgebung des Benutzers (besser als (un)structured)
• goal-directed questions
• Opportunity: Welche Aktivitäten verschwenden Ihre Zeit?
• Goals: Was macht einen "guten Tag" aus?
• Priorities: Was ist Ihnen wichtig?
• Information: Was unterstützt den Entscheidungsprozess?
• system-oriented questions
• Function: Worin bestehen die gewöhnlichen Tätigkeiten, die Sie mit dem Produkt ausführen?
• Frequency: Welcher Teil des Produktes wird am häufigsten benutzt?
• Preference: Welche Teile des Produktes sind am angenehmsten, welche am unangenehmsten?
• Expertise: Welche Shortcuts nutzen Sie?
• workflow-oriented questions
• Process: Was war Ihre erste Handlung, als Sie heute zur Arbeit kamen? Und die nächste...
• Occurence und Reoccurence: Wie oft machen Sie dies? Was machen die jede Woche oder jeden Monat aber nicht täglich?
• Exception: Wie läuft ein typischer Tag ab? Was wäre ein ungewöhnliches Ereignis?
  
• Beobachtung
• Zeit mit den Stakeholdern verbringen, während sie arbeiten

Informationen aufbereiten: Personas und Scenarios, Requirements und Usability Goals

• Personas (= archetypische Benutzer)
• "lebendige" Beschreibungen
• Persona hat Ziele, Möglichkeiten, Neigungen und einen Hintergrund
• repräsentiert die Zielgruppe an greifbarem Beispiel
• gegen self-referential design
• Infos aus den Interviews / Observations die in die Personas einfließen:
• Activities: Was tut der User? (Frequenz und Ausmaß)
  
• Attitudes: Wie denkt der User über die Domäne des Produktes und die Technologie?
• Aptitude: (Aus)bildung des Users und seine Möglichkeiten zu lernen
• Motivations: Warum betägtigt sich der User in der Domäne des Produktes? (vgl. Interview: Wie wird man Fleischfachverkäuferin?)
  
• Skills: Möglichkeiten und Fähigkeiten des User capabilitiesbezogen auf die Domäne und Technologie
• Personatypen
• Primary Persona
  
• 1 pro Interfacevariante
• Interface muss auf die Primary Persona zugeschnitten sein, ohne andere Personas zu zu kurz kommen zu lassen
• Secondary Personas
• typischerweise 0-2
  
• Persona ist absolut zufrieden mit dem Interface der Primary Persona mit einigen Änderungen
• Negative Personas
• repräsentiert Nutzergruppe, die explizit beim Design nicht berücksichtigt wird
• Scenarios
• Scenarios haben ein erfüllbares Goal
• sie setzen sich aus kleineren Tasks zusammen
• nutzen Sprache der Stakeholder
• Fördern Verständnis warum Leute was wie tun
  
• Requirements
• spezifiert was ein Produkt tun soll / wie es sich verhalten soll
• so spezifisch, klar und eindeutig wie möglich
• Arten von Requirements:
• Functional
  
• Technological
• Data
• Environmental / Context
  
• System Use
• User
• Usability (->Usability Goals and Measures)
  
• Usability Goals
• klären Prioritäten
• auf ihrer Basis sind "tradeoff decisions" möglich
• Ermöglichen Fokusieren von Aufmerksamkeit und Resourcen

Ergebnisse veranschaulichen: Das Framework

• konzeptuelles Framework, das sowohl den Zielen der Personas als auch denen der Organisation gerecht wird
• Beschreibung zentraler Elemente und Features
• Beschreibung der Information Architecture und der Hauptbestandteile der Navigation
• UI Konzept (vorgegebene Workflows vs. freie Navigation, Multi- oder Singledocument, ...)
  

Refinement

• fertige Dokumentation kann an den Auftraggeber übergeben werden
• Specs und Styleguides
• UI Samples