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.

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. 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.
,
This document and it’s content is Copyright ©2012 [Tom Stewart] and UCD UK Limited.
Supporters Sponsors Organiser
1

2. If UCD is so great, why are
more systems not perfect?
Supporters Sponsors Organiser
2

3. Actually, IT projects have a
long history of failure
Supporters Sponsors Organiser
3

4. Typical reasons for failure
1. The technology didn’t work
Supporters Sponsors Organiser
4

5. Me = Mistake edition
Supporters Sponsors Organiser
5

6. Typical reasons for failure
1. The technology didn’t work
2. Unrealistic ambitions
Supporters Sponsors Organiser
6

7. • Other thoughts
“the new system will let
everyone be customer
facing so customer
service will be great!”
Supporters Sponsors Organiser
7

8. Typical reasons for failure
1. The technology didn’t work
2. Unrealistic ambitions
3. Rejected by users
Supporters Sponsors Organiser
8

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. Supporters Sponsors Organiser
10
10

11. UCD is the solution
but not everyone gets it
(Google user centred design)
Supporters Sponsors Organiser
11

12. Supporters Sponsors Organiser
12

13. Supporters Sponsors Organiser
13

14. But most do (Google images for User Centre Design)
Supporters Sponsors Organiser
14

15. Supporters Sponsors Organiser
15

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 conformance
Supporters Sponsors Organiser
16

17. Warning!
Photos from this point are NOT
from the actual project or client
Supporters Sponsors Organiser
17

18. Plan the human-centred
design process
Supporters Sponsors Organiser
18

19. Plan the human-centred design process
• What can go wrong?
Supporters Sponsors Organiser
19

20. Supporters Sponsors Organiser
20

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 change
Supporters Sponsors Organiser
21

22. Understand and specify
the context of use
Supporters Sponsors Organiser
22

23. Understand and specify the context of use
• What can go wrong?
Supporters Sponsors Organiser
23

24. Supporters Sponsors Organiser
24

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 possible
Supporters Sponsors Organiser
25

26. Specify the user
requirements
Supporters Sponsors Organiser
26

27. Specify the user requirements
• What can go wrong?
Supporters Sponsors Organiser
27

28. Supporters Sponsors Organiser
28

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
characteristics
Supporters Sponsors Organiser
29

30. Produce design solutions
to meet user requirements
Supporters Sponsors Organiser
30

31. Produce design solutions to meet user
requirements
• What can go wrong?
Supporters Sponsors Organiser
31

32. Supporters Sponsors Organiser
32

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
evaluation
Supporters Sponsors Organiser
33

34. Supporters Sponsors Organiser
34

35. Evaluate the designs against the
requirements
• What can go wrong?
– Not test at all
Supporters Sponsors Organiser
35

36. Supporters Sponsors Organiser
36

37. Supporters Sponsors Organiser
37

38. Supporters Sponsors Organiser
38

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 tasks
Supporters Sponsors Organiser
39

40. Supporters Sponsors Organiser
40

41. Iterate where appropriate
• What can go wrong?
Supporters Sponsors Organiser
41

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.uk
Supporters Sponsors Organiser
42

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 governance
Supporters Sponsors Organiser
43

44. Supporters Sponsors Organiser
44
44

45. Tom Stewart
tom@system-concepts.com
020 7240 3388
www.system-concepts.com
Supporters Sponsors Organiser
45

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, 1947
Supporters Sponsors Organiser
46