Tom Stewart - If UCD is so great, why are more systems not perfect?

374 views

Published on

User centred design is now mainstream. It’s widely accepted as the best way to create usable systems. Not everyone follows the ISO standard for UCD (ISO 9241-210 previously known as ISO 13407) but the basic principles seem unarguable. Start by understanding the users and context. Then set measurable objectives and test potential designs against these objectives with typical users. Keep refining the design till it meets the objectives. What could possibly go wrong? In this presentation we discuss a number of real world stumbling blocks which mean that even when the process is followed properly ( and not doing it properly is one of the first stumbling blocks), the results are not always what was wanted. Issues include failing to get management buy-in, testing with the wrong users and fixed project schedules which preclude fixing known problems.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
374
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tom Stewart - If UCD is so great, why are more systems not perfect?

  1. 1. 9.30 Saturday 10 November 2012 Tom Stewart, Founder System Concepts If UCD is so great, why are more systems not perfect? User centred design is now mainstream. Its widely accepted as the best way to create usable systems. Not everyone follows the ISO standard for UCD (ISO 9241-210 previously known as ISO 13407) but the basic principles seem unarguable. Start by understanding the users and context. Then set measurable objectives and test potential designs against these objectives with typical users. Keep refining the design till it meets the objectives. What could possibly go wrong? In this presentation we discuss a number of real world stumbling blocks which mean that even when the process is followed properly ( and not doing it properly is one of the first stumbling blocks), the results are not always what was wanted. Issues include failing to get management buy-in, testing with the wrong users and fixed project schedules which preclude fixing known problems. , This document and it’s content is Copyright ©2012 [Tom Stewart] and UCD UK Limited.Supporters Sponsors Organiser 1
  2. 2. If UCD is so great, why are more systems not perfect?Supporters Sponsors Organiser 2
  3. 3. Actually, IT projects have a long history of failureSupporters Sponsors Organiser 3
  4. 4. Typical reasons for failure 1. The technology didn’t workSupporters Sponsors Organiser 4
  5. 5. Me = Mistake editionSupporters Sponsors Organiser 5
  6. 6. Typical reasons for failure 1. The technology didn’t work 2. Unrealistic ambitionsSupporters Sponsors Organiser 6
  7. 7. • Other thoughts “the new system will let everyone be customer facing so customer service will be great!”Supporters Sponsors Organiser 7
  8. 8. Typical reasons for failure 1. The technology didn’t work 2. Unrealistic ambitions 3. Rejected by usersSupporters Sponsors Organiser 8
  9. 9. User feedback “in the FCO’s long history of ineptly implemented IT initiatives, Prism is the most badly-designed, ill- considered one of the lot”Supporters Sponsors Organiser 9
  10. 10. Supporters Sponsors Organiser 10 10
  11. 11. UCD is the solution but not everyone gets it (Google user centred design)Supporters Sponsors Organiser 11
  12. 12. Supporters Sponsors Organiser 12
  13. 13. Supporters Sponsors Organiser 13
  14. 14. But most do (Google images for User Centre Design)Supporters Sponsors Organiser 14
  15. 15. Supporters Sponsors Organiser 15
  16. 16. Standards trivia • Started as ISO 13407 • “Human centred” to reflect more stakeholders • Revision is part 210 of ISO 9241 series • Part 210 contains “shalls” ie can claim conformanceSupporters Sponsors Organiser 16
  17. 17. Warning! Photos from this point are NOT from the actual project or clientSupporters Sponsors Organiser 17
  18. 18. Plan the human-centred design processSupporters Sponsors Organiser 18
  19. 19. Plan the human-centred design process • What can go wrong?Supporters Sponsors Organiser 19
  20. 20. Supporters Sponsors Organiser 20
  21. 21. Plan the human-centred design process • What can go wrong? – Phased development with no time to incorporate feedback after initial phases – Organisational changes exposed ‘accidentally’ during design consultation • Lessons – Plan for time to incorporate feedback – Don’t use IT to force organisational changeSupporters Sponsors Organiser 21
  22. 22. Understand and specify the context of useSupporters Sponsors Organiser 22
  23. 23. Understand and specify the context of use • What can go wrong?Supporters Sponsors Organiser 23
  24. 24. Supporters Sponsors Organiser 24
  25. 25. Understand and specify the context of use • What can go wrong? – Scope and position of new product assumed by remote teams • Lesson – Communicate context of use as early as possible to as many stakeholders as possibleSupporters Sponsors Organiser 25
  26. 26. Specify the user requirementsSupporters Sponsors Organiser 26
  27. 27. Specify the user requirements • What can go wrong?Supporters Sponsors Organiser 27
  28. 28. Supporters Sponsors Organiser 28
  29. 29. Specify the user requirements • What can go wrong? – Project team “hadn’t decided who would use system”, planned to install then see “who took to it best” • Lesson – Be absolutely clear about target user characteristicsSupporters Sponsors Organiser 29
  30. 30. Produce design solutions to meet user requirementsSupporters Sponsors Organiser 30
  31. 31. Produce design solutions to meet user requirements • What can go wrong?Supporters Sponsors Organiser 31
  32. 32. Supporters Sponsors Organiser 32
  33. 33. Produce design solutions to meet user requirements • What can go wrong? – Too early focus on detail, users reluctant to criticise what appear to be fully worked designs • Lesson – Keep design concepts simple prior to initial evaluationSupporters Sponsors Organiser 33
  34. 34. Supporters Sponsors Organiser 34
  35. 35. Evaluate the designs against the requirements • What can go wrong? – Not test at allSupporters Sponsors Organiser 35
  36. 36. Supporters Sponsors Organiser 36
  37. 37. Supporters Sponsors Organiser 37
  38. 38. Supporters Sponsors Organiser 38
  39. 39. Evaluate the designs against the requirements • What can go wrong? – Not test at all – Test with wrong users and tasks – managers instead of staff • Lesson – Test with real users and their tasksSupporters Sponsors Organiser 39
  40. 40. Supporters Sponsors Organiser 40
  41. 41. Iterate where appropriate • What can go wrong?Supporters Sponsors Organiser 41
  42. 42. “Most government IT therefore remains trapped in an outdated model, which attempts to lock project requirements up-front and then proceeds at a glacial pace. The result is repeated system-wide failure” Report published by the Institute for Government, March 2011 www.instituteforgovernment.org.ukSupporters Sponsors Organiser 42
  43. 43. Iterate where appropriate • What can go wrong? – Not enough time to iterate, made worse by contractual straightjackets • Lesson – Plan better, gain management buy in to agile/ucd process to minimise risk as part of organisations IT governanceSupporters Sponsors Organiser 43
  44. 44. Supporters Sponsors Organiser 44 44
  45. 45. Tom Stewart tom@system-concepts.com 020 7240 3388 www.system-concepts.comSupporters Sponsors Organiser 45
  46. 46. “Many forms of Government design process have been tried, and will be tried in this world of sin and woe. No one pretends that democracy user centred design is perfect or all-wise. Indeed, it has been said that democracy user centred design is the worst form of Government design process except for all those other forms that have been tried from time to time." ‘based’ on a speech by Winston Churchill, 1947Supporters Sponsors Organiser 46

×