UXQB Foundation Level F

• Benutzererlebnis = User Experience
• Wahrnehmungen und Reaktionen einer Person bezüglich der erwarteten/tatsächlichen Benutzung eines Systems.
• Benutzererlebnis schliesst Usability ein. Usability-Kriterien können somit eingesetzt werden um Teile des Benutzererlebnisses zu evaluieren.
• Umfasst vor, während und nach der Benutzung:
• Gefühle, Meinungen, Bevorzugungen, Auffassungen und Leistungen

• Attribute eines Systems die Menschen mit eingeschränkten Fähigkeiten ermöglichen effektiv und effizient mit dem System zu interagieren.
• Standards und Richtlinien sind verfügbar und bei gewissen Unternehmen oder Ländern gesetzlich zu erfüllen.

• Benutzer, Aufgaben, Ressourcen und physische / soziale Umgebung in der das System genutzt wird.

• People = Benutzer
• Activities = Aufgaben
• Context = Umgebung (physisch und sozial)
• Technologies = Ressourcen / Ausrüstung

• Ergebnisse aus den Beobachtungen und kontextuellen Interviews werden in der Nutzungskontextbeschreibung dokumentiert.
  • Diese ist die Grundlage für das Identifizieren der Erfordernisse. Weiter können so die Erfordernisse auf den Nutzungskontext zurückgeführt werden.
• Beschreibt:
  • Benutzergruppen, Benutzergruppenprofile, Aufgaben, Umgebungen, Ausrüstung, Szenarien

• Dies ist die Gesamtheit der gegeben Umstände oder Bedingungen, in denen der Benutzer arbeitet. Diese umfassen die physische, soziale und technische Umgebung.
• Die soziale Umgebung schliesst die organisatorische Umgebung mit ein.

• Eine Aufgabe ist die Aktivität welche erforderlich ist um ein Ziel zu erreichen.
  • Ein Ziel ist ein angestrebtes Arbeitsergebnis.
• Aufgaben können meistens in Teilaufgaben unterteilt werden.
• Teilaufgaben können zum Teil wiederum in Teilaufgaben unterteilt werden.
• Teilaufgaben führen meistens zu Auswahlmöglichkeiten oder Eingaben des Benutzers während der Nutzung des Systems.

• Dies sind die wichtigsten Informationseinheiten oder Daten mit denen der Benutzer interagiert um seine Aufgabe durchzuführen.
• Englisch: Task Object

• Mit dieser Technik werden Kontextinformationen zu den Erfordernissen im Nutzungskontext gesammelt.
• Der Beobachter beobachtet den Benutzer während der Ausführung von Aufgaben im System.
• Der Beobachter greift nur bei zu klärenden Fragen ein.
• Die Beobachtung kann auch bei manuellen Abläufen verwendet werden.
• Die Beobachtung sollte wenn möglich in einem natürlichen Kontext stattfinden.

• Dient zum Sammeln von Daten. Dies geschieht bei sorgfältig ausgewählten Individuen und dient dazu ein tieferes Verständnis für die Arbeitstätigkeit der Benutzer zu erhalten.
• Mit dem Interview sollen Unterschiede und Gemeinsamkeiten in der Benutzung des Systems aufgedeckt werden.

• Findet dort statt wo der Benutzer normalerweise mit dem System interagiert also am Ort des Handlungsgeschehens.
• Englisch: Contextual inquiry

• Der Interviewer demonstriert nicht sein Wissen. Der Benutzer ist der Meister und der Interviewer der Schüler. Somit stellt der Interviewer seine Fragen um etwas zu lernen.

• Diese Fragestellung beinhaltet bereits eine gewisse Präferenz und versucht somit die Antwort in eine gewisse Richtung zu lenken.

• Diese Fragestellung beinhaltet keine Präferenz und schliesst auch keinen Aspekt aus. Die Frage kann so nicht in eine Richtung gelenkt werden.

• Diese Fragestellung zieht keine Einschränkung der Antwortmöglichkeiten nach sich. Sie animiert den Benutzer zur freien Rede und lässt somit ausführliche Antworten zu.

• Diese Fragestellung lässt nur eine Antwort aus einer vordefinierten Auswahlmöglichkeit zu. Oft einfach nur „ja“ oder „nein“.
• Sollte nicht zu oft nacheinander verwendet werden da sie sonst den Redefluss unterbrechen.

• Diese Gruppe besteht aus einer Auswahl von Benutzern. Die Diskussion wird von einem Moderator geführt welcher Fragen zu einem bestimmten Thema stellt.
• Fokusgruppen befassen sich mit Meinungen, Usability-Tests mit der Beobachtung des tatsächlichen Benutzerverhaltens.
• Die Fokusgruppe ist kein Ersatz für eine Usability-Evaluierung.

• Eine Gruppe von Benutzern welche dieselben oder ähnliche Personenmerkale haben. Weiter befinden sie sich im gleichen oder ähnlichen Nutzungskontext.

• Abstrahiertes Benutzergruppenprofil am Beispiel von einer Person. Eine Persona ist keine existierende Person. Sie ist ein erfundenes Beispiel auf Basis eines realen Benutzers und empirisch ermittelten Daten. Die Daten können durch Beobachtungen oder Interviews erhoben werden.
• Beschreibt das Bedürfnis konkret auf das Thema.
• Personas beschreiben typischerweise: Namen, Alter, einige Hintergrundinformationen, Ziele und Wünsche.
• Weiter muss das wesentliche Wissen und das Interesse im Kontext des Systems beschrieben werden.
• Kann ein Bild enthalten.

• Beschreibt die Teilaufgaben welche erledigt werden müssen um die Ziele zu erreichen.
• Beschreibt die Logik einer Aufgabe.
• Szenarien und Personas dienen als Grundlage für das Aufgabenmodell.

• Narrative Textbeschreibung des Vorgehens welches ein Benutzer anwendet um eine oder mehrere Aufgaben zu erledigen.
• Beschreibt die Erledigung einer oder mehrerer Aufgaben durch eine Persona.
• Szenarien werden von Benutzern auf ihre Richtigkeit überprüft um Missverständnisse zu entdecken.
• Ein Szenario darf nicht zu spezifisch (die Lösung beschreibend) sein.
• Szenarien werden benutzt, um Aufgabenmodelle und frühe Prototypen zu erstellen.

• Beschreibt wie die Aufgaben bisher gemacht werden.
• Beschreibt somit den aktuellen Nutzungskontext. Dient dazu um Erfordernisse und Nutzungsanforderungen abzuleiten.

• Beschreibt wie Aufgaben mit dem zukünftigen System erledigt werden. Dient als Basis für die Entwicklung von Low-Fidelity-Prototypen.

• Person welche mit dem System arbeitet oder Daten nutzt welche vom System erzeugt werden.

• interagiert mit dem System direkt

Interagieren mit dem System um ein Ziel zu erreichen.

• Interagieren mit dem System um Unterstützung (Support) zu geben oder warten dieses.

• Kommt mit dem System nicht direkt in Kontakt.

• Kann Benutzer sein oder auch nicht. Arbeiten sie nicht direkt mit dem System werden sie nicht als Benutzer betrachtet.

• Werden vom User Requirements Engineer auf Basis von Beobachtungen und Interviews erstellt.
• Szenarien und Personas werden zusammen entwickelt. Grund ist, dass das Analysieren von Benutzern einerseits ihr Handeln andererseits auch Verhalten aufzeigt.

• Voraussetzung um ein Ziel zu erreichen.
• Ein Erfordernis ist unabhängig von jeglicher Lösung für dieses Erfordernis.
• Erfordernisse zeigen oftmals Lücken auf zwischen dem was ist und dem was sein soll.
• Besteht aus folgenden Elementen:
  • Benutzer
  • Voraussetzung
  • Nutzungskontext
  • Ziel

• Um Erfordernisse zu identifizieren, gibt es verschiedene Möglichkeiten:
  • Interviews
  • Beobachtungen
  • Benutzerbefragungen
  • Usability-Evaluierungen
  • Expertenanalysen
  • ...

• Eine Bedingung oder Fähigkeit die das System erfüllen muss.
• Eine Anforderung sollte eine festgelegte Bedingung haben, mit der sie validiert werden kann.
• Besteht aus:
  • Interessenvertreteranfoderungen
  • Marktanforderungen
  • Organisatorische Anforderungen
  • Nutzungsanforderungen

• Ein Individuum oder eine Organisation. Hat ein Anrecht, einen Anteil, einen Anspruch oder ein Interesse am System oder dessen Merkmalen.
• Alle Benutzer sind Interessenvertreter.
• Englisch: Stakeholder