Software Engineering 1 Mensch-Maschine-Schnittstellen Usability und Produktgestaltung

1. Software Engineering 1 Mensch-Maschine-Schnittstellen Usability und Produktgestaltung Prof. Dr. Bernd Ruhland

2. 3. Termin Vorlesung Usability-Methoden Teil 1

3. Usability Methoden Methoden des Usability Software Engineering: (aus „Usability Engineering kompakt“ von Richter + Flückinger Ausblick auf die folgenden Themenblöcke) • Analyse „Contextual Inquiry“(Arbeitsumfeld) • Modellierung über „Personas“ und „Szenarien“ • „Storyboards“ zur Kommunikationsanalyse + -Gestaltung • Annäherung „User Interface Prototyping“ • Entwicklungsansatz „Use Cases“ • Entwicklungsregeln „Usability Guidelines“ und „Style Guides“ • Test der Usability • Ergänzung: Auswertungen über Fragebögen

4. Usability Methoden Methoden des Usability Software Engineering: Analyse „Contextual Inquiry“(Arbeitsumfeld) Modellierung über „Personas“ und „Szenarien“ „Storyboards“ zur Kommunikationsanalyse + -Gestaltung Annäherung „User Interface Prototyping“ Entwicklungsansatz „Use Cases“ Entwicklungsregeln „Usability Guidelines“ und „Style Guides“ Test der Usability Ergänzung: Auswertungen über Fragebögen

5. Analyse „ContextualInquiry“ (Arbeitsumfeld) • Gehört zum Ansatz „UCD“ (User Centered Design) • Vorgehen: Interviews und moderierte Gesprächsgruppen • Beobachten und Befragen der Benutzer vor Ort • Kombination und Dokumentation der Erkenntnisse • Ziel: Verständnis von Tätigkeiten und Bedürfnissen der Benutzer • Beispiel: Navi-System im Auto entwickeln • Art der Reise (lang / kurz; dienstlich / Urlaub; …)  Einfluss ? • Aufgabenverteilung Fahrer / Beifahrer  Einfluss ?

6. Analyse „ContextualInquiry“ (Arbeitsumfeld) 5-Sichten-Modell der Fragestellungen: • Rollenverteilung und Kommunikation • Typische Rollenverteilungen • Verantwortlichkeiten, Aufgaben • Kommunikationsmittel, -Zweck, -Inhalte • Positives / Negatives an der Rollenverteilung • Handlungsstrategien und Vorgehen • Tätigkeiten und Vorgehensweisen (auch unterschiedliche) • Häufigkeiten der Durchführung • Stärken und Schwächen • Ausnahmesituationen und Fehler • Artefakte (Dokumente) • Physisches Umfeld • Kulturelle und soziale Einflüsse

7. Analyse „ContextualInquiry“ (Arbeitsumfeld) 5-Sichten-Modell der Fragestellungen: • Rollenverteilung und Kommunikation • Handlungsstrategien und Vorgehen • Artefakte (Dokumente) • Verwendete Dokumente, Formulare, Werkzeuge • Aufbau, Informationsgehalt, Verwendungszweck • Anpassungen an individuelle Bedürfnisse • Zweckentfremdete Verwendungen • Positives / Negatives beim Einsatz der Artefakte • Physisches Umfeld • Raumaufteilung, Arbeitsplatzgestaltung, Hilfsmittel • Wege und Distanzen (nah, mittel, fern) • Einfluss auf die Kommunikation (siehe 1.) • Verbesserungspotential • Kulturelle und soziale Einflüsse

8. Analyse „ContextualInquiry“ (Arbeitsumfeld) 5-Sichten-Modell der Fragestellungen: • Rollenverteilung und Kommunikation • Handlungsstrategien und Vorgehen • Artefakte (Dokumente) • Physisches Umfeld • Kulturelle und soziale Einflüsse • Personen, die Einfluss ausüben • Machtausübung, sozialer Druck • Verhaltensregeln • Ziele, Wertvorstellungen, Vorlieben • Widersprüchliche Einflüsse • Positives / Negatives auf kultureller Ebene

9. Analyse „ContextualInquiry“ (Arbeitsumfeld) • Auswertung / Dokumentation: • Ziele und Bedürfnisse, Probleme, Werte und Eigenheiten der befragten Personen • Aufgaben, Abläufe und Tätigkeiten als Grundlage für die Beschreibung der künftigen Abläufe • Schwierigkeiten und Lösungsansätze mit bestehenden Werkzeugen • Begriffe und Informationen zum Datenmodell • Informationsfluss-Modell (Diagramm beteiligter Personen, die Kanten sind die „Meldungen“) • Bestehende Geschäftsprozessmodellierung ergänzen (Begriffsmodell z.B. UML um nichtfunktionale Usability-Aspekte) • Innovationsspielraum ausschöpfen

10. Übung „ContextualInquiry“ • 4-er-Gruppen bilden: • Jeweils 2 sind die Benutzer • Jeweils 2 sind die Befrager • Arbeitsumfeld: Essensmarkenautomat der Mensa • Aufgaben: • Vorgehen nach „Contextual Inquiry“ Analyse (s.o.) • Ausfertigen einer Dokumentation der Befragung

11. Usability Methoden Methoden des Usability Software Engineering: Analyse „Contextual Inquiry“(Arbeitsumfeld) Modellierung über „Personas“ und „Szenarien“ „Storyboards“ zur Kommunikationsanalyse + -Gestaltung Annäherung „User Interface Prototyping“ Entwicklungsansatz „Use Cases“ Entwicklungsregeln „Usability Guidelines“ und „Style Guides“ Test der Usability Ergänzung: Auswertungen über Fragebögen

12. Modellierung über „Personas“ und „Szenarien“ Persona (Plural: Personas): Kommt aus der Altgriechischen Theaterwelt, bedeutet „rollenspezifische Maske“ und diente zugleich als Lautsprecher Stellt einen prototypischen Benutzer dar Verkörpert dessen Ziele und Verhaltensweisen Wird aus Informationen über den späteren Benutzer des IT-Systems erarbeitet (primäre und sekundäre Personas etc.) Gibt die für die Projektziele relevanten Eigenschaften des Benutzers wieder ACHTUNG! Nicht verwechseln mit Marktsegmenten ! Dort geht es um Zielgruppen, bei der Persona geht es um die Anforderungen einer Benutzergruppe  …

13. Modellierung über „Personas“ und „Szenarien“ Informationen zu den Personas: Ziele der betreffenden Benutzer Funktion, Aufgaben, Verantwortlichkeiten Fachliche Ausbildung, Wissen, Fähigkeiten Vorgehensweisen Verhaltensmuster Computerkenntnisse Kenntnisse über fachliche Systeme, Vorgänger- und Konkurrenzprodukte Verbesserungsideen Erwartungen an eine neue SW-Lösung Werte, Vorlieben, Ängste, Sehnsüchte !  ACHTUNG! Durchaus die „rein menschliche“ Komponente nicht vergessen, warum ?:

14. Modellierung über „Personas“ und „Szenarien“ Personas als Charaktere für die weitere Verwendung: Der Charakter soll einprägsam sein Soll einfach verinnerlicht werden können Soll „vor dem Auge“ des Analysten „leben können“ Hilfreiche Idee dazu: Virtuelle Person kreieren, „zum Leben erwecken“ (erfinden): Name, Alter, Geschlecht Foto oder Skizze (Portrait) Markante Charakterzüge Einprägsame Zitate aus Interviews Kurze Geschichte „ein Tag im Leben von …“ Ziele, Werte, Ängste dabei darstellen

15. Modellierung über „Personas“ und „Szenarien“ Typen/Klassierung von Personas: Primäre Persona: Für ihre Anforderungen und Bedürfnisse ist das Produkt optimal auszurichten, insbesondere die Oberfläche / Benutzerschnittstelle Sekundäre Persona: Ihre Bedürfnisse sind weitestgehend durch eine primäre Persona abgedeckt Evtl. sind Änderungen / Erweiterungen sinnvoll und notwendig Ergänzende Persona: Ihre Bedürfnisse sind vollständig abgedeckt durch eine primäre Persona Non-Persona: Explizit benannt (ggf. explizit begründen warum) Explizit nicht berücksichtigt beim Design der Lösung !

16. Modellierung über „Personas“ und „Szenarien“ Typen/Klassierung von Personas: Non-Persona: Explizit benannt (ggf. explizit begründen warum) Explizit nicht berücksichtigt beim Design der Lösung ! Kennen Sie Beispiele dafür ? • Katholische Priester bei der Partnervermittlungsorganisation ? • Welche Rollen spielen die Chefs bei Sachbearbeiter-Formulardesigns ? • Administratoren-Oberflächen bei IT-Systemen: Ist da der „normale User“ eine Non-Persona ?

17. Modellierung über „Personas“ und „Szenarien“ Beispiel anschauen: incom.org/projekt/1258 dort das PDF zu Personas und Szenarien  Sicht des Menschen (als Anwender) Ganz und gar losgelöst von der technischen Umsetzung Es geht hier eindeutig um das WAS und nicht um das WIE Welche Non-Persona(s) können Sie nennen ?

18. Modellierung über „Personas“ und „Szenarien“ Was ist ein Szenario: „Brücke“ zwischen Anforderungen und Lösungsentwurf Konstruiertes realistisches Beispiel, wie eine Persona mit dem geplanten System interagieren wird Ablauf aus Benutzersicht Ausformuliert in kurzen Sätzen Inhaltliche Korrektheit überreitet formale Korrektheit  Wird dadurch leicht verständlich Szenario wird interaktiv entwickelt mit den Benutzern (z.B. Workshop) Kann bereits zum frühen Zeitpunkt, von Benutzern, Auftraggebern, Produktmanagern, Entwicklern überprüft und korrigiert oder ergänzt werden  „Modellierung“ der Anforderungen an eine neue Lösung

19. Modellierung über „Personas“ und „Szenarien“ Eigenschaften eines Szenarios: Wird für eine bestimmte Benutzergruppe entworfen Berücksichtigt genau deren Bedürfnisse und Eigenschaften Stellt einen konkreten Anwendungsfall dar Demonstriert den Umgang mit der geplanten Lösung im realen Umfeld Beschreibt (zumindest exemplarisch) Ausnahme- und Fehlersituationen

20. Modellierung über „Personas“ und „Szenarien“ Themen-Vorschläge für die Ausarbeitung von Personas und Szenarien durch kleine Gruppen: Parkscheinautomat mit Schranke (geschlossener Parkplatz) Parkscheinautomat ohne Schranke (offene Stellplätze) Kaffeeautomat (beliebig vorstellbar, Szenarien freien Lauf lassen), Anregung: www.pomegranatephone.com Handy-Guthaben aufladen Große Lösung: Kassensystem im Supermarkt Mensamarken-Automat an der FH Je Aufgabenstellung 2-3 Teams zu je max. 3 Teilnehmer  Dann nächste Woche max. 8 Präsentationen zu je 10 Minuten mit max. 24 TN gesamt

21. Modellierung über „Personas“ und „Szenarien“ Verwendung von Szenarien: Sie können an allen Stellen des Entwicklungsvorgangs eingesetzt werden: Anforderungserhebung: Reflektion an konkreten Ablauf-Beispielen „Erste Prototypen“ Anforderungs-Spezifikation: Ergänzung des Use Case Modells (Begriffsmodells) UI-Design: Modellierung der Interaktion Benutzer / System Als Usability-Testszenarien Als Testszenarien für die Umsetzung in Software Als Schulungsszenarien und für Bedienungsanleitungen  Nutzung der „Macht des Beispiels“

22. Modellierung über „Personas“ und „Szenarien“ Beispiele wo wir diese Methodiken im realen Einsatz finden: Stellenausschreibung: www.sinnerschrader.de/jobs/kreation/senior-user-experienceinformation-architect Beratungsunternehmen: www.nextsoft.ch Kompakter Artikel des Autors von „Usability kompakt“: www.michaelrichter.ch/richter_OS_RE_08.pdf

23. 4. Termin Vorlesung Usability-Methoden Teil 2

24. Usability Methoden Methoden des Usability Software Engineering: Analyse „ContextualInquiry“(Arbeitsumfeld) Modellierung über „Personas“ und „Szenarien“ „Storyboards“ zur Kommunikationsanalyse + -Gestaltung Annäherung „User Interface Prototyping“ Entwicklungsansatz „UseCases“ Entwicklungsregeln „Usability Guidelines“ und „Style Guides“ Test der Usability Ergänzung: Auswertungen über Fragebögen

25. „Storyboards“ Komm.-Analyse + -Gestaltung Herkunft: vom Film: Regisseur vermittelt dem Filmteam den Aufbau des Films Visualisierung von Perspektive, Licht, Kostümen, Gesichtsausdrücken Zweck: Kommunikation zwischen den Beteiligten Visualisierung eines Szenarios, wo Text alleine nicht ausreicht:  realistisch gestaltete GUI-Abfolgen – oder – „Bildergeschichten“ inkl. Kontext und handelnden Personen

26. Storyboards im Film Quellen: Sukuma, Jinsak, collabor.idv.edu, edaktik.de, fal-visions.com

27. „Storyboards“ Komm.-Analyse + -Gestaltung Geschichte zum nutzbringenden Einsatz des Systems Vermittelt Vorschläge und Entscheidungen Stellt die (impliziten) Fragen: Erfüllt die Lösung die Bedürfnisse ? Wo bestehen Irrtümer ? Wo bestehen Bedenken ? Verwendet dazu ein konkretes Fallbeispiel Detaillierte Darstellung kritischer Punkte Handelnde Personen werden charakterisiert Begründung des Handelns der Personen Daraus sollen Diskussionen entstehen Storyboard wird im Projektverlauf präzisiert von der Skizze hin zu Vorschlägen und getroffenen Entscheidungen

28. Storyboard als Skizze Quellen: andrewmckinney.com, amazonaws.com, ahmadj.com, anncharng.com

29. „Storyboards“ Komm.-Analyse + -Gestaltung Bestandteile eines Storyboards sind u.a.: Bedürfnisse (berücksichtigte und ignorierte) Funktionalitäten (auch ausgeklammerte !) Änderungen an Geschäftsprozessen Änderungen an Arbeitsweisen Benennung von Ausnahmen Aufbau der Benutzerschnittstelle (schematisch, Konzept) Detailbeschreibung einzelner Details der Benutzerschnittstelle

30. Storyboards für die Diskussion Quellen: sapdesignguild.org, fronttoback.org, martintung.com, mit.edu

31. „Storyboards“ Komm.-Analyse + -Gestaltung Einsatzbereiche und Zweck von Storyboards: Diskussion einer Idee oder eines Konzepts mit den vorgesehenen Benutzern Ebenso mit anderen Stakeholdern (z.B. Management) Überprüfung des Verständnisses der Bedürfnisse Ausräumen von Missverständnissen Diskussion von Vor- und Nachteilen (von Varianten) Konsequenzen für die Arbeit erkennbar machen Neugierde wecken, Akzeptanz vorbereiten Visionen vermitteln SW-Entwicklern die Anforderungen und Abläufe erklären Fachliche Einblicke verschaffen (wichtiger als Informatikdetails)

32. Storyboard ausformuliert / weiterentwickelt Quellen: Nina Korolewski 2002, blogspot.com, theguiguru.com

33. Storyboard Projekt Panlingual Camera Phone Teil 1 der „Geschichte“: OCR per CameraCapturing, dann Übersetzung Quelle: panlingual.com

34. Storyboard Projekt Panlingual Camera Phone Teil 2 der „Geschichte“: Manuelle Eingabe, dann Übersetzung Quelle: panlingual.com

35. Storyboard Projekt Panlingual Camera Phone Teil 3 der „Geschichte“: Manuelle Korrektur-möglichkeit des OCR-Ergebnisses vor der Übersetzung Quelle: panlingual.com

36. Dritte Verleihung der Preise ! Beispiele guter Intuitivität: xxx Beispiele schlechter Intuitivität: xxx • The Winneris: … • The Loseris: …

37. Vielen Dank für die Aufmerksamkeit ! Bernd Ruhland email: ruhland@fh-worms.de Sprechstunde: mittwochs 12 bis 13 Uhr, Raum N023 Bitte per email anmelden