Medien in der Lehre

Dozent: M. Sc. Dipl.-Inform Manuel Ecker 

ÜBERBLICK

• Prozesse und Methoden
• Design
• Usability
• Sozialforschung
• Prototypisches Design
• Prüfungen

Prozesse und Methoden zur Entwicklung von Medienprodukten

Was sind Projekte?

• ist final
• man arbeitet auf ein Ziel hin bis es erreicht wieder
  —> alleine oder in einer Gruppe, die sich nach der Zielerreichung wieder auflöst
• es muss meist ein Zeitrahmen eingehalten werden

Was ist Agiles Projektmanagement?

• findet man meistens in kreativen Arbeitsbereichen wieder
• „Wir suchen nach besseren Wegen, Produkte zu entwickeln, indem wir es selbst praktizieren und anderen dabei helfen, dies zu tun.“
• Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen. 
• Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation. 
• Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen. 
• Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung. 
• ist in gewisser Weise eine Kritik am klassischen Projektmanagement 

Was ist Scrum?

• agiles Managementframework —> verkörpert Werke des agilen Manifests
• empirischer Prozess —> inspect and adapt
• die Anwendung ist ein kontinuierlicher Lernprozess
• Alternative = Kanban —> wird aber meist im industriellen Kontext genutzt
• „schlankes Management“ („Lean“) —> vermeidet Überlastungen systematisch durch das „Ziehsytsem“ („pull“) —> jeder Mitarbeiter "zieht" sich eine Aufgabe heraus, die er gerade bearbeiten möchte / kann
• hilft dabei Probleme und Fehler frühzeitig zu erkennen und auszubessern —> hilft bei der Zielerreichung und spart Geld und erweitert Handlungsspielraum

Warum Scrum?

• sorgt für größere Mitarbeiterzufriedenheit
• größere Kundenzufriedenheit
• bessere Qualität
• besserer Produktivität
• besserer Umgang mit Geld --> z. Bsp durch schnelle Fehlererkennung

Rollen in Scrum

• Product Owner
  - repräsentiert die Endkundenbedürfnisse
  - steuert die Produktentwicklung
  - arbeitet mit dem Team über den gesamt Projektverlauf eng zusammen (sowohl örtlich
    als auch menschlich)
  - nimmt in Scrum eine zentrale Stellung ein
  - ist weit mehr als Programm-, Produkt- oder Projektmanager
  - beeinflusst den Erfolg eines Scrum-Projekts entscheidend und ist für diesen
     verantwortlich
  - Anforderungsbeschreibung und -management
  - Releasemanagement und Return on Investment
  - Stakeholder-Management
  - Chief Engineer
  - er hat nicht die Entscheidungsrolle inne
• Team
  - Individuen und Interaktionen
  - Bevollmächtigt
  - Autonom
  - Interdisziplinär besetzt
  - selbstorganisiert
  - klein
  -Vollzeitteammitglieder
  - Arbeitsplätze in unmittelbarer Nähe
  - Teamprozesse: Einer für alle, alle für einen
  - Teamnormen und Standards
  - visueller Arbeitsplatz
• Scrum Master
  - agiert als Coach und Change Agent
  - etabliert Scrum
  - unterstützt das Team
  - stellt die direkte Zusammenarbeit des Teams und des Product Owners sicher
  - beseitigt Hindernisse
  - hilft die Entwicklungspraktiken zu verbessern
  - führen durch dienen
  - hilfreiche Eigenschaften:
    > Moderation
    > Coaching
    > Erfahrung in der Softwareentwicklung

Die Rolle des Projektleiters

Der Product Owner steuert das Scrum Projekt, das Team entwickelt Auslieferer Produktinkremente, und der Scrum Master stellt sicher, dass Hindernisse rasch beseitigt werden und der Prozess rund läuft —> Gibt es aber einen Projektleiter? —> diese Rolle ist meist überflüssig

Anforderungen im klassischen Requirement Engineering

• zu Projektbeginn gibt es eine Definitionsphase in welcher Anforderungen möglichst vollständig erfasst und detailliert beschrieben werden —> dadurch soll der Projektplan realistisch ausfallen 
• hierbei treten häufig Probleme auf 

Probleme 

• Aufbau eines umfangreichen Bestands an Anforderungen
• Informationsverlust durch Übergaben
• Überproduktion von Funktionalitäten
• Unausgeglichener Arbeitsanfall und Überlastungen

Die Anforderungen in Scrum 

• werden nicht zu Projektbeginn vollständig und detailliert erfasst und anschließend in die Entwicklung übergeben —> Verschwendung und Überlastung werden so vermieden
• es existiert keine separate Definitions- und Umsetzungsphase
• Anforderungsbeschreibung und Umsetzung erfolgen zeitnah und überlappend
• Product Owner repräsentiert die Bedürfnisse der Kunden, Endandwender und anderer Interessenvertreter
• Product Owner entscheidet, welche Anforderungen in welcher Version in welcher Reihenfolge umgesetzt werden
• Product Owner erfasst, beschreibt und kommuniziert die Anforderungen an das Team
• Anforderungen werden in Kollaboration mit dem Team kontinuierlich verfeiernt, Arbeitsergebnisse am Ende eines jeden Sprints begutachtet
• Pull-Prinzip —> Product Backlog

Bei der Funktion Scrum wird in vier Teilkomponenten unterschieden

Product Backlog

• ist das zentrale Mittel zum Erfassen und Managen von Anforderungen in Scrum
• enthält alle bekannten Anforderungen und Arbeitsergebnisse, die zur Erreichung des Projektziels umgesetzt oder erbracht werden müssen
• funktionale und nicht funktionale Anforderungen, sowie Anforderungen an die Benutzerschnittstelle
• ist ein lebendes Dokument
• die Einträge sind priorisiert
• die Einträge weisen einen unterschiedlichen Detaillierungsgrad auf
• die Einträge sind abgeschätzt
• das Programm ist nicht festgelegt, kann auch Word sein

Das Produktkonzept

—> Das Produktkonzept beschreibt das zu befriedigende Kundenbedürfnis zusammen mit Wesentlichen Leistungsmerkmalen und Zielgrößen des Produkts

 Auffüllen des Product Backlogs

• Umfang und Vollständigkeit
• Unterschiedliche Detaillierungsstufen
• Arbeiten mit Themen
• Priorisieren

Sprint

—> In der Sprint-Planungssitzung erstellt das Team ein realistisches Sprint Backlog, das festlegt, welche Anforderungen bis zum Ende des Sprints in ein Produktinkrement umgewandelt werden können 

• 14 Tage (maximal 30 Tage) haben sich als geeigneter Zeitraum für eine Sprint herausgestellt
• zunächst wieder der Sprint geplant, dann der Daily Scrum umgesetzt
• Es gibt immer eine Anfangs- und eine Abschlussveranstaltung
• der PO stellt dem Team seine Anforderungen vor
• Aufgabenverteilung
• Planungsschritte im Überblick
• Etablierung eines gemeinsamen Verständnissen des Sprint-Ziels
• Erzielen eines gemeinsamen Verständnisses der ausgewählten Anforderungen
• Identifizieren und Abschätzen der benötigten Aktivitäten
• Überprüfen von Kapazität und Leistungsvermögen

Sprint Backlog

—> beinhaltet alle Aktivitäten, die zur Umsetzung der Anforderungen notwendig sind, zu denen sich das Team in der Sprint-Planungssitzung verpflichtet hat
—> legt fest, wie das Sprint-Ziel erreicht wird und fungiert als kollektives Zeitmanagementsystem

• eine Art Protokoll
• hier „pulled“ jeder die Aufgaben, die er als nächstes erledigen will
• Visualisierung der Arbeit, zeigt zwar auch auf, was noch zu erledigen ist, motiviert aber durch das Aufzeigen der bereits erledigten Aufgaben

Daily Scrum

—> eine auf 15 Minuten beschränkte Besprechung, die an jedem Arbeitstag am selben Ort zur selben Zeit stattfindet

• Welche Aktivitäten habe ich seit der letzen Daily Scrum abgeschlossen?
• Woran plane ich bis zur nächsten Daily Scrum zu arbiten?
• Werde ich in irgendeiner Form an der Ausführung einer Aktivität behindert?

—> Nützliche Techniken: beispielsweise ein Stand-Up Meeting

Sprint Review

• am Ende findet immer das Sprint Review statt
• Ziel der Sitzung ist es, die entstandenen Arbeitsergebnisse zu begutachten und den Projektfortschritt transparent zu machen
• der PO überprüft, ob das Team alle Anforderungen, zu denen es sich in der Sprint-Planungssitzung verpflichtet hat, erfolgreich umgesetzt hat

—> inspect and adapt

Sprint Retrospektive

• findet unmittelbar im Anschluss an und schließt den Sprint ab
• Zielsetzung: Zusammenarbeit innerhalb des Teams und die Anwendung des Prozesses zu verbessern

Personal Kanban

• Visualisierung und Planung von Aufgaben, Projekten und Terminen 

zwei Regeln:

1. Stellen Sie Ihre Arbeit bildlich dar
2. Machen Sie nicht zu viel auf einmal

• 6 Schritte wie man mit Personal Kanban arbeitet

1. Vorbereitung des Materials 
2. Ermitteln Sie den Wertstrom Ihrer Arbeit
3. Erstellen Sie Ihr Backlog
4. Legen Sie Ihr WIP-Limit (Work in Progress Limit) fest
5. Beginnen Sie, sich Aufgaben zu ziehen (=pull)
6. Besinnen Sie sich / Review
   - Welche Aufgaben haben Sie besonders gut erledigt?
   - Welche Aufgaben haben Sie stolz gemacht?
   - Welche Aufgaben waren schwer zu erledigen?
   - Waren die richtigen Aufgaben zur richtigen Zeit erledigt?
   - Haben die erledigten Aufgaben einen Wert generiert?
   

Was ist eigentlich Design?

„Wenn etwas besonders gut funktioniert, dann sieht es meistens auch so aus.“

—> Design ist nur dann gut, wenn es auch gut zu benutzen ist —> die Gestaltung der Funktionsweise führt zum neuen Design

„Einfach ist genaugenommen ziemlich kompliziert.“

—> Einfachheit ≠ Minimalismus
—> Einfachheit heißt, Ordnung in ein komplexes System zu bringen, und etwas zu schaffen, das
       einfach immer und überall funktioniert 

—> Einfach heißt, dass man etwas zum ersten Mal in die Hand nimmt, und trotzdem weiß, wie
       man es bedienen muss

„Gutes Design erkennt man, wenn man es benutzt.“
—> der Nutzen einer Sache ist immer das Wichtigste
—> man integriert Features nur dann, wenn sie wirklich nützlich sind, und nicht nur, weil es
       technologisch möglich ist 

„Technologie sollte den Menschen niemals im Weg stehen.“

—> wenn die Technologie genau für ein Individuum entwickelt wurde und man sich nicht erst an
       sie gewöhnen muss, dann kann man eine Art Beziehung zu dem Produkt aufbauen
—> gutes Design fördert diese
—> Interaktionen werden dynamisch

—> das Benutzererlebnis wird auf eine ganz natürliche Weise sehr lebendig

„Design ist nicht wie etwas aussieht oder sich anfühlt, sondern wie es funktioniert.“

„User-centred Design kann die Qualität eines interaktiven Systems verbessern.“

1. Steigerung der Produktivität der Benutzer und der Wirtschaftlichkeit von Organisationen
2. Verringerung der Kosten für Schulung und Betreuung
3. Erhöhte Zugänglichkeit durch Verbesserung der Gebrauchstauglichkeit
4. Verbesserung der User Experience
5. Reduzierung von Unbehagen und Stress
6. Schaffen eines Wettbewerbsvorteils
7. Erreichen von Nachhaltigkeitszielen

„Grundsätze der menschzentrierten Gestaltung“

1. Gestaltung basiert auf einem umfassenden Verständnis der Benutzer, Arbeitsaufgaben & Arbeitsumgebungen
2. Benutzer sind während der Gestaltung & Entwicklung einbezogen
3. Das Verfeinern & Anpassen wird fortlaufend auf Basis der benutzerzentrierter Evaluation vorangetrieben
4. Prozess sieht Iterationen vor
5. Bei der Gestaltung wird die gesamte User Experience berücksichtigt
6. Das Gestaltungsteam vereint fachübergreifende Kenntnisse und Gesichtspunkte

Was heißt eigentlich Usability?

• use = benutzen
• ability = Fähigkeit
• deutsche Übersetzung = Gebrauchstauglichkeit
• NICHT Benutzerfreundlichkeit
• bezieht sich uf den Zeitpunkt während der Nutzung

„Usability bezeichnet das Ausmaß in dem bestimmte Benutzer, in ihrem bestimmten Kontext, ihre bestimmten Aufgabenziele mit Effektivität, Effizienz und Zufriedenstellung erreichen können.“ (DIN ISO 9241-11)

Stufen des Erfüllungsgrads von Usabilty

Joy of Use

„Spaß und [die] Freude an der Nutzung oder die Bedeutung von Emotionen im Umgang mit Interaktiven Produkten.“

—> eine freudvoll-genussreiche Reaktion auf das Erleben der Qualität der Interaktion und der
       Möglichkeiten eines Software Produktes 

User Experience

• Wahrnehmungen und Reaktionen einer Person, die aus der tatsächlichen und /oder der erwarteten Benutzung eines Produkts, eines Systems oder einer Dienstleistung resultieren, wobei sämtliche Emotionen, Vorstellungen, Vorlieben, Wahrnehmungen, physiologischen und psychologischen Reaktionen, Verhaltensweisen und Leistungen, die sich vor, während und nach der Nutzung ergeben umfasst werden (ISO 9241-210,2010) 
• umfasst die Phasen vor und nach der Nutzung eines Produktes

 Usability Prozessmodelle

Benutzer-orienterte Gestaltung interaktiver Systeme (ISO 9241-210)

• Anleitung für die Planung und Durchführung von Benutzer-orienterten Gestaltungsaktivitäten während des gesamten Produktlebenszyklus
• Grundsätze:
  - Aktive Beteiligung der Benutzer und ein klares Verständnis von Benutzer- und
    Aufgabenanforderungen
  - Geeignete Funktionsaufteilung zwischen Benutzern und Technik
  - Integration von Gestaltungslösungen
  - Multidisziplinäre Gestaltung
• Hoher Abstraktionsgrad, deshalb leicht für alle Projektvorhaben genrealisierbar  
• Vier Durchführungsphasen (Kreislauf)
  -  Analyse Nutzungskontext
  - Entwicklung von Nutzungsanforderungen
  - Prototypisches Design
  - Prüfung

 Usability Engineering Lifecycle nach Mayhew

• Vollständige Ausrichtung der Entwicklung auf UCD Prinzipien und Methoden (nicht nur Einbindung von UCD Maßnahmen in Entwicklungszyklus)
• Integration des Wasserfallmodells in ein UCD-Modell (iterativer Ansatz)
• fünf Phasen
• Hoher Dataillierungsgrad mit genauer Beschreibung von:
  - Phasen
  - Notwendigen Aktivitäten
  - Methoden
  - Arbeitsergebnissen
  —> ist sehr komplex und wird in der Realität nur von Wenigen umgesetzt

Scenario-based Usability Engineering nach Rosson & Carroll

—> dies ist mein Schwerpunktthema, welches Sie sich hier angucken können

  Pervasive Usability Process nach Brinck et al.

• Speziell auf Gestaltung von Websites abgestimmt
• ist als idealtypische Vorlage aufzufassen
• Iterationen möglich trotz linearer Anordnung
• fünf Phasen und Aktivitäten

 Erweitertes 9241-210 Prozessmodell nach Fraunhofer FIT

• basiert auf ISO 9241-210
• Darstellung der Notwendigkeit die personellen und organisatorischen Rahmenbedingungen zu beachten
• Behandlung der Produkteinführung als eigene Phase zur Betonung ihrer Wichtigkeit (nicht die Annahme, dass ein interaktiver Prozess automatisch zur Benutzerzufriedenheit führt)
  —> „springt“ aus der Integration heraus und macht einer Benutzerorientierte Benutzereinführung 

 Methoden der Sozialforschung 

—> die drei grundlegenden Erhebungsmethoden:

• Beobachtung
• Interview
• Fragebogen

Herausforderungen der sozialen Situation

—> Beobachter und Interviewer sind Menschen!

—> Wahrnehmung jedes Menschen ist subjektiv gefärbt, je nach

• gemachten Erfahrungen und Sozialisierung
• (vermeintlichem) Vorwissen über das Gegenüber
• Erwartungen an die Situation
• die Wahrnehmung ist leicht beeinflussbar durch äußere Einflüsse

—> Soziale Interaktion verändert Verhalten

• unbewusste gegenseitige Beeinflussung der Interaktionspartner

Wichtige Fehlerfallen für Benutzer und Usability Engineer

BENUTZER	USABILITY ENGINEER
soziale Erwünschtheit Hawthrone-Effekt Positionseffekte Fehler der zentralen Tendenz	selbsterfüllende Prophezeiung Attributionsfehler Suggestivfragen und mehr

Soziale Erwünschtheit

• Versuchspersonen reagieren auf Fragen oder bestimmte Situationen so, wie sie denken, dass die Gesellschaft bzw. der Versuchsleiter erwartet
  —> Befragte geben Antworten, die nicht mit ihrer tatsächlichen Meinung übereinstimmen

Hawthrone-Effekt

• Versuchspersonen verhalten sich anders, da ihnen bewusst ist, dass sie beobachtet werden
  —> Ergebnisse der Studie werden durch die Studie selbst verfälscht

Positionseffekte

• Primacy Effekt
  —> Personen erinnern sich an die zuerst erhaltene Informationen
         —> der erste Eindruck steuert die Aufnahme weiterer Informationen
• Recency Effekt
  —> Personen erinnern sich an die zuletzt erhaltenen Informationen
         —> Versuchspersonen beurteilen bei Nachbefragungen meist nur die letzten Testminuten,
                 da sie sich am besten daran erinnern 

Fehler der zentralen Tendenz 

• entsprechend einer Normalverteilung werden extreme Urteile gemieden und neutrale bevorzugt
  —> bei Usability Test gelten neutrale Aussagen als Null-Aussagen

Selbsterfüllende Prophezeiung

• Versuchsleiter verhalten sich in der Versuchsperson gegenüber entsprechend ihrer Überzeugungen, Erwartungen, Einstellungen und Vorurteile
• Entsprechend entwickelt sich das Verhalten bzw die Leistung der Versuchsperson
  —> Das Verhalten der Versuchsperson wäre ohne den Versuchsleiter nicht in der gezeigten
         Form aufgetreten
  —> bspw wenn der Usability Prüfer unbewusst mehr Hilfe gibt, da die Versuchsperson
         hilfebedürftiger aussieht

Attributionsfehler

• Menschen tendieren dazu eigenes Verhalten eher auf sich selbst, als auf die Situation, zurückzuführen 

Suggestivfragen und mehr…

—> bei Befragungen sollten folgende Fragen vermieden werden:

• Suggestivfragen „Das ist doch kein Problem für Sie, oder?“
• Mehrdeutige Fragen „Beurteilen Sie die Aussage: Jeder Mann liebt eine Frau.“
• Doppelte Verneinungen „Halten Sie sich nicht für untalentiert?“

Fazit der Fehlerfallen

—> Beobachtungen sind immer subjektiv gefärbt

• Beobachter nimmt nur Ausschnitte der Realität wahr
• Beobachter sollte dennoch versuchen Daten so objektiv wie möglich aufzunehmen
• Hilfsmittel
  - genaues Beobachtungsschema
  - Vier-Augenprinzip (oder mehr)
  - Videoaufzeichnungen zur späteren Kontrolle
• Neutrale Formulierungen bei der Niederschrift der Daten

Drei Messdimensionen 

Qualitativ	Quantitativ
Analyse von Worten (z.B. Interviews), Bildern (z.B. Videos) oder Objekten (z.B. Lastenheft)	Analyse numerischer Daten
Ziel ist eine detaillierte Beschreibung des Untersuchungsgegenstandes	Ziel ist zahlenmäßige Erfassung eines Untersuchungsgegenstandes (und statistische Auswertung der Erkenntnisse)
Untersuchungsgegenstand ist oft nicht gut bekannt	Untersuchungsgegenstand klar definiert; detaillierte Versuchplanung erforderlich
Häufig genutzt bei explorativen Untersuchungen und Auswertungen	Weniger zeitaufwändig bei Durchführung und Auswertung
Generalisierbarkeit ist niedrig	Hohe Generalisierbarkeit (bei korrekter Planung)

EXPERTENSICHT / EXPERTENEVALUATION	Benutzersicht / Evaluation mit Benutzern
Evaluation des Untersuchungsobjekts durch Experten auf de Gebiet der Fragestellung (bspw. Usability-Experten)	Evaluation des Untersuchungsobjekts durch Beobachtung/Befragung tatsächlicher Benutzer des Untersuchungsobjekts
Überprüfung der Einhaltung von vordefinierten Kriterien oder Richtlinien
Ein oder mehrere Experten

Formative vs. Summative Evaluation

Evaluation Allgemein

• Abgleich von Ist- und Sollzustand

Formative Evaluation

• Prozessbegleitende Evaluation
• findet während der Entwicklung eines Projektes statt
• soll Informationen zur Verbesserung des Projektes liefern

Summative Evaluation

• fasst alle Ergebnisse eines Projektes, etc. abschließend zusammen
• es findet häufig eine abschließende Bewertung statt

Methoden des Usability Engineerings 

Analyse Nutzungskontext

• 80% der Kosten von Softwareentwicklungsprojekten entstehen in der Einführungsphase
• Davon 80% wegen nachträglicher Befriedigung unerwarteter Anforderungen der Benutzer
• Das Einbringen neuer Funktionen zu einem späten Stadium der Softwareentwicklung ist sehr viel teuerer als zu einem frühen Stadium

—> Ursache: Ungenaue Analyse des Nutzungskontextes

Bei der Analyse sind folgende Punkte zu berücksichtigen:

1. Der Benutzer —> relevante Merkmale können sein:

- Kenntnisse
- Fertigkeiten
- Erfahrungen
- Ausbildung
- Übungsgrad
- physische Merkmale
- motorische und sensorische Fähigkeiten

—> es kann notwendig sein Merkmale verschiedener Benutzertypen zu definieren

2. Die Aufgaben
—> sind die erforderlichen Aktivitäten, die wichtig für die Zielerreichung sind, aber sich in
       Häufigkeit und Dauer unterscheiden
—> sollten jeweils in ihrem Ablauf bis zur Zielerreichung und ihrem Zusammenspiel verstanden
       sein

3. Die Arbeitsmittel

—> relevante Mittel können Hardware und Materialien sein, die mit dem Computer
       zusammenhängen
—> können aber auch Hilfsmittel wie „Post-Its“, Taschenrechner oder Nachschlagewerke sein

4.  Die Organisation

- Firmenkultur,
- Arbeitspraxis
- Untenehmensphilosophie
- Arbeitsplatz
- Ausstattung
    

Methoden zur Erhebung des Nutzungskontextes

• Nutzungskontext empirisch analysieren, weil oft keine geeigneten Dokumente zu Zielen und Aufgaben der Benutzer zur Ausrüstung am Arbeitsplatz sowie die physische und soziale Umgebung vorliegen
• Aufgabenbeschreibungen eines Arbeitsplatzes oft nur formale Darstellung, ohne Tätigkeitsabläufe
• Unterschied zwischen der formal gestellten Aufgabe und der informellen Aufgabe, d.h. wie ein Mitarbeiter die Aufgabe versteht und tatsächlich bearbeitet
• die Gestaltung der Benutzerschnittstelle muss im Hinblock auf informelle Aufgaben erfolgen

Was sind eigentlich Anforderungen?

—> „Eine Beschaffenheit oder Fähigkeit des Systems, die von einem Benutzer zur Erreichung
        eines Arbeitsergebnisses benötigt wird.“ (IAEE Standard Glossar of Software Engineering
        Terminolgy, 1990)

Stakeholder-Anforderungen beschreiben die Wünsche, Verlangen, Erwartungen und Notwendigkeiten und sind die Basis für Systemanforderungen. 

Verschiedene Arten von Anforderungen:

• Gesetzliche Anforderungen
• Marktanforderungen
• Organisatorische Anforderungen
• Fachliche Anforderungen
• Nutzungsanforderungen
• Systemanforderungen

Was sind eigentlich Nutzungsanforderungen (requirements for use)?

„Eine erforderliche Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise - nicht realisierter Weise.“

—> beruhen auf Erfordernissen des Nutzungskontexts

(DAkkS Leitfaden Usability)

—> Benutzeraktionen werden unterschieden in beobachtbare Handlungen (= Benutzer muss im
       Kontext etwas auswählen/eingeben können) und kognitive Leistungen (= Benutzer muss im
       Kontext etwas erkennen können)

Entwicklung von Nutzungsanforderungen

EIGENSCHAFT	BESCHREIBUNG
Abstraktheit	Anforderungen sollen unabhängig von der konkreten technischen Umsetzung formuliert sein
Eindeutigkeit	Anforderungen sollen nur eine mögliche Interpretation zulassen.
Nachvollziehbarkeit	Anforderungen sollen zu ihrer Quelle zurückverfolgbar sein.
Überprüfbarkeit	Es soll gezeigt werden können, dass das System die Anforderungen tatsächlich erfüllt.

Nutzungsanforderungen herleiten

„If I’d have asked my customers what they wanted, they would have told me „A faster horse“.“ (Henry Ford)

—> Innovationen können besser sein, als Verbesserungen

Leitfaden Usability

—> Gestaltungsrahmen für den Usability Engineering Prozess
—> DAkkS-Prüfverfahren für en Usability Engineering Prozess auf der Grundlage von DIN EN ISO
       13407
—> DAkkS-Prüfverfahren für die Konformitätsprüfung interaktiver Systeme auf Grundlage von DIN
       EN ISO 9241-11 und -210

DAkkS-Verfahren

Nutzungsanforderungen

1. Tatsächliche Nutzergruppen ermitteln, definieren und beschreiben
2. Interviewleitfragen für Kontext-Interviews entwickeln
3. Kontext-Interviews durchführen und protokollieren
4. Kontextszenarien formulieren
5. Kontextszenarien validieren
6. Nutzungskontext pro Nutzergruppe als Kontext-Szenario beschreiben
7. Auswertungsschema anwenden
8. Liste mit Nutzungsanforderungen ableiten

Tatsächliche Nutzergruppen ermitteln

—> es sollten die Benutzer, Arbeitsaufgaben, Arbeitsmittel (Hardware, Software und Materialien),
       sowie die physische und soziale Umgebung mit einbezogen werden

—> Nutzergruppen können nach folgenden Merkmalen charakterisiert werden:

• Bezeichnung
• Demografische Rahmendaten
• Aufgabenwissen
• Soziale Umgebung
• Physische Umgebung
• Verwendete Arbeitsmittel
• ggf bekannte Vorlieben
• Abneigungen und Wünsche

Nutzungskontext pro Nutzergruppe beschreiben

—> pro Nutzergruppe sollten mindestens 3-5 sogenannte „Kontext-Szenarien“ auf Basis von je ca. zweistündigen Einzelinterviews durch hierfür qualifiziertes Personal erhoben werden

Vorgehen bei der Durchführung von Kontext-Interviews

• echte Repräsentanten einer Benutzergruppe in Einzelgesprächen interviewen - „Kontext-Interviews“
• Im Vorfeld ein Experteninterview mit einer Führungskraft über die organisatorischen Rahmenbedingungen führen
• Interviews immer im Vorfeld mit jeweiligem Vorgesetzten abstimmen und planen (ggf. Betriebsrat/Personalrat in Kenntnis setzen)
• Pro Interview einen Zeitrahmen von ca. zwei Stunden planen
• In Bezug auf das Interview und die Interviewdaten Anonymität zusichern (Codenamen vergeben)
• Für das Interview Leitfragen bereithalten
• Zwei Interviewer (einer führt das Gespräch, ein weiter erfasst und dokumentiert die relevanten Daten)
• Nur ein Repräsentant pro Interview (keine „Gruppengespräche“)
• Fokus des Gesprächs: Tätigkeiten des Befragten mit all seinen Facetten, so wie sich das täglich am Arbeitsplatz ereignet

Vorgehen beim Dokumentieren von Kontext-Interviews

• Nach den Interviews möglichst am gleichen Tag (spätestens am nächsten Tag!) das Interview als Kontext-Szenario durch einen der beiden Interviewer aufschreiben (nicht aufschieben!!)
• Das Kontext-Szenario gemeinsam mit dem zweiten Interviewer durchsprechen —> haben beide das gleiche verstanden?
• Alle Unklarheiten und offenen Fragen and den entsprechenden Textstellen mit aufschreiben und im Text markieren
• Das Kontext-Szenario mit der interviewten Person durchgehen und auf Unvollständigkeit und Verständnisfehler hin überprüfen —> Ergebnis: Validiertes Kontext-Szenario
• Das Kontext-Szenario fertigstellen, bevor man in das nächste Interview geht

Struktur für das Aufschreiben von Kontext-Szenarien

 Der Auswertungsprozess

                                             

Schema zur Auswertung von Kontext-Szenarien

KONTEXT-SZENARIO	ERFORDERNIS	NUTZUNGSANFORDERUNG
Authentische Beschreibung aus dem Kontext-Szenario	Welchem Zweck dienen die beschriebenen Fakten und welche Voraussetzungen müssen gegeben sein, um diesen Zweck wirksam zu dienen?	Welche Aktion(-en)[...]

Gütekriterien für Erfordernisse

—> eine notwendige Voraussetzung, die es ermöglicht, den in einem Sachverhalt des Nutzungskontexts enthaltenen Zweck effizient zu erfüllen

• Erfordernisse stehen immer im Bezug zum Kontext und begründet das, was im Kontext geschieht
• Erfordernisse bestehen immer aus einer Voraussetzung und dem Zweck, dem diese Voraussetzung dient
• Erfordernisse sind unstrittig und für alle Beteiligten einer Nutzergruppe zutreffend
• Erfordernisse haben keinen Bezug zum System
• Formulierungshilfen für die Formulierung von Erfordernissen:
  - Der <Rollenbezeichnung> muss X einschätzen können, um Y tun/sicherstellen zu können
  - Der <Rollenbezeichnung> muss X wissen, um Y tun/sicherstellen zu können
  - Der <Rollenbezeichnung> muss X verfügbar haben, um Y tun/sicherstellen zu können
  - Der <Rollenbezeichnung> muss auf X vorbereitet sein, um Y tun/sicherstellen zu können

Gütekriterien für Nutzungsanforderungen

—> eine erforderliche Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise - nicht in technische realisierter Weise

• Nutzungsanforderungen beruhen immer auf einem Erfordernis —> sie sind Interpretationen des Erfordernisses, die beschreiben, wie dieses erfüllt werden kann, ohne eine konkrete Lösung vorzugeben
• Nutzungsanforderungen sind auf eine prospektive Unterstützung des Kontextes durch ein System oder eine Dienstleistung hin formuliert
• Formulierungshilfen für die Formulierung von Nutzungsanforderungen:
  - Der Nutzer muss am System X erkennen können
  - Der Nutzer muss sich am System über X informieren können
  - Der Nutzer muss am System X im Zusammenhang erkennen 

Prototypisches Design

• Anforderungen (nach und nach) Gestalt geben
• Gestaltungsidee für Benutzer erlebbar machen
• „Kultur des Ausprobieren“ —> Wegwerfen tut nicht weh (iteration)
• Kultur des Abwägens
• Vom Groben zum Feinen (Besser eine Skizze als direkt alles perfekt in Photoshop —> Wegwerfen fällt leichter)
  —> Lieber zu viele Ideen

Prototyping Stufen

 Prototypisches Design — Methoden

• Paper-Pencil
  - Benutzer traut sich eher zu sagen „Das passt nicht, ich möchte es anders“, weil es unfertig
     aussieht
  - schnell zu erstellen
  - keine ablenkenden „Geschmacks-Diskussionen“
• Mockups
• Claims Analysis
  - Abwägen von Vor- und Nachteilen
  - verschiedene Versionen abwägen
• horizontale bs. vertikale Prototypen

Prüfung — Anlässe und Methoden

Szenarien-basierter Walktrough

Durchführung

• Fokus ISO 9241-110
• Usability-Experten arbeiten mit System typische Testaufgaben ab
• Vieraugenprinzip
• bei jeder potentiellen kritischen Nutzungssituation wird geprüft, ob diese ein Problem gemäß ISO 9241-110 ist 

 Heuristische Evaluation (Nielsen)

—> Mehrere Usability-Experten inspizieren getrennt voneinander ein Stetem gemäß 10 Usability-Daumenregeln (Heuristiken)

—> 5 Experten finden 75% aller Usability-Probleme

• sehr kostengünstige und effektive Methode
• kann schon im frühen Stadium der Produktentwicklung durchgeführt werden
• aber nicht geeignet, alle Usability-Probleme zu identifizieren
• kein Ersatz für Benutzungstests
• es hat sich allerdings als sehr nützlich erwiesen, heuristische Evaluation mit Benutzungstests zu kombinieren 

Die 10 Usability-Heuristiken

1. Der Systemstatus sollte dem Benutzer immer transparent sein.
2. Das System sollte die Welt des Benutzers abbilden.
3. Der Benutzer sollte das System steuern können und Freiheitsgrade in der Bedienung haben.
4. Das System sollte konsistent sein und gängigen Standards entsprechen.
5. Das System sollte den Benutzer vor Fehlern bewahren.
6. Mentale Belastung des Benutzers sollte vermieden werden (Recognition rather than recall).
7. Das System sollte flexibel und effizient nutzbar sein (Expertenmodus, SHortcuts, Accelerators).
8. Das System sollte nur die notwendigen Informationen anzeigen.
9. Benutzer sollten dabei unterstützt werden Fehler zu erkennen, zu diagnostizieren und zu lösen.
10. Die Hilfe und Benutzerdokumentation sollte leicht zu finden sein, aufgabenbezogen, handlungsleitend und nicht zu umfassend.

Inspektion

—> Experte prüft ab, ob System bestimmten Anforderungen (Prüffkriterien) gerecht wird

Kontextunabhängige Anforderungen

Prüfkriterien stammen z.B. aus der Norm („Es sollte keine reine Farbcodierung verwendet werden.“)

Kontextabhängige Anforderungen 

Prüfkriterien sind unter Benutzerbeteiligung aus dem Kontext entwickelte Anforderungen, z.B. „Es sollte möglich sein, Fotos als ‚bereits in das Album geklebt‘ zu kennzeichen.“

Benutzungstests

—> Durchführung

• im Labor oder im Feld
• Benutzer arbeiten mit System typische Testaufgaben ab
• Usability-Engenieer fordert Benutzer auf, seine  Gedanken bei der Aufgabenbearbeitung zu verbalisieren (Teilnehmende Beobachtung mit Thinking Aloud)
• bei jeder kritischen Nutzungssitutaion wird geprüft, ob diese ein Problem gemäß ISO 9241-110 ist —> Thinking Aloud hilft dabei die Ursachen zu beleuchten

Ablauf

1. Begrüßung, Formalia
   „Small-Talk“, Getränk anbieten, ggf. Geheimhaltungserklärung)
2. Inhaltliches Briefing
   Testgrund, Testziel, Testablauf inkl. Hinweis darauf, dass mitgeschrieben wird
3. Testdurchführung
   Abarbeiten des Leitfadens, ggf. Fragebögen
4. Intensivierung, Verabschiedung
   Quittung, bedanken fürs Mitmachen 

Testpersonen

—> Anzahl der Testpersonen für Teilnehmende Beobachtung mit Thinking Aloud—> 6 Personen

• Internationale Studien zeigen, dass mit sechs Benutzern im Test bis zu 80% der Nutzungsprobleme entdeckt werden können
• Unter diesen 80% werden alle schwerwiegenden Probleme gefunden = „Usabililty Disasters“

Inhaltliche Testplanung

Werkzeug Moderationsleitfaden

• in der Hand des Moderators
• legt den Testablauf fest, z.B. Zeitpunkt des Einsatzes von Fragebögen, wann Zeit zu stoppen ist
• beinhaltet Zusatzfragen, Hinweise auf besondere „Points of Interesses“ des Auftraggebers

Werkzeug Testleitfaden

• in der Hand des Benutzers
• enthält Testszenarien zum Nachlesen

Organisatorische Testplanung

Organisation der Testnutzer

• je Testaufgabe 5-6 Testnutzer
• je Benutzungstest (mit teilnehmender Beobachtung und Thinking Aloud) 90 Minuten (inkl. Briefing und De-Briefing); zur Vor- und Nachbereitung der Testsituation 30 Minuten 
• im Vorfeld Excel-Sheets anlegen mit
  - den zeitlichen Testlots an den Testtagen
  - Testnutzer mit Kontaktdaten eintragen
• Pro Testperson eine einheitliche Testkennung vergeben, die Rückschlüsse auf den Testgegenstand und die Zugehörigkeit zur Benutzergruppe zulässt

Organisation des Begleitmaterials

• Klemmbrett, Papier und Stift
• Moderationsleitfaden bereitlegen
• Testleitfaden bereitlegen
• Fragebögen ausdrucken und mit Testnutzerkennung versehen
• Zustimmungs- und Geheimhaltungserklärung bereitlegen
• Quittungen für Intensivierung Breitlegen
• Anderweitige Inzentives bereitlegen
• Getränke breitstellen

„Benutzungstest-Knigge“

• Kleidung nicht zu förmlich, da dies einschüchtern kann
• „Wir-Gefühl“ schaffen
• Wohlfühlatmosphäre
• nicht der Nutzer, sondern System wird getestet
• Benutzer kann nichts falsch machen
• Daten bleiben geheim
• Tempo möglichst zum Mitschreiben einhalten

Qualitative Fragebögen

—> ErgoNorm-Benutzerfragebogen (DAkkS Leitfaden Usability, ab S.170)

• Benutzer füllt Fragebogen pro Aufgabe/Tätigkeit aus
• die Fragen testen die Dialogprinzipien der ISO 9241-110 ab
• der Benutzer wird über die Dialogprinzipien aufgeklärt, bevor er die Fragen zu den Prinzipien beantwortet

Fokusgruppen

• Benutzer
  - diskutieren Designentwürfe
  - gestalten selbst
• Hauptnutzen
  - Identifikation mentaler Modelle
  - Vorlieben/Abneigungeen
  - Wünsche
  - (Validierung) Anforderungen
• Ideale Teilnehmeranzahl: 7 (empirischer Wert)
• Teilnehmer müssen „homogen“ sein

Quantitative Fragebögen zur Usability

• Software Usability Measurement Inventory (SUMI)
• System Usability Scale (SUS)
• Website Analysis and MeasureMent Inventory (WAMMI)

Software Usability Measurement Inventory (SUSMI)

• Effizienz
  Wird der Aufwand der Aufgabenbearbeitung mit dem System als angemessen erlebt oder fühlt sich der Benutzer durch die Software bei seiner Arbeitserledigung behindert?
• Positive Einstellung
  Hat der Benutzer eine positive Einstellung gegenüber der Nutzung des Systems?
• Nützlichkeit
  Wird das System aus Benutzersicht als hilfreich in Bezug auf die Erledigung der alltäglichen Arbeitsaufgaben erlebt?
• Kontrolle
  Hat der Benutzer das Gefühl, das System jederzeit „im Griff“ zu haben?
• Erlernbarkeit
  Hat der Benutzer den Eindruck, dass das System mit angemessenem Aufwand erlernbar ist?

• 50 Fragen
• Antworten in drei distinktiv Antwortkategorien („stimmt“, „stimmt nicht“, „weiß nicht“)
• Auswertung über SUMI-Software
• Mindestens 10 Personen pro Benutzergruppe
• SUMI liefert die Bewertung der Benutzer auf einer normierten Skala von 1-100
• Erwwartungswerte for Standardsoftware liegen bei 50
• in die Standardisierung der SUMI-Skalen sind die Ergebnisse von über 2000 Softwareprodukten eingegangen

—> hohe Validität der Ergebnisse schon bei einer relativ kleinen Zahl von Benutzern aus einer homogenen Benutzergruppe

System Usability Scale (SUS)

• Usability-Aspekte
  - Hilfebedarf
  - Schulungsbedarf
  - Komplexität der Anwendung
• 5-Stufige Skala 
• Hohe Korrelation zu SUMI

Website Analysis and MeasureMent Inventory (WAMMI)

• 20 Fragen
• optimal 30 Personen
• 5-stufige Likert-Skala
• Computer-gestützte Auswertung
• Nutzbar für Benchamrking und „Optimierungsverlauf“

Quantitative Fragebögen zur Joy of Use — AttrakDiff

• gratis im Internet verfügbar
• Vorher-/Nachhermessungen
• Verglecihsmessungen
• Einzelmessungen

Dimensionen:

• Pragmatische Qualität (PQ)
  - beschreibt die Benutzbarkeit eines Produktes
  - verdeutlicht wie gut der Nutzer seine Ziele erreichen kann
• Hedonische Qualität — Stimulation (HQ-S)
  - bildet ab wie weit das Produkt die Entwicklung fördert
• Hedonische Qualität — Identität (HQ-I)
  - beschreibt inwieweit sich ein Nutzer mit seinem Produkt identifizieren kann
• Attraktivität (ATT)
  - beschreibt globale Bewertung auf der Basis der wahrgenommen Qualität

Dialogprinzipien ISO9241-110

Aufgabenangemessheit

—> „Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen, d.h. wenn Funktionalität und Dialog auf den charakteristischen Eigenschaften der Arbeitsaufgabe basieren“
Beispiel: „Der Benutzer muss den Cursor immer per Hand in das Feld „Kapitel/Titel“ setzen. Er wundert sich, warum dieser da nicht von vorne herein steht, denn es ist immer das erste Feld in das er seine Eingaben macht.“

Selbstbeschreibungsfähigkeit

—> „Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog er sich befindet, welche Handlungen übernommen werden können und wie diese ausgeführt werden können“
Beispiel: „Der Benutz wundert sich: Auf der Maske „Verbuchungsstellen pflegen“ können weder die Checkboxen noch die Radioboxen ausgewählt werden, obwohl die weiße Hinterlegung suggeriert, dass sie aktiv sind.“

Steuerbarkeit
—> „Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.“

Beispiel: „Der Benutzer ärgert sich, dass er bei dem langen Formular keinen Zwischenstand speichern kann. Er kann das gesamte Formular nur „in einem Rutsch“ ausfüllen.“

Erwartungskonformität
—> „Ein Dialog ist erwartungskonform, wenn er (in sich konsistent ist), den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen, sowie allgemein anerkannten Konventionen entspricht.“
Beispiel: „Der Benutzer darf an dieser Stelle bei der Eingabe des Dateinamens die Endung „*.dat“ nicht eintippen, obwohl diese im vorherigen Arbeitsschritt unbedingt erforderlich war. Hierbei vertut er sich oft. Andere Benutzer klagen ebenfalls über diese Inkonsistent bei der Dateneingabe.“

Fehlertoleranz
—> „Ein Dialog ist Fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seines des Benutzers erreicht werden kann.“
Beispiel: „Das Programm stürzt an dieser Stelle fast immer ab, wenn der Benutzer aus versehen einen falschen Buchstaben eingibt.“

Individualiserbarkeit
—> „Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-System-Interaktion und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen.“
Beispiel: „Der Benutzer ärgert sich über die kleinen Buchstaben auf dem Bildschirm. Diese sind für ihn nur mühevoll zu lesen. Leider kann er diese nicht größer anzeigen lassen.“

Lernförderlichkeit
—> „Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlenern der Nutzung des interaktiven Systems unterstützt und anleitet.“
Beispiel: „Der Benutzer weiß nicht, wie er mit der Software die Grafik für das Internet aufbereiten kann. Er findet im System dazu keine aufgabenbezogene Hilfe.“

FAZIT

In dem Seminar „Medien in der Lehre“ habe ich viele verschiedene Dinge über Design, Projektmanagement, und Usability im Allgemeinen gelernt. Auch haben wir einige nützliche Vertiefungsaufgaben zu diesen Themen bearbeitet. Besonders gut gefallen hat mir, dass uns dadurch ein großer Einblick auf ein mögliches, späteres Berufsleben gegeben wurde.