UX Toolkit für Product Owner
•Download as PPTX, PDF•
4 likes•1,165 views
Kurze Vorstellung von 5 UX-Methoden für Product Owner um Benutzer und deren Bedürfnisse besser zu verstehen.
Recommended
More Related Content
Similar to UX Toolkit für Product Owner
Similar to UX Toolkit für Product Owner (20)
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“
- 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.
- 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
- 17. Anmerkung: Diese Slides enthalten nicht alle Projektbeispiele. Für die kompletten Slides bitte e-mail an co@techtalk.at
- 18. PERSONAS ANALYSE UND USER REQUIREMENTS
- 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
- 23. WIREFRAMES
- 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
- 25. BEISPIEL
- 27. BEISPIEL: AXURE / HTML
- 29. WORKSHOPS MIT BENUTZER & STAKEHOLDER
- 31. 31 WIREFRAMES: TEIL DER ANFORDERUNGEN
- 33. ENDBENUTZERTESTS MIT „LAUTEN DENKEN“ • Benutzer führt Aufgaben durch und spricht Gedanken laut aus. • Bei der Ausführung wird er beobachtet.
- 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
- 37. BEIPSPIEL SPECLOG Beispiel Speclog (TechTalk)
- 38. 38 UX TOOLKIT • Endbenutzerinterviews • Nutzungskontextanalyse • Personas • Szenarien & Storyboards • Card Sorting • Wireframes • Paper Prototyping • Endbenutzertests • Laut Denken • Heuristische Evaluierung
Editor's Notes
- 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.