This document provides an introduction to user-centric design (UCD) and interaction design (IxD) principles for building software. It discusses how UCD tools like personas, goals, and interaction loops can help design coherent experiences and increase agility, sanity and quality. While earlier software was system-centric, the focus is now on designing intuitive experiences through iterative collaboration using UCD and pairing it with Agile development methods.

1. UCD
introduction
A basic intro to user-centric design, as it relates to building software.

2. great software
at high speed
(the goal)

3. play book
Successful teams know what plays they’re running, why, and how. The principles of UCD (and IxD) help you setup
plays.

4. topics

5. topics
context
define
q&a

6. source:

7. source:
alan cooper
Godfather in Silicon Valley. OG.

8. indelible
Alan Cooper’s ideas have left an indelible mark on how software design’s approached.

9. dancing bear
Imagine one end of a town square, where a man bring’s in a bear, dressed in a tutu and clown hat, and gets the
bear to dance. People’s attention is captivated that is even possible. At the other end of the square as a world class
dancer pirouettes and piqué’s, few notice. As time passes, the novelty of the dancing bear wear’s off, and the
absence of technique and refinement becomes obvious. The human dancer stands out with consistency, emotion,
technique. We must beware of “dancing bear” technology products that distract with novelty, but have little long-
term value.

10. Example products, bleeding edge, don’t produce quality output, but stood out because, “holy shit this works!”.

13. context
In earlier eras of software development, applications were “system centric”. The CPU, memory, and graphics
abilities were limited and therefore defined what could be done. The physical size of a punchcard determined how
much information could be carried. These limitations have evaporated, increasing flexibility, but requiring more
design guidance to produce coherent products.

14. software quality
What the computer could do used to define what software did.

15. software quality
over time
Over time, technical capability has improved, and so has collective knowledge about building effective & intuitive
applications.

16. daily use
Daily use software is especially demanding of an over-arching approach to maintain coherence, and intuitive
experiences.

17. improvement?
How many have observed improvements in software in the past 10-20 years? Clearly, the proliferation of effective,
intuitive software has increased.

18. dog’s breakfast?
Still, we see applications that are mash-up of too much noise and incoherent navigation.

19. tolerance for bad design
impatience / friction
Gmail, iPhone, Amazon, TurboTax, Pinterest have raised the bar. As builders, we must elevate our craft. Tolerance
for friction and incoherence has diminished.

20. our context
What’s expected of software builders?

21. an engineer should:
code
test
do the interface
prototype
manage
scope
spec
document
communicate
be fast
pontificate
know everything
Many, many things are expected (concurrently).

22. TOO MUCH
(overload)

23. TOO MUCH
not fun
Over time, this results in reduced problem solving capability, job satisfaction, and output quality.

24. TOO MUCH
inefficient
Poor use of resources.

25. TOO MUCH
incomplete
Key parts of build and support get missed.

26. – scramble –
– too much –
– don’t support –
– crap –

27. – scramble –
– too much –
– don’t support –
– crap –
( repeat )
Engineering organizations get stuck in loops.

28. It becomes a continuous scramble to maintain systems.

29. break the cycle

30. shake shit up

31. get out of our comfort zone
This requires revisiting the same thing 3, 4, 5 times. Being brutally honest. Keeping egos in check. Nurturing the
best ideas.

32. what’s UCD?
What is UCD and can it help ameliorate these issues, and increase quality?

33. 3 powerful tools

34. personas
goals
interactions

35. personas

36. personas
(not actual people)
If you build based on actual person, given enough time, then that person will inevitably dictate features that are
specific to them. Examples; applications become entirely mouse-driven, keyboard centric, or focused on granular
data to the extent that they bury the key insights they’re supposed to surface.

37. goals

38. tasks aren’t goals
A task is to secure-copy modified image slices to the server. A goal is to quickly replace content with an audit trail.

39. specificity
Goals need to be interrogated, refined, polished; not taken at face value in one discussion. Missed test cases,
incompatible features, and unanticipated risks come from a lack of specificity.

40. personal
Goals can be divided into 4 types. All types need to be considered. Example personal goals; 1. Don’t feel stupid
while using application. 2. Commensurate effort: Help user feel like amount of effort makes sense for desired
outcome.

41. professional
Examples: Launch quicker enough to capture market-share, beat competition.

42. practical
Accomplish the nuts and bolts. Example; accurately record orders. Create numerical model of business.

43. false
Some goals bleed into the realm of being a “false goal”. Example: Reducing processor use is a false goal if it’s
invisible to users, and not anticipated to become visible (as more people use the application). These are means to
an end, not ends in themselves.

44. clarity of purpose
If clarity of purpose is lacking, the underlying goals need more attention.

45. IxD
Personas lead to goals. Goals lead to…an interaction with a piece of software. As a result, the discipline is called
Interaction Design > IxD.

46. how we experience software
Interactions reflect how we experience software.

47. how we experience software
loops
With each sitting, we go thru a loop.

48. IxD
Designing and optimizing coherent loops is the focus of IxD.

49. user centric
What does it mean to be user “centric”.

50. not user driven
Not to be confused with user “driven”.

51. not user driven
Many software teams find themselves stuck in patterns that look something like this. End-users are given override
authority to put anything into an application.

52. not user driven
This shift is subtle at first, but takes over, and then drives the entire endeavor.

53. not user driven
not user interface
elements
This leads to very granular interface and business element determination by end-users.

54. not user driven
not user features
timing
This results in an unmanaged flow of features, and expectations about time requirements.

55. not user driven
not user features
timing
FML!
Maintaining a coherent experience, reliable code, clean data becomes impossible.

56. riding the tiger
This is called…riding the tiger.

57. diner that runs the kitchen
Another analogy…

58. where can we take this?
How can this be put in place?

59. what do we have?
Take stock

60. what do we have?
personas
goals

61. ask the right questions
Don’t assume we ask the right questions in the 1st, 2nd pass.

62. build quickly, without
making silly mistakes
Let the method guide us, not ride us.

63. can’t be done by one
By definition, is a collaborative endeavor.

64. can’t be done by one person
skill set
group
layer
This will fail if key pieces don’t get skin in the game.

65. define our environment
We know how many products, but how many domains do we have? How many applications? How many platforms
should this turn into?

66. define our environmentneeds

67. get out of our comfort zone
We’re used to working in the business, so working on the business will feel uncomfortable at first.

68. evolve how we do things

69. designing an entire experience
from sit-down to stand-up
Our overall goal is to design the ongoing software experiences that we require.

70. best in breed examples:
Amazon check-out
Gmail read/reply
Pinterest browse
JIRA list sorting
There’s good info out there! Don’t reinvent the wheel.

71. good artists copy

72. good artists copy
great artists steal

73. repeat:

74. user centric

75. personas > goals > interactions

76. coherence
Maintain coherence.

77. agility
Increase agility.

78. sanity
Improve sanity.

79. designed, not
incidental software
Good software doesn’t come out of nowhere, or happen by accident.

80. If Interaction Design (IxD) represents the yin of our ideation, then what about the yang, our production method??
How can we complete the picture?

81. Agile
Agile is the other half of this story. The method we can use to turn the designs into reality.
!
We can talk about that…

82. ...next time

83. –ernest hemmingway
“write drunk, edit sober.”
Parting words of wisdom…

84. q&a