Just Married: User Centered Design and Agile

11,460 views

Published on

User Centred Design (UCD) and Agile Development are two of the most exciting and productive Methods to achieve high quality appication both desired by the customers and loved by the users. UCD and Agile Development are though often said to be impossible to combine and that despite their great advantages any attempt would most certainly lead to disaster.
This talk picks up the main points of both methods, shows the key issues and tries to offer a pragmatic approach on how to successfully combine User Centered Design and Agile Development.

Published in: Technology, Education, Design
1 Comment
17 Likes
Statistics
Notes
No Downloads
Views
Total views
11,460
On SlideShare
0
From Embeds
0
Number of Embeds
3,331
Actions
Shares
0
Downloads
146
Comments
1
Likes
17
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Just Married: User Centered Design and Agile

    1. 1. Memi BeltrameJUST MARRIEDUser Centered Design and AgilephpDay Verona May 13th 2011
    2. 2. About meWorking on the web since1997+10 years of phpDegree in cinematographI work for Liip in ZurichWe do Agile WebDevelopment
    3. 3. Bringing UCD and Agile
    4. 4. Bringing UCD and Agile It‘s a process of Change Management
    5. 5. Nobody likes change.
    6. 6. Be prepared:It‘s a long process
    7. 7. Be prepared:You‘ll find a lot of
    8. 8. Be prepared:You‘ll find a lot ofYou‘ll hear a lot of
    9. 9. Be prepared:You‘re in for a ride full ofself-doubt & trust issues
    10. 10. Be prepared:You can‘t do it alone
    11. 11. Be prepared:Every single person hasto be informed, involved
    12. 12. This talk is about what it takes to bring UCD and
    13. 13. User Centered Design?
    14. 14. knowledge base for cutomer support customer thinks the users are lawyers, but in fact they are their secretariesUser = most likely not you
    15. 15. knowledge base for cutomer support customer thinks the users are lawyers, but in fact they are their secretariesUser = most likely not you or me
    16. 16. knowledge base for cutomer support customer thinks the users are lawyers, but in fact they are their secretariesUser = most likely not you or me or the
    17. 17. No User Centered Design without research.
    18. 18. No User Centered Design without research. • Whoare your users?
    19. 19. No User Centered Design without research. • Who are your users? • How do they tick?
    20. 20. No User Centered Design without research. • Who are your users? • How do they tick? • What are their
    21. 21. User Centered:Business objectivesbased on satisfying user-needs
    22. 22. New Paradigm:The return is generatedby offering real value to real users
    23. 23. In contrast to Business Centered: Business objectivesbased on organizational constraints
    24. 24. In contrast to Business Centered: Business objectivesbased on organizational constraints „Our site must show all products
    25. 25. In contrast to Business Centered: Business objectivesbased on organizational constraints „Our site must show all products „We want to have more traffic“
    26. 26. In contrast to Business Centered: Business objectivesbased on organizational constraints „Our site must show all products „We want to have more traffic“ „We want to centralize our
    27. 27. Design?Be careful.
    28. 28. Design?Be careful.Design ≠ Grafic Design
    29. 29. Design?Be careful.Design ≠ Grafic Design- Information design- Workflow design- Functional design- Interaction design
    30. 30. User Centered Design and Development
    31. 31. User Centered Design
    32. 32. UCD is often perceived as a waterfall process
    33. 33. UCD is often perceived as a waterfall process The problem is not the UCD process
    34. 34. UCD is often perceived as a waterfall process The problem is not the UCD process is its The problem integration
    35. 35. The the standardproject structureDesign Implementation
    36. 36. The the standardproject structureDesign Implementation Handover
    37. 37. The the standardproject structure Design Implementation Handover Your implementation may beFAIL agile. This global structure is not.
    38. 38. User Centered Designand Agile have to be one
    39. 39. Design is too importantto leave it to designers.
    40. 40. Design is too importantto leave it to designers. Development is too important
    41. 41. The Agile Approach Design Implementation
    42. 42. The Agile Approach Design Implementation It‘s all about involvement.
    43. 43. Involvement
    44. 44. Aim for:Early developer
    45. 45. InvolvementMake Developers take part in the Ideation Design Implementation
    46. 46. What happens in the ideation process?
    47. 47. User Centered Designfollows the 5S Pattern
    48. 48. The Process
    49. 49. The Process Mission, Focus Groups
    50. 50. The Process Personas, Tasks Mission, Focus Groups
    51. 51. The Process Workflows, Information Architecture Personas, Tasks Mission, Focus Groups
    52. 52. The Process Prototypes, Design Patterns Workflows, Information Architecture Personas, Tasks Mission, Focus Groups
    53. 53. The Process Screens Prototypes, Design Patterns Workflows, Information Architecture Personas, Tasks Mission, Focus Groups
    54. 54. Well executed UCD is an iterative process of
    55. 55. Well executed UCD is an iterative process of Research > Ideate > Test > Adapt
    56. 56. Well executed UCD is an iterative process of Research > Ideate > Test > Adapt Research > Ideate > Test > Adapt
    57. 57. Well executed UCD is an iterative process of Research > Ideate > Test > Research Adapt > Ideate > Test > Research Adapt > Ideate > Test > Adapt
    58. 58. Well executed UCD is an iterative process of Research > Ideate > Test > Research Adapt > Ideate > Test > Research Adapt > Ideate > Test > Research Adapt > Ideate > Test > Adapt
    59. 59. Well executed UCD is an iterative process of Research > Ideate > Test > Research Adapt > Ideate > Test > Research Adapt > Ideate > Test > Research Adapt > Ideate > Test > Research Adapt > Ideate > Test > Adapt
    60. 60. InvolvementHow Developers can contribute during
    61. 61. InvolvementHow Developers can contribute during• Helpfinding good and technically viable solutions
    62. 62. InvolvementHow Developers can contribute during• Helpfinding good and technically viable solutions• Help avoiding conceptual
    63. 63. Benefits of earlydeveloper involvement:
    64. 64. Benefits of earlydeveloper involvement: • Higher identification with the users, costumer & project
    65. 65. Benefits of earlydeveloper involvement: • Higher identification with the users, costumer & project • Less knowledge transfer needed
    66. 66. Benefits of earlydeveloper involvement: • Higher identification with the users, costumer & project • Less knowledge transfer needed • Higher acceptance, because they could help & contribute
    67. 67. Aim for:Constant designer
    68. 68. InvolvementMake Designers take part in the Development Design Implementation
    69. 69. What happens in thedevelopment process?
    70. 70. The translation of aconcept into a product
    71. 71. The Agile Process 24h Daily Meeting Backlog Sprint Sprint Review Sprint Backlog Tasks (n days) Sprint Planning Product Increment Product Backlog
    72. 72. InvolvementHow Designers can contribute during
    73. 73. Involvement How Designers can contribute during• Design reviews
    74. 74. Involvement How Designers can contribute during• Design reviews• Coaching & pair design
    75. 75. Involvement How Designers can contribute during• Design reviews• Coaching & pair design• Defining and verifying design deliverables
    76. 76. Benefits of constantdesigner involvement:
    77. 77. Benefits of constantdesigner involvement:• Quality Assurance of usability & design
    78. 78. Benefits of constantdesigner involvement:• Quality Assurance of usability & design• Developers have a design coach
    79. 79. Benefits of constantdesigner involvement:• Quality Assurance of usability & design• Developers have a design coach• Less refactoring due to bad interface implementation
    80. 80. Important possibilities of early developer involvement
    81. 81. Important possibilities of involvementStrategyHave developers assist thecreation of the projects Missionand establishing the FocusGroups
    82. 82. Important possibilities ofinvolvementScopeHave developers take part in thecreation of the Personas and inthe definition of their mainTasks.
    83. 83. Important possibilities of involvement Structure This is the moment when a lot of prioritization happens: - workflows are defined - the relevant vs the costly are evaluatedLet the developers help make theseevaluations
    84. 84. Important possibilities ofinvolvementStructure This helps Task developers in TaskBusiness Task Task Task Cost
    85. 85. Important possibilities ofinvolvementStructure This helps Task developers in Task • Whatmatters toBusiness Task the user Task Task Cost
    86. 86. Important possibilities ofinvolvementStructure This helps Task developers in Task • Whatmatters toBusiness Task the user Task • What matters to the customer Task Cost
    87. 87. Important possibilities ofinvolvementSkeletonMake developers review
    88. 88. Important possibilities ofinvolvementSkeletonMake developers reviewHave developers sit inprototype-testing sessions
    89. 89. Important possibilities ofinvolvementSurfaceMake developers review visual
    90. 90. Important possibilities ofinvolvementSurfaceMake developers review visualGive developers functionalprototypes
    91. 91. Important possibilities of constant designer involvement
    92. 92. Important possibilities ofDefinition ofinvolvementdoneTake the user experience anduser centered design view intoaccount whenformulating the DoD.
    93. 93. Important possibilities ofinvolvementSprint planningHave a designer review the userstories
    94. 94. Important possibilities ofinvolvementUser StoriesHave designers watch & labeluser stories
    95. 95. Important possibilities ofinvolvementUser StoriesHave designers watch & labeluser storiesThis works for virtual andphysical boards.
    96. 96. Important possibilities ofinvolvementDailiesHave designers take part
    97. 97. Important possibilities ofinvolvementDailiesHave designers take partThey will know what is going onand
    98. 98. Important possibilities ofinvolvementReviewing WorkHave designers review the workdone
    99. 99. Important possibilities ofinvolvementReviewing WorkHave designers review the workdoneHere is where labeling becomesimportant and allows designers
    100. 100. Important possibilities ofinvolvementUsability TestingHave designers set up usabilitytests
    101. 101. Empowerment
    102. 102. AgileCollective Code Ownership
    103. 103. UCD & AgileCollective Design Ownership
    104. 104. Empower developers to understand design
    105. 105. Empower developers tomake responsible design decisions
    106. 106. Have design principles
    107. 107. Design principles for
    108. 108. Design principles for1.Be consistent
    109. 109. Design principles for1.Be consistent2.Give humanoid feedback
    110. 110. Design principles for1.Be consistent2.Give humanoid feedback3.Minimize distractions
    111. 111. Design principles for1.Be consistent2.Give humanoid feedback3.Minimize distractions4.Observe alignments & orientations
    112. 112. Design principles for1.Be consistent2.Give humanoid feedback3.Minimize distractions4.Observe alignments & orientations5.Group elements according to function
    113. 113. Design principles for1.Be consistent2.Give humanoid feedback3.Minimize distractions4.Observe alignments & orientations5.Group elements according to function6.Use color and form to convey meaning
    114. 114. Design principles for1.Be consistent2.Give humanoid feedback3.Minimize distractions4.Observe alignments & orientations5.Group elements according to function6.Use color and form to convey meaning7.Offer undo
    115. 115. Design principles for1.Be consistent2.Give humanoid feedback3.Minimize distractions4.Observe alignments & orientations5.Group elements according to function6.Use color and form to convey meaning7.Offer undo8.Details are not just details: They make the product, so honor
    116. 116. Design principles for1.Be consistent ma youke2.Give humanoid feedback ow r n!3.Minimize distractions4.Observe alignments & orientations5.Group elements according to function6.Use color and form to convey meaning7.Offer undo8.Details are not just details: They make the product, so honor
    117. 117. Usability Testing
    118. 118. Very uncomfortable topic.
    119. 119. Developer concern #1: The race condition
    120. 120. Usability testing racing
    121. 121. Usability testing racing Tests for
    122. 122. Usability testing racing Tests for done during sprint 2
    123. 123. Usability testing racing Tests for done during sprint 2 have effect on sprint 3
    124. 124. BUT:
    125. 125. BUT:• Features are almost never evolve linearly
    126. 126. BUT:• Features are almost never evolve linearly• Topics of sprints differ from one sprint to another
    127. 127. BUT:• Features are almost never evolve linearly• Topics of sprints differ from one sprint to another• Usabilty Testing during the same
    128. 128. A lot of excuses.
    129. 129. „It‘s not in the budget“
    130. 130. „It‘s not in the budget“ It costs virtually nothing
    131. 131. „It‘s not in the budget“ It costs virtually nothing - Hallway/guerilla testing
    132. 132. „It‘s not in the budget“ It costs virtually nothing - Hallway/guerilla testing - Remote testing
    133. 133. „Didn‘t you test the prototype“
    134. 134. „Didn‘t you test the prototype“Would you drive a carthat relies onprototype testing?
    135. 135. „We don‘t want others tosee what we are working
    136. 136. „We don‘t want others tosee what we are working You don‘t want others to be excited about your new product?
    137. 137. „We know it works.“
    138. 138. „We know it works.“ You never know until you know.
    139. 139. Inform, Involve &
    140. 140. Inform- Who- What- Why- Coach
    141. 141. Inform Involve- Who - Meet up- What - Assign- Why tasks- Coach - Empower
    142. 142. Inform Involve Motivat- Who - Meet up- What - Assign e - Give- Why tasks Control- Coach - Empower
    143. 143. Thanks! I‘m @bratwurstkometThis talk: liip.to/UCDagileliip.ch * memibeltrame.ch

    ×