TU Wien:Socially Embedded Computing VU (Ganhör)/Stoffzusammenfassung SS16-Methoden

Methoden

Contextual Inquiry

Analyse der Benutzer und des Einsatzumfelds. Untersucht die Bedürfnisse der Anwender, indem sie diese bei ihren Tätigkeiten beobachtet und dazu befragt.

• Kontexbezogenes Wissen oft schwer abrufbar, in reinem Interview schwer abbildbar.

=> Daher: Kombination von Beobachtung und Befragung (im Kontext!).

• Ausgewählte Fragen: Mehrere Runden, zuerst unscharf und breit, dann spezifischer in besser bekanntem Kontext.
• Interviewpartner soll Handlungsweisen reflektieren und kontextbezogenes implizites Wissen aufdecken.

Analyse von...

• Ziele, Bedürfnisse, Probleme, Werte, Eigenheiten der Befragten
• Aufgaben, Abläufen, Tätigkeiten
• Schwierigkeiten mit bestehenden Systemen und erprobte Lösungsansätze (workarounds) der Anwender
• Datenmodell: Formulare, Dokumente, bestehende Software

Personas

• Modellieren prototypische Benutzergruppen
• Verkörpern deren unterschiedliche Ziele und Verhaltensweisen.
• Soll für Projektziele relevanten Eigenschaften der Benutzer widerspiegeln.
• Entworfen aufgrund von Informationen über die zukünftigen Benutzer (Information aus Workshops, Contextual Inquiry, Fragebögen, Usability Walkthroughs)

Sollen Auskunft geben über:

• Ziele einer Benutzergruppe
• Funktion, Verantwortlichkeiten, Aufgaben
• Ausbildung, Wissen, Fähigkeiten
• Verhaltensmuster und Vorgehensweisen
• Werte, Ängste, Vorlieben
• Computerkenntnisse
• Kenntnisse über verwandte Produkte, Vorgängersysteme
• Verbesserungspotential der aktuellen Situation
• Erwartungen an neue Lösung

Sollte einprägsam sein, daher Personifizierung hilfreich:

• Name, Alter, Geschlecht
• Bild, Skizze, Portrait
• Zitate aus Interviews

Bsp.: "Jakob", 43 Jahre, kaufmännische Ausbildung, seit 24 Jahren im Versicherungsgeschäft, arbeitet täglich mit dem heutigen System. "Ich will ein System wo ich alles auf einen Blick sehe.", "Ich brauche kein intelligentes Programm. Ich weiß genau, was wohin gehört".

Arten von Persona

• Primäre Persona: Für deren Bedürfnisse wird Produkt optimiert und Benutzerschnittstelle erstellt (Relevante Aspekte der Hauptzielgruppe)
• Sekundäre Persona: Anwender die von der primären Persona abweichende, zusätzliche Ziele haben.
• Indirekt betroffene Persona: Keine Anwender, aber durch Benutzung indirekt Betroffene (zB. mit Gerät therapierte Patienten)
• Ergänzende Persona: Keine Anwender, aber unternehmenspolitisch relevante Personen (Manager, Interessensvertreter etc.)
• Non-Persona: Repräsentiert Menschen außerhalb der Zielgruppe um falsche Annahmen über die Anforderungen zu vermeiden.

Szenarien

• Realistisches aber leicht verständliches Beispiel, wie eine Benutzergruppe mit dem System interagiert
• Anzahl der Benutzergruppen (Personas) sollte klein gehalten werden. Eigenes Interface für jede primäre Persona.
• Konkrete Anwendungssituationen basierend auf den Anforderungen
• auch Ausnahme- und Fehlerfälle
• iterativ oder in Workshops mit BenutzerInnen erarbeitet
• von Auftraggebern, Benutzern frühzeitig überprüft, ergänzt oder korrigiert

"Szenario: Aufnehmen eines Schadensfalls. Es ist 15:00. Bei Jakob klingelt das Telefon. Auf seinem Bildschirm er-scheinen neben der Telefonnummer Name und weitere Angaben des anrufenden Kunden. Jakob nimmt den Anruf entgegen und begrüßt den ungeduldigen Kunden, der eine kaputte Fensterscheibe melden möchte. Da für diesen Kunden verschiedene Versicherungsverträge bestehen, wählt Jakob die entsprechende Police aus der Übersicht aus. Danach nimmt Jakob den Schadensfall des Kunden auf."

verwendet für:

• Erhebung und Validierung von Anforderungen (Use Cases)
• Spezifikation der Anwendung im realen Kontext
• UI Konzept, Abläufe der Benutzerschnittstelle
• Testszenarien für Usability und Software Testing
• Schulung

Storyboards

• Zeigt bildlich mithilfe der Benutzerschnittstelle wie System verwendet wird
• Visualisierung von Szenarien (Dem Zielpublikum greifbar machen!)
• Kommunikation zwischen Auftraggebern, Benutzern und Entwicklern.
• Skizzen bis realistische gestaltete Bildergeschichten

Für...

• UI Grundaufbau und Dialogabläufe im Detail
• Schwer verständliche Aspekte
• Spezielle Umgebungen / Kontext grafisch fassbar machen

Wichtig:

• Konkrete Fallbeispiele, aber keine Trivialfälle
• Ort und Zeit definiert
• Stellt kritische Zusammenhänge detailliert dar
• Akteure und ihre Bedürfnisse
• Geschichte erklärt warum Akteure so handeln
• Beschreibt Änderungen in der Arbeitsweise durch Einführung des System

User Interface Prototyping

• Konzipieren und Optimieren der BenutzerInnenschnittstelle
• Low-fi Prototype: Storyboards, Papier Mock-ups, Sketch, Video, Skizzen
• Hi-fi Prototype: digital, meist interaktiv, web-basiert, nicht triviale Investition!
• Funktionsumfang (wie viele Funktionen werden abgebildet?) vs Funktionstiefe (wie detailliert werden Funktionen beschrieben?)
• Darstellungstreue (Look and Feel)
• Interaktivität / statische Bilder
• Datengehalt (reale Daten? Platzhalter für Bezeichnungen?)
• Technische Reife (Wie viel der UI Technologie wird im Prototyp verwendet)
• Vermarktung (Visualisierung der geplanten Lieferung)
• Abschätzen des Realisierungsaufwands durch EntwicklerInnen

UI Design

• Wie bewegen sich Benutzer durch Menüs und Dialoge
• Wie wird Information strukturiert
• Optimiert für spezielle Technologien (Touchscreen)
• Anpassung an Screen Layout und Größe
• Prüfung von Eingaben und Fehlermeldungen
• Konzepte für das Speichern von Informationen und Zuständen

Papier Prototypen

• Schnell erstellt und angepasst
• keine speziellen Hilfsmittel notwendig
• Nicht standardisierte Bedienelemente sind schnell skizziert
• Verwerfen fällt leicht (erleichtert Innovation)

Use Cases

• Spezifikation der funktionalen Anforderungen
• Anwendungsfälle beschreiben Verhalten eines Systems aus Benutzersicht
• einfach verständliche Sprache
• Use Case Model: Gesamtheit der Akteure und Anwendungsfälle
• Use Case Model beschreibt nicht wie etwas passiert (dies tut die Use Case Spezifikation)
• Unterschied zu Szenarien: Anwendungsfälle dienen zur Spezifikation des Systemverhaltens, Szenarien erklären Symstemnutzung im Detail.

zB: Akteur: Kunde die Buch kauft. Anwendungsfall 1: Buch bestellen. Anwendungsfall 2: Buch bewerten

Akteure

• mit Auftraggebern und Benutzern erarbeitet
• keine realen Benutzer, aber nicht so weit verallgemeinert dass der Realitätsbezug verloren geht

Use-Case-Spezifikation

• Detailbeschreibung der Anwendungsfälle
• Alle Schritte zwischen Akteur und System. Auch alternative Abläufe und Fehlerfälle.
• Keine technischen Details
• Muss verstanden werden von Auftraggeber und Entwickler

Guidelines und Styleguides

• Gestaltungsrichtlinien für Benutzeroberflächen
• UI Guidelines: generelle Grundsätze für Verwendung und Verhalten von UI Elementen
• Styleguides: konkrete Vorgaben für visuelle Gestaltung und Layout (Look and Feel)
• Gesetzliche Verordnungen: Arbeitnehmer-/Konsumentenschutz
• Normen: Anwendung von Technologien standardisieren
• Regelsammlungen: umfangreich, Entwicklung von UIs optimieren (zB Nielsens Usability Heuristic)
• UI Patterns: häufig auftretende Designprobleme beschrieben als generische Muster
• Plattformabhängige Styleguides: Konsistente GUI Elemente in allen Apps
• je konkreter, desto kleiner wird der Gültigkeitsbereich

Gute Styleguides

• Abgestimmt auf Technologie und Zielgruppe
• Software-Ergonomie: allgemein gültige Regeln (zB max. Anzahl Menüeinträge) bzw. Berücksichtigung spezieller Zielgruppen (zB rein durch Tastatur navigierbare Dialoge)
• Feedback der UI Elemente (zB Buttons unter Cursor)
• Beschreibung der Navigationselemente, welche Elemente für welche Situationen?
• Visuelles Design: Farbschema, Kontrast, Fonts, Layout, ...
• Technische Umsetzbarkeit
• Definition der Terminologie (Beschriftungen, Fehlermeldungen, ...)
• Tastaturbedienung: Shortcuts, Tabulator-Reihenfolge etc.

(Usability) Testing

Beurteilen des neuen Systems durch BenutzerInnen.

Fragebögen

Sammeln aussagekräftige Zahlen zur...

• Analyse von Benutzer und Kontext
• Beurteilung eines Systems oder Prototypen