2. 2
ABOUT ME
FH Hagenberg – Digitale Medien, Interactive Media // Universität Wien – Psychologie // UXcamp Europe
Usability Engineer // Seit 2008 bei TechTalk // Usability, Product Owner, Scrum Master
8. ENDBENUTZERINTERVIEWS
• Befragung von (potentiellen) Endbenutzern
Ziele:
• Informationen über Ziele, Bedürfnisse und Probleme
der Benutzer sammeln
• Informationen über den Nutzungskontext
• Vermeiden von falschen Annahmen
10. WAS IST ZU BEACHTEN?
• Ziel des Interviews erklären
• Offene Fragen – Der Benutzer soll seine Geschichte
erzählen
• Stille zulassen
• Körpersprache beachten
• Incentives?
11. 11
BEISPIEL: ANWENDUNG FÜR DIREKTOREN
• Wann verwenden Sie die Anwendung?
• Zum Monatsabschluss, bzw. sobald was anfällt.
• 1x in der Woche gibt es etwas zu ändern.
• Was ist die kritischste Aufgabe die sie
durchführen?
• Lehfächerverteilung zu Beginn des Schuljahres
-> sehr gut: es wird gleich angezeigt wenn etwas
nicht passt.
13. NUTZUNGSKONTEXTANALYSE
• Beobachtung und Befragung der Benutzer bei der
Durchführung von Aufgaben in der realen Situation
Ziele:
• Informationen über Ziele, Bedürfnisse und Probleme der
Benutzer sammeln
• Informationen über den Nutzungskontext
• Vermeiden von falschen Annahmen
14. BEISPIEL
ANLIEGENMANAGEMENTSYSTEM
BERLIN• Anwendung für Ordnungsämter in Berlin
• ZweiTeams besuchten 4 Ordnungsämter
• Inkl. Projektmanager & Entwickler
• Briefing für alleTeilnehmer
• Aufzeichnung: Fotos, Audioaufnahmen (für
Interviews), Notizen
19. PERSONAS
• Fiktive, aber möglichst realistisch beschriebene Person als
Repräsentant der Hauptbenutzergruppen
• Basiert auf vorhandenen Daten
Ziele:
• Verständnis für BenutzerInnen im gesamten Projektteam
• Diskussiongrundlage
• Unterstützt Priorisierung von Anforderungen
20. VORGEHEN
• Benutzergruppe festlegen & Daten sammeln
• Persona erstellen
• Name
• Foto
• Hintergrundinformationen
• Ziele und Bedürfnisse
• Keep them alive:
• Kommunikation: Poster, Karten, Arbeitsplätze, Newsletter
• Verwendung in User Stories & Diskussionen
24. WIREFRAMES
• Reduzierter Entwurf der Benutzeroberfläche für die
Konzeption von Struktur und Funktionsweise der
Anwendung
• Ziele:
• Layoutvorschläge schnell entwickeln
• Diskussionsgrundlage
• Unterstützt gleichesVerständnis aller
Beteiligten im Entwicklungsprozess
34. ENDBENUTZERTESTS MIT „LAUTEN
DENKEN“
• Ziele:
• Benutzerspezifische Usability-Probleme werden entdeckt
• Man erfährt warum diese Probleme auftreten
• Geringe Anzahl anTestpersonen
• Schon früh im Entwicklungsprozess einsetzbar, z.B. mit
Paper Prototyp
In diesen Rollen und in diesen Projekten habe ich gesehen, dass …
… die Einbindung der Benutzer ein sehr wichtiger Erfolgsfaktor ist.
Denn nur wenn man die Benutzer einbindet, kann man ein Produkt schaffen, dass auch tatsächlich die Ziele und Bedürfnisse der Benutzer befriedigt.
Product Owner steuert welche Funktionalitäten wann umgesetzt werden. D.h. er muss wissen was sind wirklich die Bedürfnisse der Benutzer
Das kann man damit herausfinden, dass man versucht die Benutzer zu verstehen und die Annahmen und in weiterer Folge auch die Lösungen, die man mit dem Produkt bereithält, überprüft.
UX Methoden können helfen einen Einblick zu bekommen.
Für mich ein wichtiger Punkt ist, dass UX Methoden keine Zauberei sind -> es hat viel mit Empathie zu tun, aber auch mit viel Handwerk.
Deswegen möchte ich heute ein paar ausgesuchte UX-Methoden vorstellen.
Die Methoden sind das Endbenutzerinterview, die Nutzungskontextanalyse, Personas, Wireframes und die Endbenutzertests.
Die Methoden haben einen unterschiedliche Komplexität und mein Ziel heute ist es euch einen Einblick zu geben, was sind diese Methoden, was kann man damit erreichen und vielleicht könnt ihr ja was mitnehmen.
Häufig spricht man nur mit Stakeholdern – als Personen die einem erzählen wie die anderen arbeiten – z.B. mit Abteilungsleitern, aber nicht mit den Benutzern selbst.
Es ist wichtig, sich bewusst zu machen – „Spreche ich wirklich mit dem Benutzer?“
Benutzergruppe auswählen > Auch bei einer Anwendung die „alle“ bedienen können, werden nicht „alle“ diese verwenden.
Screener erstellen
Termine vereinbaren > Besuchen oder Einladen / per Telefon
Fragen vorbereiten
Fragenformulierung beachten
Fokussieren auf das Wichtigste
Benutzer interviewen
Aufzeichnung
Notizen
Verwendung der Ergebnisse
Antworten strukturieren
Für Projektteam zugänglich machen
Weitere Nutzung für Personas, Überarbeitung von Anforderungen
Ziel des Interviews den Benutzern erklären
Offene Fragen – Der Benutzer soll seine Geschichte erzählen
Fragen mit Ja/Nein-Antworten vermeiden
Keine „technischen“ Fragen:
Schlecht: „Welche Spalten wollen Sie angezeigt haben?“
Besser: „Was möchten Sie mit dieser Übersicht erreichen? Wie unterscheiden sich die Daten?“
Nachfragen wenn es „spannend“ wird
Stille zulassen
Wir sind meist sehr kommunikativ, hier heißt es „ruhe bewahren“.
Den Benutzer nachdenken lassen, Zeit geben zu antworten und keine Worte in den Mund legen.
Meisten führe ich Interviews im Zusammenhang mit der Nutzungskontextanalyse durch, die ich gleich näher erläutern werde.
Bei diesem Beispiel, war aber der direkte Kontakt nicht möglich, also habe ich Telefoninterviews durchgeführt, die nicht so „gut“ sind wie Interviews bei denen man die Person auch sieht, aber besser als gar nicht mit den Benutzern zu reden.
Eigentlich relativ offensichtliche Möglichkeit viele Informationen über den Benutzer und den Anwendungsfall zu lernen, wird aber selten genutzt.
Häufig organisiert man irgendwelche Workshops in denen dann darüber gesprochen wird wie man arbeitet, aber nicht tatsächlich beobachtet wird.
Zwei Team – jeweils 4-5 Personen besuchten 4 Ordnungsämter.
Briefing für alle Teilnehmer
Es geht vor allem darum den Personen mit Wertschätzung entgegenzukommen und die Informationen dankend annehmen die man bekommt.
Sowohl bei Audioaufzeichnungen, als auch bei Fotos ist immer darauf zu achten vorher zu fragen und dann keine Persönlichkeitsrechte zu verletzen.
Stadträume eines Bezirkes – wichtig für Planung des Außendienstes.
Man kann also sehr unterschiedliche Informationen erhalten, aber auf jeden Fall hat man einen sehr guten Einblick und ein viel höheres Verständnis für die Ziele und Bedürfnisse.
Wer kennt Personas bereits?
Basiert auf vorhandenen Daten: Interviews, Nutzungskontextanalyse, Log-Files, Erfahrungen von Support-Hotlines/Support Teams
Diskussiongrundlage im Projektteam, aber auch mit Kunden
Priorisierung möglich, da man in Diskussion immer auf die Personas Bezug nehmen kann. Man kann auch die Personas in primäre und sekundäre Personas einteilen.
Personas bringen Fokus und Empathie
Vorteil gegenüber Akteuren > sind konkret, haben Anforderungen die nicht allgemein beschrieben werden können (z.B. muss beim Tippen auf die Tastatur sehen) > in der Anwendung kann es verschiedenste Möglichkeiten geben, dieses Erfordernis zu berücksichtigen.
2-3 Personas / Benutzergruppe
Herausforderung > Keep them alive: Nicht in alte Muster verfallen und aus der eigenen Perspektive diskutieren, sondern Personas in Diskussionen heranziehen.
Wenn man es schafft, führt es dazu, dass man Probleme „objektiviert“ bzw. „von außen betrachtet“.
Susanne, Günther, Cengiz
Dagmar & Tobias
Diskussionsgrundlage: sehr wichtig auch in Diskussionen Wireframes zu erstellen. Ermöglichen es sehr schnell Probleme aufzudecken und zu einer gemeinsamen Lösung zu kommen.
Einfach mit der Hand schnell Ideen visualisieren.
Sehr wichtig: Es muss kein Kunstwerk sein. Es muss nur so schön sein, dass die anderen Personen es mit Erklärung verstehen können.
Man erkennt sehr schnell, wenn etwas gar nicht funktionieren kann.
Teil der Anforderungen
Unterstützt sowohl bei der Kommunikation mit den Kunden, als auch für die Entwickler. Man weiß schnell um was es geht.
Problem: Aktualisierung der Wireframes > Regel: die Akzeptanzkriterien zählen bei Widersprüchen!
Und natürlich eigenen sich Wireframes auch bereits als Grundlage für Paper Prototyping – als einem Endbenutzertest basierend auf einem Papier Prototypen. Und zum Abschluss möchte ich noch auf Endbenutzertests eingehen.
Benutzerspezifische Usability Probleme – Auch wenn man ein erfahrener Usability Engineer ist, können benutzerspezifische Probleme trotzdem nicht vermieden oder erkannt werden. D.h. man findet bei einem sogenannten Expert Review durch Usability Experten andere Probleme, als bei Tests mit Endbenutzern.
Laut Denken ermöglicht, dass man erfährt wo genau das Problem des Benutzers liegt.
Anzahl TP: bereits ab 3, 4, 5 Testpersonen erkennt man Muster, d.h. man erkennt, welches Problem tritt bei allen auf, welches bei bestimmten Benutzergruppen.
Externer Monitor
Tastatur, Maus
So ähnlich wie möglich dem „normalen“ Arbeitsplatz.
Wichtig Audio + Screencapturing, ev. auch Webcam.
Kein „Labor“ sondern in Berlin in einem Besprechungszimmer.
2 Beobachterinnen – eine führte das Gespräch, die andere machte Notizen
Vorteil: Man erkennt sehr schnell wo das Problem liegt und wieso es ein Problem ist? („Ich erkenne gar nicht was das ist?“ „Wo ist die Funktionalität zum Hinzufügen einer Seite?“ „Ach ist das verwirrend.“)
Inspiration und Einstiegspunkt um Methoden selbst anzuwenden.