Das Dokument kritisiert den 'nutzerzentrierten Design-Prozess' (UCD) und verweist auf mehrere Probleme, die zu ungünstigen Projektergebnissen führen können, wenn wichtige Nutzungsanforderungen nicht berücksichtigt werden. Es wird argumentiert, dass ein evidenz-basierter Ansatz bessere Resultate und effizientere Projekte liefert, während meinungsbasiertes Design zu hohen Kosten und schlechten Ergebnissen führt. Abschließend wird empfohlen, die Normen von ISO 9241-210 als Checkliste für erfolgreiche UCD-Projekte zu nutzen.

1. Prozess Checkliste.
Weg mit dem
„UCD-Prozess“!
Arno Bublitz
World Usability Day 2016 Hamburg

2. Bevor es losgeht:
Ein paar Fragen

3. OK, jetzt zum
„Nutzerzentrierten Prozess“

4. Quelle: de.wikipedia.org/wiki/ISO_13407
„Entwicklungsprozess“

7. Drei Probleme mit
diesem „Prozess“

8. 1: Wann
kommen wir
da raus?
Inkompatibel mit
Projektvorstellungen
Kriterien für „gut“
sind unklar
Nicht kompatibel mit
gängigen Vorgehensmodellen
Quelle: de.wikipedia.org/wiki/ISO_13407

9. 2: Ein seltsames Bild von Iteration
Quellen: jordisan.net ; smart.com ; caranddriver.com ; iihs.org ; volkswagenaustralia.com.au
VS.

10. 3: Es ist falsch
• Die Norm spricht vom
„Abhängigkeit“ zwischen
Nutzer-zentrierten Design-
Aktivitäten
• …und sie stellt klar…
Quelle: ISO-9241-210:2100, S.11

11. • … dass ein User Centered
Design Ansatz mit
verschiedenen Entwicklungs-
Prozessen vereinbar ist. Z.B.
• Objekt-Orientiert
• Wasserfall
• Rapid Application
Development
Quelle: ISO-9241-210:2100, S.VI

12. OK, aber…
Warum kümmert mich das?

13. Nutzer-zentriertes Design
hilft Projekten und Nutzern
• Nutzerzentriert = Evidenz-basiert*
• = starke Argumente ggü. mächtigen Stakeholdern
• = weniger Diskussionen im Projekt
• = schnellere, wirtschaftlichere Projekte
• = Bessere Projektergebnisse, bessere UI
*) i.Ggs. zu Meinungs-basiert

14. Wenn UCD nicht verstanden wird…
wird es nicht gemacht
?
Meinungsbasiertes statt Evidenz-basiertem Design
Und damit leidet die Nachhaltigkeit von UX

15. Ignorance Centred Design
(ICD)
• Keine harten Argumente, warum etwas „so“
gemacht werden sollte und nicht anders
• lange, fruchtlose Diskussionen im Projekt
• Schwach argumentierte Priorisierung
• schlechte Projektergebnisse
• teure Projekte
Und das führt zu…

16. ICD kostet … Milliarden
Allein ich habe unmittelbar und mittelbar Projekte
scheitern sehen mit einem budgetierten
Gesamtvolumen von ca. 1 Mrd. Euro…
… u.a. weil im Anforderungsprozess
Nutzungskontext und Nutzeranforderungen fehlten

17. Zwischenfazit
• UCD macht Sinn, weil dabei erfolgreiche Produkte
und erfolgreiche Projekte herauskommen
• Die „üblichen“ Vorgehensweisen funktionieren
anders, Usability ist so etwas wie ein Nach-
Gedanke. (Für uns ist es zentral für die
Anforderungen…)

18. Deborah Mayhew’s Usability
Engineering Lifecycle
• Zuerst Rahmenbedingungen,
Anforderungen der
Organisation
• Dann iteratives Design von
Struktur zu detailliertem Design
auf 3 Ebenen
• inkl echt heißem Scheiß:
Pattern-Libraries…
(aka “Design-Standards“)
Quelle: https://twobenches.files.wordpress.com/2008/06/47-01.jpg

19. Rapid Prototyping /
Rapid User Testing
• Dienstleistungs-Ansatz, wenn
Unternehmen keine Mitarbeiter
für eine Wochen Klausur
schicken können
• Ähnlich Design Sprint: Kein
direktes Kontext Research
• User Test ohne Test-Report,
stattdessen Beobachtung
durch Mitarbeiter des Kunden
Kick-Off & Anforderungen
1. Prototyp & Feedback
2. Prototyp & User Test
Finalisierung & Übergabe
Quelle & Copyright: Arno Bublitz
Rapid Prot /
Rapid UT
Plan the User
Centered Process ✅
Understand & Specify
Context of Use ✅
Specify User
Requirements ✅
Produce (iterative)
Design Solutions to
meet User
Requirements
✅
Evaluate Design
against
Requirements
✅

20. „Normale“ Software
Entwicklung

21. Quelle: de.wikipedia.org/wiki/sdlc

22. Quelle: de.wikipedia.org/wiki/sdlc
User/Context Research
&
Artefakte
Prototype
1
+
User Test
Prototype
N
+
User Test
…mit UX Aktivitäten

24. Sprint 0
Context
Research

25. Die Anforderungen der ISO9241-210
lassen sich erfüllen!
SDLC SDLC mit UX-Aktivitäten Scrum
Scrum
+ Sprint 0 / Design Spike
Plan the User Centered
Process ❌ ✅ ❌ ✅
Understand & Specify
Context of Use ❌ ✅ ❌ ✅
Specify User
Requirements ❌ ✅ ❌ ✅
Produce (iterative)
Design Solutions to meet
User Requirements
❌ ✅ ✅ / ❌ ✅
Evaluate Design against
Requirements
✅
im Live-Betrieb
✅ ✅ / ❌ ✅ / ❌

26. Mein Schluss-Plädoyer
1. Streicht das Kreislauf-Diagramm aus den
Foliensätzen
2. Nutzt die Norm als Checkliste für Eure Projekte,
3. Stellt die unangenehmen Fragen, zB:
„Kennen wir überhaupt den Nutzungskontext
und die Ziele der Nutzer?“

27. Danke!
Arno Bublitz
arno@bublitz.at
www.xing.com/profile/Arno_Bublitz
@abublitz

28. Echte UCD-Modelle

29. Eric Schaffer’s HFI Framework
• Verschiedene Projekttypen
• Zentrale Elemente
• Structural Design
• Detailed Design
• Eine Variation vom UELC
Quelle & Copyright: Human Factors International

30. Google Design Sprint
• Im Kern ein schneller
UCD-Cycle mit
indirektem User-Kontext-
Research
• 1 Woche Team-Arbeit
ohne andere
Verpflichtungen
Quelle: developers.google.com/design-sprint/

31. Was haben diese
Ansätze gemeinsam?

32. Sie erfüllen die Anforderungen
der ISO9241-210
Mayhew
UELC
Schaffer
HFI FW
Google Design Sprint
Plan the User Centered Process ✅ ✅ ✅
Understand & Specify Context
of Use ✅ ✅ ✅
(indirekt)
Specify User Requirements ✅ ✅ ✅
(indirekt)
Produce (iterative) Design
Solutions to meet User
Requirements
✅ ✅ ✅
Evaluate Design against
Requirements ✅ ✅ ✅