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.

1. Memi Beltrame
JUST MARRIED
User Centered Design and Agile
phpDay Verona May 13th 2011

2. About me
Working on the web since 1997
+10 years of php
Degree in cinematography
Film & photo enthusiast
I work for Liip in Zurich
We do Agile Web Development
I run the UX Team

3. Bringing UCD and Agile together.
It‘s a process of
Change Management

4. Nobody likes change.

5. Be prepared:
It‘s a long process

6. Be prepared:
You‘ll find a lot of obstacles
You‘ll hear a lot of excuses

7. Be prepared:
You‘re in for a ride full of
self-doubt & trust issues

8. Be prepared:
You can‘t do it alone

9. Be prepared:
Every single person has to be
informed, involved & motivated

10. This talk is about what it takes to
bring UCD and Agile together

11. User Centered Design?

12. User = most likely not you
or me
or the customer

13. No User Centered Design
without research.
• Who are your users?
• How do they tick?
• What are their tasks?

14. User Centered:
Business objectives based on
satisfying user-needs

15. New Paradigm:
The return is generated by
offering real value to real users

16. In contrast to
Business Centered:
Business objectives based on
organizational constraints
„Our site must show all products by type“
„We want to have more traffic“
„We want to centralize our websites“

17. Design?
Be careful.
Design ≠ Grafic Design
- Information design
- Workflow design
- Functional design
- Interaction design
- Grafic design

18. User Centered Design and
Development

19. User Centered Design

20. UCD is often perceived as a
waterfall process
The problem is not the UCD process
The problem is its integration

21. The the standard
project structure
Design Implementation
Handover
FAIL
Your implementation may be agile.
This global structure is not.

22. User Centered Design and Agile
have to be one process.

23. Design is too important
to leave it to designers.
Development is too important
to leave it to developers.

24. The Agile Approach
Design Implementation
It‘s all about involvement.

25. Involvement

26. Aim for:
Early developer involvement

27. Involvement
Make Developers take part in the
Ideation Process
Design Implementation

28. What happens in the
ideation process?

29. User Centered Design
follows the 5S Pattern

30. The Process
Screens
Prototypes,
Design Patterns
Workflows,
Information Architecture
Personas, Tasks
Mission, Focus Groups

31. Well executed UCD is an iterative
process of refinement
Research > Ideate > Test > Adapt
Research > Ideate > Test > Adapt
Research > Ideate > Test > Adapt
Research > Ideate > Test > Adapt
Research > Ideate > Test > Adapt

32. Involvement
How Developers can contribute
during ideation
• Help finding good and technically viable
solutions
• Help avoiding conceptual failures due to
technical limitations

33. Benefits of early developer
involvement:
• Higher identification with the users,
costumer & project
• Less knowledge transfer needed
• Higher acceptance, because they could
help & contribute

34. Aim for:
Constant designer involvement

35. Involvement
Make Designers take part in the
Development Process
Design Implementation

36. What happens in the
development process?

37. The translation of a
concept into a product

38. The Agile
Process 24h
Daily
Meeting
Backlog Sprint Sprint
Review
Sprint Backlog Tasks (n days)
Sprint
Planning
Product Increment
Product Backlog

39. Involvement
How Designers can contribute
during implementation
• Design reviews
• Coaching & pair design
• Defining and verifying design deliverables

40. Benefits of constant designer
involvement:
• Quality Assurance of usability & design
• Developers have a design coach
• Less refactoring due to bad interface
implementation

41. Important possibilities of
early developer involvement

42. Important possibilities of involvement
Strategy
Have developers assist the creation of
the projects Mission and establishing
the Focus Groups

43. Important possibilities of involvement
Scope
Have developers take part in the creation
of the Personas and in the definition of
their main Tasks.

44. Important possibilities of involvement
Structure
This is the moment when a lot of
prioritization happens:
- workflows are defined
- the relevant vs the costly are evaluated
Let the developers help make these evaluations

45. Important possibilities of involvement
Structure
This helps developers in
Task
getting a feeling for:
Task
Business • What matters to
relevance Task the user
Task • What matters to
the customer
Task
Cost

46. Important possibilities of involvement
Skeleton
Make developers review prototypes
Have developers sit in
prototype-testing sessions

47. Important possibilities of involvement
Surface
Make developers review visual designs
Give developers functional prototypes
of complex interactions.

48. Important possibilities of
constant designer involvement

49. Important possibilities of involvement
Definition of done
Take the user experience and user
centered design view into account when
formulating the DoD.

50. Important possibilities of involvement
Sprint planning
Have a designer review the user stories

51. Important possibilities of involvement
User Stories
Have designers watch & label user stories
This works for virtual and physical boards.

52. Important possibilities of involvement
Dailies
Have designers take part
They will know what is going on and
they can help with impediments

53. Important possibilities of involvement
Reviewing Work
Have designers review the work done
Here is where labeling becomes important
and allows designers to be autonomous.

54. Important possibilities of involvement
Usability Testing
Have designers set up usability tests

55. Empowerment

56. Agile
Collective Code Ownership

57. UCD & Agile
Collective Design Ownership

58. Empower developers to
understand design decisions

59. Empower developers to make
responsible design decisions

60. Have design principles

61. Design principles for developers:
1. Be consistent mak
you e
2. Give humanoid feedback own r
!
3. Minimize distractions
4. Observe alignments & orientations
5. Group elements according to function
6. Use color and form to convey meaning
7. Offer undo
8. Details are not just details:
They make the product, so honor them.

62. Usability Testing

63. Very uncomfortable topic.

64. Developer concern #1:
The race condition

65. Usability testing racing condition
Tests for sprint 1
done during sprint 2
have effect on sprint 3

66. BUT:
• Features are almost never evolve linearly
• Topics of sprints differ from one sprint to
another
• Usabilty Testing during the same sprint
creates unneccessary stress

67. A lot of excuses.

68. „It‘s not in the budget“
It costs virtually nothing
- Hallway/guerilla testing
- Remote testing

69. „Didn‘t you test the prototype“
Would you drive a car that
relies on prototype testing?

70. „We don‘t want others to see
what we are working on“
You don‘t want others to
be excited about your
new product?

71. „We know it works.“
You never know
until you know.

72. Inform, Involve & Motivate

73. Inform Involve Motivate
- Who - Meet up - Give Control
- What - Assign tasks - Be Positive
- Why - Empower - Celebrate
- Coach - Network - Show respect

74. Thanks!
I‘m @bratwurstkomet
This talk: liip.to/UCDagile
liip.ch * memibeltrame.ch