Human Factors - Heuristic Evaluation

Eine Form der Evaluation von User Interfaces ist die heuristische Evaluation. Hierbei betrachten Experten ein User Interface und benutzen Ihre Expertise über allgemein anerkannte Schwachstellen, um es zu bewerten.
typische Problemstellen nach Nielsen:

• einfache und natürliche Dialoge?
• wird die Sprache des Users benutzt oder eine technische Systemsprache (Bsp.: Error: Systembuffer overload) ?
  
• muss sich der User zu viel merken? (Informationen die der User noch benötigt sollen weiterhin angezeigt werden)
• Konsistenz des Interfaces
• bekommt der Benutzer Feedback?
• gibt es klar definierte Exit-Points?
• Shortcuts
• Fehlermeldungen müssen sinnvoll sein und weiterhelfen
• Fehler möglichst vermeiden
  

Human Factors - Designpatterns (Bsp.: Process Funnel )

Design Patterns sind allgemeine Vorlagen, die dazu dienen standardisierte Lösungen für gleichartige Probleme zu bieten.
Sie dienen dazu, Expertenwissen zu kapseln. Ein Experte könnte vermutlich zu einem speziellen Problem eine bessere Lösung finden, als ein allgemeines Design Pattern bietet.
Da aber Experten teuer und rar sind, bietet sich ein Patternbasierter Ansatz an, um schneller zu einem zufriedenstellenden Ergebnis zu kommen.

Im folgenden betrachten wir das Pattern "Process Funnel", für die meisten Nuttzer in Form eines "Wizard" oder "Assistenten" bekannt. Im besonderen sind bei der Verwendung von "Process Funnel" folgende Punkte zu beachten:

• komplizierte Vorgänge in mehrere zusammenhängende Schritte aufteilen
• Problem: Back-Funktion
  
• dürfen nicht zu lang sein
• Nutzer muss erkennen können, wie weit er im Prozess ist

Human Factors - Prototyping

Wie in den klassischen Ingenieurwissenschaften dienen Prototypen auch bei der Software Entwicklung dazu, Konzepte auf ihre Tauglichkeit zu überprüfen oder Feedback zu einer angestrebten Lösung einzuholen.
Prototypen bieten immer die Möglichkeit, für verschiedene Stakeholder über Produkte zu sprechen, die noch in der Entwicklung sind.

Arten nach Ausführung

• low fidelity (Papier)
• high fidelity (klickbare UI)

Arten nach Focus

• vertikal
• horizontal
• diagonal

Prototypen können alles mögliche sein: PowerPoints, Tafelbilder, Holzstücke, Photoshop Drawings, Websites, Software, Flash,...


Ziele:

• Evaluation
• Feedback
• Kommunikation
• Stakeholder Info
• PoC
  

The Elements of User Experience

Im User Centered Design Process geht es darum, eine möglichst optimale Gestaltung der Interaktion zwischen dem (archetypischen) Benutzer und einem interaktiven System zu gestalten, damit eben auch die User Experience.

Jesse James Garret stellt in seinem Buch "The Elements of User Experience " eine Hierarchie der Elemente der User Experience vor:

1. Strategie (input Benutzer / Kontext / Business goals)
   
2. Scope (output task analyse)
   
3. Structure (Navigation und "Pageflow" des User Interface)
   
4. Skeleton (Screenlayout und funktionale Teile des Screens == Wireframe)
   
5. Surface (fertiges visuelles Design)
   

Ein Element kann das folgende validieren, muss aber nicht vollständig sein, um das folgende zu erstellen. Die einzelnen Schritte werden also iterativ (auch stufenübergreifend) durchlaufen.
Näherer Informationen findet man auf Garrets Website.

Human Factors - Usability Return of Investment

Usability - ROI
Usability ist ein teurer Spaß, beschäftigt man doch hochbezahlte Experten, die wiederum Stakeholder von der Arbeit abhalten und nach einem langen UCD hat man oft noch keine Zeile Code entwickelt.
Daher die Frage: Lohnt sich der Aufwand? Was bekomme ich zurück für meine Investition?


Returns:

• erhöhte Produktivität der Benutzer
• Reduzierung der nutzerverursachten Fehler
• geringere Schulungskosten
  
• geringere Entwicklungskosten durch besseres Anforderungsmanagement
• geringere Supportkosten (vgl. "Ein anruf bei der Hotline vernichtet Gewinn bei diesem Kunden")
• höhere Zufriedenheit der Benutzer (-> Motivation)
• höhere Zufriedenheit der Kunden (-> Marktanteil)

Für alle Freunde betriebswirtschaftlicher Kennzahlen lässt sich der ROI auch berechnen:

Berechnung der Einsparung von Mitarbeiterarbeitszeit (z.B. keine redundante Eingabe in versch. Systeme, automatisierungen, Workflowunterstützung):
(eingesparte Zeit / Arbeitszeit) x Kosten pro Angestellter x Mitarbeiterzahl = Einsparung

Einsparung von Kosten durch Bedienfehler
Fehleranzahl x Reparaturdauer x durchschn. Stundensatz = Kosten durch Bedienfehler

Human Factors - Usability Design Prinzipien

Auch beim Erstellen der Benutzerschnittstellen gibt es gewisse Prinzipien, die man beherzigen sollte.

Designprinzipien sind abstrakter, als etwa Design Patterns. Es gibt sie projektspezifisch und allgemein.
Manche Prinzipien haben eine gewisse allgemeingültigkeit, andere beziehen sich auf bestimmte Kontexte oder Systeme.

Als allgemeine Anleitung, wie man Design Prinzipien findet, könnte das folgende gelten:

Design Prinzipien = theoretisches Wissen + Erfahrung + gesunder Menschenverstand

• klare Beschriftungen (Labels) wählen
• klare Mappings ermöglichen (wenn ich hieran etwas ändere, wird sich folgendes ändern...)
• Nähe ermöglicht Mapping
• Farbcodierung ermöglicht Mapping
• siehe Gestaltgesetze
• nur die Aktionen zulassen, die im Moment erlaubt sind ("ausgrauen")
• phyische Einschränkungen nutzen (z.B. Floppy kann nur auf eine Art in das Laufwerk eingelegt werden)
• logische Einschränkungen nutzen (Metaphern und mentale Modelle aus dem Alltag nutzen, z.B. Ampel)
• kulturelle Vereinbarungen nutzen (international vs. spezifisch)
• Feedback an den User geben, wenn eine Handlung ausgelöst wurde
• "Wenn Anweisungen von Nöten sind, gibt es Raum für Verbesserungen"
• "Dinge, die unterschiedlich aussehen, sollten sich unterschiedlich Verhalten. - Dinge die gleich aussehen, sollten sich gleich verhalten"
• Konsistent bleiben

Probleme von Design Prinzipien:

• zu allgemein oder zu trivial (zu abstrakt oder zu konkret)
  
• schwierig das Richtige für den Kontext zu finden
• schwierig zu interpretieren (für ein spezifisches System)
• teilweise widersprüchlich
• mögliche Alternative: Design Patterns ("Baukasten")
  

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
  

Human Factors - Begriffsabgrenzungen

Einige Stichworte zum Thema Human Factors / Human Computer Interaction:

• Usefullnes (Nützlichkeit)
• ein interaktives System kann zum Erreichen bestimmter Ziele genutzt werden
• Utility (Nutzwert)
• die Funktionalitäten des Systems um die Ziele zu erreichen sind prinzipiell im System enthalten
  
• Usability (Benutzerfreundlichkeit)
  
• wie gut können benutzer die Funktionalitäten nutzen
• Effektivität + Effizienz + Zufriedenheit
  

Ein interaktives System sollte folgende Anforderungen erfüllen:

• Aufgabenangemessenheit
• Selbstbeschreibungsfähigkeit
• Erwartungskonformität
• Fehlertoleranz
• Steuerbarkeit (Dialog steuerbar? -> Richtung/Geschwindigkeit beeinflußbar, undo-Funktion)
• Individualisierbarkeit
• Lernförderlichkeit (System ermöglicht es dem Benutzer an ihm zu wachsen)
• Memorierbarkeit (Einarbeitung nach längerer Nutzungspause?)
  

Speichermodell

Im Programmierumfeld betrachten wir vier Speichersegmente:

1. Code-Segement (auch Text-Segment genannt)
2. Data-Segment
3. Heap
4. Stack

Im Code-Segment sind die ausführbaren (Programm-)Codezeilen gespeichert, übrigens auch der Startup-Code der vor der main ausgeführt und den Terminate-Code, der nach Beenden des eigentlichen Programms ausgeführt wird. Das Code-Segment ist während der Programmausführung read-only.
Im Data-Segement befinden sich die Daten, die über die gesammte Programmlaufzeit erhalten bleiben (globale und statische Variablen). Es besteht aus einem const-Bereich, und je einem Bereich für initialisierte und nicht-initialisierte Daten.
Das Heap-Segment ist gleichbedeutend mit dem freien Arbeitsspeicher, der zur Laufzeit allokiert werden kann.
Das Stack-Segment ist ein LIFO (Kellerspeicher) und nur durch push/pop , aber nicht wahlfrei zugreifbar. Auf dem Stack werden lokale Daten abgelegt, sowie Rücksprungadressen und Parameter von Funktionen.

Ablauf der Speicherzugriffe eines Programmes:

1. nach compiling/binding -> load des Programmes (in den Prozessorspeicher)
2. Loader legt Maschinenbefehle ins Code-Segment
3. Instruktionszeiger zeigt auf den ersten auszuführenden Befehl im Code-Segment
4. Programm im Code-Segment wird linear abgearbeitet.
5. erfolgt ein Funktionsaufruf, wird in die entsprechende Stelle im Code-Segment gesprungen - der letzte Instruktionszeigerwert(Rücksprungadresse) wird auf dem Stack gelegt und die Einsprungadresse in den Instruktionszeiger geladen.
6. beim Verlassen der Funktion wird die alte Adresse vom Stack geholt und das Programm bei der nächsten folgenden Adresse fortgesetzt.

• Über den Stack können auch Parameter an die Funktion übergeben oder Return-Werte an das Hauptprogramm zurück gegeben werden.
• Variablenübergaben (bei C/C++) erfolgen durch Übergabe der Werte, indem die Werte auf den Stack geschrieben werden. Entweder durch Schreiben des Wertes (primitive Datentypen) oder Aufruf des Copy-Konstruktors (Objekte und Klassen) -> Call-by-Value
  
• Möchte man Call-by-Reference einsetzen, muss man explizit Zeiger oder Referenzen übergeben.