28 Februar 2008

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

Labels: , ,

27 Februar 2008

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

Labels: , ,

26 Februar 2008

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

Labels: , ,

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.

Labels: , ,

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

Labels: , ,

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")

Labels: , ,

25 Februar 2008

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

Labels: , ,

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?)

Labels: , ,

14 September 2007

Don't let me do the computer's work - task design 1.0

Vor kurzem habe ich einige Familienphotos über den Onlinebilderservice des DM Drogeriemarks entwickeln lassen. Dabei musste ich mich über einen klassischen Usability Bug ärgern. Der Webservice wollte, dass ich die Arbeit des Computers übernehme.
Das hat mich umso mehr verwundert, als DM eine tolle Javaapplikation bietet, um die Bilder in Ihr System zu bekommen - sogar mit iPhoto Alben Unterstüzung.
Doch dann bekam ich folgende Mail:

vielen Dank für Ihre Bestellung bei dm-drogerie markt. Die Bearbeitung wird je nach Bestellung 2-5 Arbeitstage in Anspruch nehmen.<br /><br />Nach Fertigstellung werden Sie umgehend von uns per e-mail informiert.<br /><br />Auftragsnummer:        071412<br />Auftragswert:                  6.64<br />                                      (Bildpreis inkl. Bearbeitungsgebühr, Filialabholung und gesetzlicher Mehrwertsteuer)<br /><br />Zahlart:                         Filialabholung<br /><br />Filiale:<br />dm-drogerie markt (Filiale 0548)<br />Bliesstr. 66-68<br />66538 Neunkirchen Tel.: 06821/149946<br />contact: 00548<br /><br />Bei Rückfragen wenden Sie sich bitte an dm drogeriemarkt service@dm-digi-foto.de oder telefonisch an die Hotline 0800-2393-240.<br /><br /><br />Zu beachten :<br /><br />- Aufträge mit mehr als ca. 70 Bildern oder<br />- Aufträge mit mehr als einem Format <br /><br />werden in mehreren Auftragstaschen ausgeliefert. Alle Auftragstaschen haben die gleiche Auftragsnummer.<br /><br /><br />Ist mein Fotoauftrag schon fertig? www.dm-digifoto.de <br /><br />Mit freundlichen Grüßen<br /><br />     Ihr dm-DIGI-Foto<br />












Wenn ich also wissen wollte, wie der Auftragsstatus, sollte ich auf www.dm-digifoto.de gehen. Hmm zähneknirrschend ging ich davon aus, dass ich da dann die Auftragsnummer in irgendein Webformular eingeben muss. Schlimm genug, doch es geht auch noch blöder:

Ja, tatsächlich musste ich Auftrags- und Filialnummer eingeben. Für alle, die zwar die 6stellige Auftragsnummer, aber nicht die Filialnummer im Kopf haben (steht die eigentlich auf den Filialen? Müsste man mal nachschauen), bietet die Seite dann freundlicherweise einen Filialnummernfinder. (Danke, da habe ich schneller die E-Mail nochmal rausgesucht...)

Altruistisch wie ich bin, gebe ich DM hier mal einen kostenlosen Tipp. Dabei gehe ich von der Annahme aus, dass die E-Mails bei DM automatisch erzeugt und nicht von Hand geschrieben werden. Folgende Annahmen kann ich treffen, da sich alle Informationen aus der E-Mail, die ich erhalten habe ergeben:
  1. Das System kennt meine E-Mail
  2. Das System kennt die Auftragsnummer
  3. Das System kennt die Filialnummer
  4. Das System kennt die URL des Onlinephotoservices
Frage: Wie kann ich es dem Kunden jetzt ermöglichen, schmerzfrei seinen Auftragsstatus abzufragen?
Antwort: In die Mail setze ich einen Link der folgenden Art href="http://www.dm-digifoto.de/status.do?filiale=0548&auftrag=071412">Wann kann ich meine Bilder abholen?
Ob ich dann als Antwortseite eine so wenig Aussagekräftige, wie die aktuelle Anzeigen muss, lasse ich mal dahingestellt...

Technorati Profile

Labels: , , ,

25 Juli 2007

Neues aus dem Webgarten

leckerer Salat, hier leider noch in der Version 0.2 alpha
Wer mich persönlich kennt, weiss vermutlich, dass ich eigentlich kein begeisterter Salatesser bin. Um ganz ehrlich zu sein, esse ich Salat am liebsten, nachdem er durch ein ökologisch aufgezogenes Tier gewandert ist (klassischer Veredelungsprozess).

Nichtsdestotrotz gibt es Leute, die die Beilage zum Hauptgericht stilisieren. ;-) So mein Ex-Chef, der als kleines Sideproject zum Softgarten jetzt auch handfesteres Grünzeug verkaufen will.

Die Idee der Gastronomie 2.0 finde ich dagegen höchst interessant und bin daher auch zum regelmäßigen Leser seines Salad 2.0 Blogs geworden. Schleißlich könnte so eine interaktive Salatbar interessante Herausforderungen für Usability (Software und Hardware) und Projektmanagement bieten.

Wir lesen weiter und bleiben gespannt.
Technorati Profile

Labels: , ,