Embed Size (px)
Citation preview
Process Checklist. Get rid of the
„UCD-Prozess“!Arno Bublitz
World Usability Day 2016 Hamburg
Upfront: A couple of questions
OK, now concerning that „User Centered Design
Prozess“
Quelle: de.wikipedia.org/wiki/ISO_13407
„Developement Process“
Three Problems with this „Process“
1: How are we going to get out of here?
Not compatible with project conventions
No criteria for breaking out
Not kompatible with prevailing models
Quelle: de.wikipedia.org/wiki/ISO_13407
2: A strange picture of Iteration
Quellen: jordisan.net ; smart.com ; caranddriver.com ; iihs.org ; volkswagenaustralia.com.au
VS.
3: It’s just plain wrong
• The Standard explicitly talks about „Interdependence“ of activities
• …and clarifies…
Quelle: ISO-9241-210:2100, S.11
• … that User Centered Design Approach can be incorporated in diverse Development Models such as.
• Objekt-Oriented
• Waterfall
• Rapid Application Development
Quelle: ISO-9241-210:2100, S.VI
OK, but… Why do I care?
User Centered Design helps Projects AND Users
• User Centred = Evidence-based*
• = strong Arguments vis-a-vis powerful stakeholders
• = fewer Diskussions in Projects (and more productive ones)
• = fester more efficient Projects
• = Better Project Results, better UI*) i.Ggs. zu Meinungs-basiert
If UCD is not understood … It will not be practiced
?Opinio-based instead of Evidence-based Design
Und damit leidet die Nachhaltigkeit von UX
Ignorance Centred Design (ICD)
• No strong Argumente, why decide exactly „this way“ and not differently
• long and infertile Discussions in Projects
• Weakly built Prioritization
• Bad Project Results
• Expensive Projects
That leads to …
ICD costs … Billions
Your’s truly alone has seen Projects fail that amounted to a total Budget Sum of approx. 1 Bln. Euro…
… among other reasons because Context of Use and User Requirements were missing
Preliminary Conclusion
• UCD should be practised, because it yields better digital products
• The circular UCD „Process“ depiction inhibits a wider application of UCD. It is misleading and wrong
Deborah Mayhew’s Usability Engineering Lifecycle
• Business Parameters and Requirements first
• Then iterative Design from Structure to detaillied Design
• inkl really hot stuff: Pattern-Libraries…(aka “Design-Standards“)
Quelle: https://twobenches.files.wordpress.com/2008/06/47-01.jpg
One of my Approaches: Rapid Prototyping /Rapid User Testing
• Service Approach if clients cannot lock up an entire Team into a meeting room for a week without email
• Similar to Google Design Sprint: No direkt upfront Context Research
• User Test without Test-Report, instead: Clients observe
Kick-Off & Requirements
1. Prototype & Feedback
2. Prototype & User Test
Finalising & Handover
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 ✅
„Normal“ Software Development
Quelle: de.wikipedia.org/wiki/sdlc
Quelle: de.wikipedia.org/wiki/sdlc
User/Context Research
& Artefakts
Prototype 1 +
User Test
Prototype N
+ User Test
…with UX Activities
Sprint 0 Context
Research
Die Requirements of ISO9241-210 can be fulfilled!
SDLC SDLC with UX-Aktivities 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-Operations
✅ ✅ / ❌ ✅ / ❌
My closing Appeal
1. Delete the „Process“-Diagram from your Slide Decks
2. Use the Standard as checklist and be flexible about Development Lifecycles,
3. Ask the awkward and painful Questions:„Do we really know our cusomters’ context? Do we really know what the customers want to achieve??“
