4. User Centered Design

Transkript

1 Grundlagen der Mensch Maschine Interaktion. 4. User Centered Design Prof. Kirstin Kohler // Hochschule Mannheim // WS 2014_15

2 Unser Fahrplan 1. Einführung 2. Grundlagen der Psychologie 3. Normen und Richtlinien 4. User Centered Design MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 2

3 Entwicklung ohne UCD Anforderungen Au;raggeber Design/Impl Entwickler Testen Usability wird nach Erfahrungen der Beteiligten als gut befunden Betrieb MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 3

4 Im Mittelpunkt MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 4

5 Entwickler = Nutzer? * Warum gehen Entwickler häufig davon aus, das sie Interface Experten sind? * Entwickler sind auch Anwender. Deshalb denken sie zu wissen, was einfach zu bedienen ist und was nicht. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 5

6 Entwicklung mit UCD - Aktivitäten 1. UCD Prozess planen 2. Nutzungskontext verstehen und beschreiben Gestaltungslösung erfüllt Nutzeranforderungen IteraIon soweit Evaluierungsergebnis Bedarf zeigt 5. Gestaltungslösung aus Nutzersicht evaluieren 3. Nutzungs- anforderungen spezifizieren Angelehnt an Bild 1: DIN EN ISO : Wechselwirkungen zwischen menschzentrierten GestaltungsakIvitäten 4. Gestaltungslösung entwickeln MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 6

7 Was ist User Centered Design? * UCD ist ein Vorgehensmodell/Prozessmodell * Prinzipien für das Vorgehen: _ Die Gestaltung basiert auf einem umfassenden Verständnis der Benutzer, Arbeitsaufgaben und Arbeitsumgebungen _ Benutzer sind während der Gestaltung und Entwicklung einbezogen _ Das Verfeinern und Anpassen von Gestaltungslösungen wird fortlaufend auf der Basis benutzerzentrierter Evaluierung vorangetrieben _ Der Prozess sieht Iterationen vor _ Bei der Gestaltung wird die gesamte User Experience berücksichtigt _ Das Gestaltungsteam vereint fachübergreifende Kenntnisse und Gesichtspunkte MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 7

8 Was ist User Centered Design? _ umfasst viele Phasen der Entwicklung also nicht nur das Design der Benutzerschnittstelle. _ die Schnittstellen zur klassischen Softwareentwicklung sind schlecht definiert. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 8

9 * Es gibt viele Prozesse des UCD _ Eigene Namen Was ist User Centerd Design? _ Unterschiedliche Schwerpunkte < Von Aktivitäten < Von Plattformen _ Branding von Beratungs-/Entwicklungsfirmen _ Die Kernaktivitäten/-ideen finden sich in all diesen Varianten wieder. * Beispiele _ K. Holtzblatt: Contextual Design (Schwerpunkt auf Kontextanalyse) _ IDEO: Design Thinking (Schwerpunkt auf Innovation) _ J.J. Gerrett: User Centered Design for the Web (Schwerpunkt Web) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 9

10 Artefakt zentrierte Sichtweise Bsp. Web InteracFons- Design: Fluss durch die Anwendung, um die Aufgaben des Anwenders zu unterstützen. Definiert wie der Nutzer mit der Seite interagiert. NavigaFons- Design: Gestaltung der Interface Elemente, um die Bewegung des Anwenders durch die InformaIonsarchitektur zu unterstützen. InformaFon Design: Darstellung der InformaIon, so dass der Anwender den InformaIonsinhalt einfach versteht. InformaFons- Architekture: Struktur des InformaIonsraumes, um den Zugriff auf Inhalte intuiive zu unterstützen User Needs: Externe Ziele des Anwenders, idenifiziert durch User Research Site ObjecFves: GeschäXsziele, die projekintern idenifiziert/definiert werden. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 10

11 UCD: Kontext Verstehen 1. UCD Prozess planen Interviews, Fokus Gruppen, Beobachtung 2. Nutzungskontext verstehen und beschreiben Gestaltungslösung erfüllt Nutzeranforderungen IteraIon soweit Evaluierungsergebnis Bedarf zeigt 5. Gestaltungslösung aus Nutzersicht evaluieren 3. Nutzungs- anforderungen spezifizieren Angelehnt an Bild 1: DIN EN ISO : Wechselwirkungen zwischen menschzentrierten GestaltungsakIvitäten 4. Gestaltungslösung entwickeln MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 11

12 Personas * Anhand von Personas, fiktiver Personenbeschreibungen, wird sichergestellt, dass der Bezug zu den späteren Anwendern erhalten bleibt. * Eine Persona ist ein fiktiver Charakter der eine bestimmte Anwender repräsentiert * Personas gewähren Einblick in Erwartungen, Ziele und Verhalten der Nutzer * Personas fassen die gewonnenen Erkenntnisse über die Zielgruppe zusammen und sind für jedermann verständlich * Auswahl passender Probanden nach Persona-Profil. * Wichtig! Nicht zu viele Personas entwerfen * Wichtig! Priorisieren: Primär, sekundär, ausschluss MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 12

13 Warum sind Personas so wichtig ansonsten würde man versuchen, alle Anforderungen die es geben könnte, gleichermaßen zu erfüllen! MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 13

14 Aufgabenanalyse * Aufgabenanalyse (contextual task analysis) _ Die Aufgaben nicht die Features stehen zu Beginn im Vordergrund _ Features müssen Aufgaben zugeordnet werden können. * Eine gängige Praxis ist dabei, eine Gesamtaufgabe in Teilaufgaben zu zergliedern. * Der Stellenwert der Aufgabenanalyse (der damit verbundene Aufwand) variiert stark mit dem Typ der Anwendung _ Homepage _ System zur Konfiguration eines CT _ Handy App zur Einkaufsunterstützung MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 14

15 Aufgabenanalyse * Basierend auf der Analyse, werden dann Aufgabenvariationen vorgeschlagen, die dem Nutzer ermöglichen seine Aufgabe effizienter ( und/oder mit mehr Spaß) zu erledigen. (to-be-task) * Die Aufgabenanalyse wird aus der Perspektive des Nutzers durchgeführt (nicht aus der Perspektive eines Managers oder Entwicklers). Die Wissen darüber kommt vom Nutzer selbst. * Es gibt _ viele Methoden um die Aufgabenanalyse durchzuführen (Beobachtungen, Log-file Analyse, Interviews, Fokusgruppen, Contextual Inquiry,... ) _ Viele Notationen um Aufgabenbeschreibungen festzuhalten (Tabellen ähnlich Use-Case Beschreibungen, Workflowmodellierung/Aktivitätsdiagramme,.. ) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 15

16 Aufgabenbeschreibung * Ist das Ergebnis der Aufgabenanalyse. * Wird an vielen Stellen im UCD verwendet _ Um Probleme im Ablauf zu entdecken und Potential für Verbesserungen aufzuspüren. _ Um Features zuzuordnen (keine unnötigen Features zu implementieren). _ Um Evaluationen durchzuführen. _ Um Alleinstellungsmerkmale zu identifizieren. _ später in der Entwicklung: Als Basis für Use-Cases, so wie Sie sie kennen. * Und warum das alles? - z.b. um Aufgabenangemessenheit zu erreichen (vgl. Dialogprinzip) - um Produkte zu bauen, die den Anwender bei der Erreichung seiner Ziele unterstützt (vgl. Usability Definition nach ISO) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 16

17 Aufgabenbeschreibung * Zeig die einzelnen Schritte, die durchgeführt werden um eine Aufgabe zu erfüllen, die zur Tätigkeit des Nutzers gehört. Es verdeutlicht verschiedene Strategien, die Menschen nutzen, ihre Absichten und Ziele, sowie die Probleme, denen sie bei den Tätigkeiten begegnen. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 17

18 Ein Beispiel Aufgaben-Analyse für ein Hotel-System: * Das System soll die folgenden Aufgaben an der Rezeption unterstützen: _ Raumbuchung eines Gastes _ Check-in eines Gastes _ Check-out eines Gastes MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 18

19 Aufgabenbeschreibung dokumeniert (nach Lauesen) : T1.2: Check in Start: A guest arrives. End: The guest has got room(s) and key. AccounIng started. Frequency: Total: Around 0.5 check ins per room per night. Per user: Difficult: A bus with 50 guests arrive Subtasks: 1. Find room. Problem: Guest wants neighbor rooms; price bargain. 1a. Guest has booked in advance. 1b. No suitable room. 2. Record guest data. 2a. Guest recorded at booking. 2b. Regular guest. 3. Record that guest is checked in. 4. Deliver key. Problem: Guest forgets to return the key; guest wants two keys.

20 Aufgabenbeschreibung Sequence Model (Contextual Inquiry) hip:// design.org/ encyclopedia/contextual_design.html

21 Kochen & Einkaufen Ziel Absicht Zubereitung eines MiLagessens/ Abendessens für die Familie RechtzeiIg essen, es soll allen schmecken, es sollte nicht zu teuer sein Rezept suche: Die Wahl des Rezeptes hängt davon ab: - Was ist vorräig? - Was stand in den vergangenen Tagen auf dem Essensplan? - Wie viel Zeit ist zum Kochen? Einkaufszeiel schreiben: - Feststellen, was vorräig ist - Mengen und Zutaten noieren Einkaufen: - Waren suchen - Angebote vergleichen - Waren bezahlen - Waren einladen Speise zubereiten: - Lebensmiiel abwiegen, waschen, schneiden, kochen - Im Rezept nachlesen

22 Artefakte

23 Zusammenfassung der Information Welche Fragen müssen Sie mit der Kontextanalyse beantworten können? * Was tuen die Anwender, wie und warum? * Welche Aktivitäten werden durchgeführt? * Durch was können diese unterbrochen werden? * Welche Werkzeuge werden verwendet und wofür? * Wie werden diese heute ausgeführt? * Welche typischen Artefakte werden in der Aktivität verwendet? Wie sehen Sie aus? * Welche Wörter verwendet der Anwender während dieser Aktivität? * Wie häufig und lang führt der Anwender die Aktivität aus? * Zu welchen Fehlern kann es dabei kommen? * Wie könnte die Aktivität signifikant erleichtert und verbessert werden? MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 23

24 Zusammenfassung der Information * Welche Rolle spielt der Nutzer in der Organisation? * Für welche Dinge ist er/sie verantwortlich? * In welchen Kommunikationsprozessen ist er/sie involviert? * Wie ist der Arbeitsplatz organisiert? * Welche Artefakte werden verwendet? _ Wo kommen sie her? _ Wo gehen sie hin? MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 24

25 Aufgabe * Beschreiben Sie im Stil einer Kontextanalyse/Aufgabenbeschreibung, den Ablauf eines typischen Mensa-Essens/Cafeteria-Essens. * Hintergrund: Sie wollen eine App schreiben, mit der Essen in der Mensa vorbestellt und vorabbezahlt werden kann. Dies soll die Planbarkeit der Mensa erhöhen und die Wartezeit verringern. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 25

26 Ist das eine gute Aufgabenbeschreibung?

27 Wo bekommen wir diese Informationen her? * Interviews/Fragebögen * Site-Visits/Beobachtung * Fokus Gruppen * Self Documentation MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 27

28 UCD: Anforderungen spezifizieren 1. UCD Prozess planen 2. Nutzungskontext verstehen und beschreiben Gestaltungslösung erfüllt Nutzeranforderungen IteraIon soweit Evaluierungsergebnis Bedarf zeigt 5. Gestaltungslösung aus Nutzersicht evaluieren 3. Nutzungs- anforderungen spezifizieren Angelehnt an Bild 1: DIN EN ISO : Wechselwirkungen zwischen menschzentrierten GestaltungsakIvitäten 4. Gestaltungslösung entwickeln MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 28

29 Ziel der Spezifikation Funktionale und Nichtfunktionale Spezifikation * Den Arbeitsablauf verbessern _ In der Phase Kontext verstehen wurden Hinweise gesammelt, < wo beim Arbeitsablauf Probleme auftreten < welche Schritte sich häufig wiederholen < welche Schritte fehleranfällig sind < welche Absicht hinter den Tätigkeiten steht (- > evtl. gibt es bessere Möglichkeiten diese Absichten zu erreichen) _ Diese werden durch einen neue Art der Aufgabenbearbeitung behoben (to-betask) * Features (funktionale Anforderungen) identifizieren, die zu dieser Verbesserung beitragen _ Aufgabenangemessenheit _ Effektivität (in der Usability Definition) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 29

30 Sören Lauesens: Task & support approach T1.2: Check in Start: A guest arrives. End: The guest has got room(s) and key. AccounIng started. Frequency: Total: Around 0.5 check ins per room per night. Per user: Difficult: A bus with 50 guests arrives Subtasks: 1. Find room. Problem: Guest wants neighbor rooms; price bargain. 1a. Guest has booked in advance. 1b. No suitable room. 2. Record guest data. 2a. Guest recorded at booking. 2b. Regular guest. 3. Record that guest is checked in. 4. Deliver key. Problem: Guest forgets to return the key; guest wants two keys. Example soluion/features: System shows free rooms on floor maps. System shows bargain prices, Ime and capacity dependent. System prints electronic keys. New key for each customer. Quelle: Sören Lauesen

31 Aufgabe * Beschreiben Sie Features für die Mensa-App, die sich aus ihrer Kontextanalyse ergeben MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 31

32 User Experience Vision * Eine Zukunftsvision, die die Erfahrung des Nutzers mit dem Produkt beschreibt. * Sie fasst die kritischen Elemente der User Experience zusammen. * Sie bringt die Kernidee auf den Punkt. * Der Schwerpunkt liegt auf dem Erleben des Nutzers mit dem Produkt und nicht auf der Technologie. * Ohne diese Vision _ Fehlt dem Team die Herausforderung _ Fehlt dem Team die gemeinsame Richtung _ Verliert das Team leicht den Fokus MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 32

33 Methode: Design a Product Box hip:// * Ihre Aufgabe ist es, mit Ihrem Team die Verpackung für Ihr Produkt zu entwickeln (auch wenn Ihr Produkt virtuell ist, wie ein Softwaresystem). * Beachten Sie dabei folgende Hinweise: _ Einigen Sie sich auf die wichtigste Botschaft was nimmt der Kunde mit, wenn der das Produkt kauf? Erfinden Sie einen Namen für das Produkt, der die Idee gut transportiert. Ergänzen Sie auf der Produktbox ein Foto oder eine Skizze, die Ihr Produkt symbolisiert. Führen Sie eine Handvoll Features Ihres Produktes auf. Führen sie die Anforderungen an die Umgebung auf, die Ihr System benötigt. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 33

34 Aufgabe * Beschreiben Sie eine Produkt-Box für besagte Mensa-App MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 34

35 Volere Template PROJECT DRIVERS: 1. The Purpose of the Product (hier Geschäftsziele -> Usability) 2. Client, Customer, Stakeholders 3. Users of the Product (hier: Personas) PROJECT CONSTRAINTS: 4. Mandated Constraints (hier: Hardwareeinschränkungen) 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS: 7. The Scope of the Work (hier: Artefakte der Kontextanalyse, Aufgabenanalyse) 8. The Scope of the Product 9. Functional and Data Requirements MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 35

36 NON-FUNCTIONAL REQUIREMENTS: 10. Look and Feel Volere Template 11. Usability and Humanity (hier: Usability Ziele) 12. Performance 13. Operational 14. Maintainability and Support 15. Security 16. Cultural and Political 17. Legal MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 36

37 Merke * Nicht der Anwender gestaltet das Produkt, sondern Sie. * Wünsche des Anwenders nicht ignorieren, aber auch nicht einfach umsetzen. * Stattdessen: Verstehen, welche Aufgaben oder Probleme hinter den Wünschen stehen, dann selbst entscheiden, durch welche Gestaltungslösungen diese Probleme behoben werden könnten. Sie kennen die Technologie, folglich haben Sie den Überblick über mögliche Gestaltungslösungen. * Wenn Anwender Produkte ablehnen, versuchen sie die Gründe zu verstehen. * Hier geht es darum: Das Richtige zu implementieren! (versus richtig implementieren) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 37

38 UCD: Gestalten 1. UCD Prozess planen 2. Nutzungskontext verstehen und beschreiben Gestaltungslösung erfüllt Nutzeranforderungen IteraIon soweit Evaluierungsergebnis Bedarf zeigt 5. Gestaltungslösung aus Nutzersicht evaluieren 3. Nutzungs- anforderungen spezifizieren Angelehnt an Bild 1: DIN EN ISO : Wechselwirkungen zwischen menschzentrierten GestaltungsakIvitäten 4. Gestaltungslösung entwickeln MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 38

39 Wer gestalten die Nutzung? MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 39

40 Merke: Jeder, der an der Entwicklung beteiligt ist, gestaltet (= designed) die Wirkung des Produktes. Überlassen Sie den Gestaltungsteil nicht dem Zufall. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 40

41 * Gestalten: Für User Interfaces eine undankbare Sache?!? Scott Jensen (Aus - Default Thinking: Why consumer products fail): A basic tenet of design is that it is very easy to criticize and much harder to create. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 41

42 Ist Design Kunst? Design Nutzen Einschränkungen RepräsenIert Kunst Künstlich/Unecht Freiheit Ausdruck MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 42

43 Ist Design Wissenschaft? Design Flexibler Prozess Analyse von Menschen IntuiIon/Baugefühl Die Rahmenbedingungen sind variable Ob die Lösung richig ist, weiß man erst, wenn sie ferig ist. Es gibt nicht die eine richige Lösung. WissenschaX/InformaIk Starrer Prozess Analyse von Daten, Entwickeln von Algorithmen Validität/Reliabilität/Beweisbar Annahme alle Rahmenbedingungen sind bekannt. Es gibt nur eine oder aufzählbar viele richige Lösungen. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 43

44 * Zur Exploration _ um Ideen zu finden _ um zu experimentieren * Zur Evaluation _ to fail faster Warum Prototyping? < Im Bezug auf UX des Endproduktes und < im Bezug auf die Entwickelbarkeit? _ to find the right design * Zur Erklärung / zur Dokumentation _ als Vertragsgrundlage _ für andere Stakeholder im Entwicklungsprozess (Entwickler) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 44

45 Zur Dokumentation * Kommentare ergänzen / über die Ferne diskutieren * Dokumentation generieren * Prototyping Artefakte an andere Rollen verlustfrei übergeben _ Wenig Toolbrüche -> wenig Dokumentation notwendig -> Reuse möglich -> weniger Missverständnisse zwischen Disziplinen _ Bsp: < X-Code < Expression Blend / Sketchflow -> WPF < Adobe Catalyst & Photoshop / Flex MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 45

46 PROTOTYPING ENTWICKLUNG Papier/ Knete Photoshop Wireframes Entwicklungswerkzeug IDE Idee Bedürfnisse des Anwenders Alles ist möglich InnovaIon Building the right thing Verhandlung Technologisch machbar Produkt Alles ist festgelegt Building it right

47 Arten von Prototypen * Nähe zum letzendlichen Produkt: _ Low-Fidelity Prototypen: einfach und schnell (Wegwerfprototypen) _ High-Fidelity Prototypen: meist aufwendig und komplex (evolutionäre Prototypen) * Umfang der Funktionalität: _ Horizontale Prototypen: Breite der Funktionen angerissen. Gibt einen Eindruck von der Gesamtheit. _ Vertikale Prototypen: Ausgewählter Funktionen bis zum Ziel definiert (z.b. Prozesse). Gibt einen Eindruck von Komplexität. _ Diagonale Prototypen: Eine Mischung MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 47

48 Vorteile des sog. Rapid-Prototypings MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 48

49 Arten von Prototypen * Interaktivität: _ Video-Prototypen/Customer Journeys/Storyboards etc.: geben einen Eindruck wie das Produkt später eingesetzt werden soll und eignen sich insbesondere für sehr innovative Konzepte, um z.b. Entscheider zu überzeugen. Man kann Konzeptideen präsentieren und initiale Meinungen einholen, was ohne visuelle Unterstützung sehr schwer wäre! _ Interaktive, benutzbare Prototypen: spiegeln das finale Produkt wieder und können benutzt werden. Der Anwender steuert das Produkt was konzeptionelle Fehler aufdeckt. Man kann repräsentativ Testen und Funktionsweisen überprüfen! MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 49

50 Prototypen in der Automobilindustrie MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 50

51 Prototypen in der Automobilindustrie MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 51

52 Skribbles: Frühzeitige Prototypen MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 52

53 Video Prototypen hip:// MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 53

54 Auch das ist ein Prototyp MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 54

55 Skribbles vs. Funktionaler Prototyp vorschlagen fragen verursachen erkunden herausfordern vorläufig unverbindlich Ideenfindung Usability Ziele beschreiben Antworten auflösen verfeinern beschließen spezifisch darstellend MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 55

56 Vom Skribble zum Storyboard MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 56

57 Keine Kunst sondern Gedankenvisualisierung Jack Dorsey s original sketch for Twiier ( Status ) Dan Cai s concept sketch for Flickr Places MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 57

58 Papierprototypen Ermöglichen frühzeiiges Erleben unterschiedlicher Designs (unabhängig von der Technik) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 58

59 Papierprototypen Schnell Änderungen möglich bzw. Anforderungen können schnell visuell umgesetzt werden. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 59

60 Papierprototypen Prozesse lassen sich schnell durchspielen (Login) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 60

61 Papierprototypen Ermöglichen auch frühzeiig das Testen ohne jemals am PC gesessen zu haben. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 61

62 Papierprototypen KreaIve Ideenfindung KollaboraIves Lösen von Problemstellungen Workshops- tauglich fördert Diskussion auf funkionaler (nicht visueller Ebene) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 62

63 MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 63

64

65

66 Wireframes Konkrete Struktur/Auxau der Seite ohne FunkIonalität und Design (meist auch ohne Farbe) MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 66

67 Wireframes Klärung der Fragestellung: Welche Elemente werden gebraucht und werden wo platziert? MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 67

68 Wireframes und logischer Ablauf MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 68

69 Vom Wireframe zum klickbaren Prototypen MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 69

70 Entwicklung mit UCD - Aktivitäten 1. UCD Prozess planen 2. Nutzungskontext verstehen und beschreiben Gestaltungslösung erfüllt Nutzeranforderungen IteraIon soweit Evaluierungsergebnis Bedarf zeigt 5. Gestaltungslösung aus Nutzersicht evaluieren 3. Nutzungs- anforderungen spezifizieren Angelehnt an Bild 1: DIN EN ISO : Wechselwirkungen zwischen menschzentrierten GestaltungsakIvitäten 4. Gestaltungslösung entwickeln MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 70

71 Heuristische Evaluation _ Eine kleine Anzahl von Experten beurteilt das User Interface und hält Ausschau nach Problemen, die durch die Verletzung von Design Prinzipien existieren. _ Entwickelt von Nielsen & Molich, 1994 _ Die Grundlage bilden Heuristiken, die aus der empirischen Analyse von Usability Problemen abgeleitet wurden. _ Es besteht ein enger Zusammenhang zwischen Design Guidelines und den Heuristiken. _ Heuristische Evaluationen liefern keine Verbesserungsvorschläge nur Mangelbeschreibungen. _ Es existieren spezielle Heuristiken für bestimmt Domänen. _ ersetzt nicht den Usability Test // Ergänzung im Vorfeld MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 71

72 Heuristische Evaluation Schritt 1: Briefing _ Jeder Experte enthält eine kurze Einführung in das Produkt Schritt 2: Evaluation _ Jeder Experte inspiziert das Produkt für ca. 1-2 h alleine. _ Die Untersuchung sollen in zwei Durchgängen erfolgen: < Ein erster Durchgang soll ein Gefühl für den Informationsablauf und die Funktionalität des Produktes vermitteln. < Im nächsten Schritt konzentriert sich die Prüfung auf einzelne Bedienelemente _ Die Probleme werden hinsichtlich ihres Schweregrads bewertet. _ Ergebnis der Evaluation ist eine Liste von Usability Problemen. Jedes Problem sollte genau beschrieben werden und auf die Heuristik, die sie verletzt, Bezug nehmen. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 72

73 Schritt 3: Debriefing _ Die Experten treffen sich und diskutieren die gefundenen Probleme _ Die unterschiedlichen Einschätzungen bzgl. des Schweregrads werden zusammengetragen/gemittelt. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 73

74 Heuristiken * Sichtbarkeit des Systemstatus Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert. * Übereinstimmung zwischen dem System und der realen Welt Das System sollte die Sprache der Benutzer sprechen und systemorientierte Terminologien vermeiden. * Benutzerkontrolle und -freiheit Ein System sollte Benutzer nie in Situationen geraten lassen, aus denen sie nicht wieder zurückfinden. * Konsistenz und Standards Benutzer sollten sich nicht über unterschiedliche Wortwahl für gleiche Situationen oder Aktionen wundern müssen. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 74

75 Heuristiken * Fehlerverhütung Besser als gute Fehlermeldungen ist ein gutes Design, welches das Eintreten von Fehlern erst gar nicht zulässt. * Wiedererkennen statt sich erinnern Das Kurzzeitgedächtnis eines Benutzers ist begrenzt. Deshalb sollten sie sich nicht an Informationen erinnern müssen, die in einem ganz anderen Bereich des Dialogs von Bedeutung waren. * Flexibilität und Effizienz der Benutzung Häufig auftretende Aktionen sollten vom Benutzer angepasst werden können, um Fortgeschrittenen eine schnellere Bedienung zu erlauben. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 75

76 Heuristiken * Ästhetik und minimalistisches Design Dialoge sollten keine irrelevanten Informationen enthalten, da die Informationen um die Aufmerksamkeit des Benutzers konkurrieren. * Hilfe beim Erkennen, Diagnostizieren und Beheben von Fehlern Fehlermeldungen sollten in natürlicher Sprache ausgedrückt werden (keine Fehlercodes), präzise das Problem beschreiben und konstruktiv eine Lösung vorschlagen. * Hilfe und Dokumentation Jede Information der Hilfe oder Dokumentation sollte leicht zu finden sein, auf die Aufgabe abgestimmt sein und die konkreten Schritte zur Lösung auflisten. Außerdem sollte sie nicht zu lang sein. MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 76

77 Traditionelle Usability Tests im Labor MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 77

78 Usability-Test Software für Mac: Silverback MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 78

79 Online Nutzerverhalten aufzeichnen MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 79

80 Merke Devise: Lieber schnell und einfach testen (evaluieren) als gar nicht testen! Lieber mit Anwendern testen als nur mit Experten! MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 80

81 Viele weitere Methoden der Evaluation * Fragebogenbasierte Evaluation * Eye-Tracking * und des User Centered Design unter hip:// Oder : Mehr dazu als Vertiefung im Hauptstudium! MMG // 4. UCD // Prof. Kirstin Kohler // WS 2014_15 81