UX Toolkit für Product Owner

1. BENUTZERZIELE ERKENNEN UND KOMMUNIZIEREN November 2015 I Copyright © TechTalk 2015 • www.techtalk.at Usability Engineer Claudia Oster | @usabilitytalks UX TOOLKIT FÜR PRODUCT OWNER
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
3. 3
4. 4
5. 5
6. 6 UX TOOLKIT (AUSWAHL) • Endbenutzerinterviews • Nutzungskontextanalyse • Personas • Wireframes • Endbenutzertests mit „Laut Denken“
7. ENDBENUTZERINTERVIEWS RESEARCH
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
9. VORGEHEN 1. Benutzergruppe auswählen 2. Fragen vorbereiten 3. Benutzer interviewen 4. Verwendung der Ergebnisse
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.
12. NUTZUNGSKONTEXTANALYSE RESEARCH (CONTEXTUAL INQUIRY)
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
15. Anmerkung: Diese Slides enthalten nicht alle Projektbeispiele. Für die kompletten Slides bitte e-mail an co@techtalk.at
16. PERSONAS ANALYSE UND USER REQUIREMENTS
17. 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
18. 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
19. BEISPIEL: ANLIEGENMANAGEMENTSYSTEM
20. 22 PERSONAS: BÜRGER & ORDNUNGSAMTSMITARBEITER
21. WIREFRAMES
22. 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
23. BEISPIEL
24. BEISPIEL: ABLÄUFE
25. BEISPIEL: AXURE / HTML
26. BEISPIEL: BALSAMIQ
27. WORKSHOPS MIT BENUTZER & STAKEHOLDER
28. WIREFRAMES IN DISKUSSIONEN
29. 31 WIREFRAMES: TEIL DER ANFORDERUNGEN
30. ENDBENUTZERTESTS MIT „LAUTEN DENKEN“
31. ENDBENUTZERTESTS MIT „LAUTEN DENKEN“ • Benutzer führt Aufgaben durch und spricht Gedanken laut aus. • Bei der Ausführung wird er beobachtet.
32. 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
33. BEISPIEL ANLIEGENMANAGEMENTSYSTEM
34. BEISPIEL ANLIEGENMANAGEMENTSYSTEM
35. BEIPSPIEL SPECLOG Beispiel Speclog (TechTalk)
36. 38 UX TOOLKIT • Endbenutzerinterviews • Nutzungskontextanalyse • Personas • Szenarien & Storyboards • Card Sorting • Wireframes • Paper Prototyping • Endbenutzertests • Laut Denken • Heuristische Evaluierung
37. DANKE Weitere Informationen auf UX.TECHTALK.AT @usabilitytalks

Hinweis der Redaktion

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.

UX Toolkit für Product Owner

Du liest eine Vorschau.

Hier ansehen

UX Toolkit für Product Owner

Weitere Verwandte Inhalte

Ähnlich wie UX Toolkit für Product Owner (20)

Aktuellste (20)

UX Toolkit für Product Owner

Hinweis der Redaktion