Contenu connexe Similaire à Big picture design without Big Design Up Front (Agile Roots 2010) (20) Big picture design without Big Design Up Front (Agile Roots 2010)1. Big picture design
without
Big Design Up Front
Agile Roots 2010
Desirée Sy
Media + Entertainment
2. Big picture design
without
Big Design Up Front
Agile Roots 2010
Desirée Sy
Media + Entertainment
4. flexible tunnel vision
just enough sprint tools
small increments
quality faster to wrong
timeboxed
product
iterative
change-friendly
t collaborative
react instead of
faster to product reflect
continuous treadmill
© 2010 Desirée Sy, All rights reserved
5. missing ingredient?
context
UX methods can provide this
© 2010 Desirée Sy, All rights reserved
6. Big picture design
without
Big Design Up Front
Agile Roots 2010
Desirée Sy
Media + Entertainment
7. Ye olde UX
• Often front-loaded
• Data isn’t refreshed during project
• Documents have detail, but often no insight
© 2010 Desirée Sy, All rights reserved
8. a.k.a.
Big Design Up Front
© 2010 Desirée Sy, All rights reserved
9. a.k.a.
Big Design Up Front
© 2010 Desirée Sy, All rights reserved
10. a.k.a.
UX methods “but”
© 2010 Desirée Sy, All rights reserved
11. Big picture design
without
Big Design Up Front
Agile Roots 2010
Desirée Sy
Media + Entertainment
12. • “Adapting Usability Investigations for Agile
User-Centered Design” JUS, May 2007
• http://tiny.cc/agileUCD
© 2010 Desirée Sy, All rights reserved
14. dsy.agileUX@gmail.com
Twitter: @DesireeSy
(tweeting all links in this presentation)
© 2010 Desirée Sy, All rights reserved
16. can’t code
(no... really!)
© 2010 Desirée Sy, All rights reserved
18. ethnography
+
behaviour prototyping
+
UX validation
© 2010 Desirée Sy, All rights reserved
19. user research
+
‘mini-fi’* prototypes
+
usability testing
© 2010 Desirée Sy, All rights reserved
*‘minimum-fidelity’
22. Usually, I speak here....
... So if I use UX jargon, please ask me right away
© 2010 Desirée Sy, All rights reserved
24. I
agile UX
© 2010 Desirée Sy, All rights reserved
25. Agile UX: the good
• Narrows the gap • Contextual inquiry &
between finding and usability testing on
fixing issues actual product
• Less “design drift” • Satisfying to see designs
in real use
• User data has effect on
current release • Face-to-face is better
than “over the wall”
• Most important features
are done first • Enables requirements
iteration
© 2010 Desirée Sy, All rights reserved
26. Agile UX: the good
• Narrows the gap • Contextual inquiry &
between finding and usability testing on
fixing issues actual product
• Less “design drift” • Satisfying to see designs
in real use
• User data has effect on
current release • Face-to-face is better
than “over the wall”
• Most important features
are done first • Enables requirements
iteration
© 2010 Desirée Sy, All rights reserved
28. My agile UX
background
Before we were Autodesk...
Alias
• products and users
• UX team
• agile team
© 2010 Desirée Sy, All rights reserved
29. • Commercial,
shrinkwrapped software
• 3D graphics,
highly interactive
• Non-standard UI
• Users:
Creative professionals
• Generative, open-ended
tasks
© 2010 Desirée Sy, All rights reserved
31. UX team
• 1 manager
• 4 interaction designers (generalists)
• 2 graphic designers
• UX developer (student intern)
© 2010 Desirée Sy, All rights reserved
33. agile team
• 1 product manager
• 1 dev lead
• 2.5 developers (the 0.5 is the dev lead)
• 1.5 interaction designers
• 1 UX developer (student intern)
• 1 QA
• 1 documentation
• 1 graphic designer
© 2010 Desirée Sy, All rights reserved
35. product owner
=
product manager
+
dev lead
+
interaction designer
© 2010 Desirée Sy, All rights reserved
36. product owner
=
every team member
© 2010 Desirée Sy, All rights reserved
37. Sprint Zero
+
Iteration Planning
© 2010 Desirée Sy, All rights reserved
38. Stay tuned for...
agile UX planning
(Agile 2010)
© 2010 Desirée Sy, All rights reserved
39. Big picture of the talk
• The problem + the framework
• Agile + the big picture
• Design chunking
• Mini-releases
• Putting it together
© 2010 Desirée Sy, All rights reserved
41. from
Jeff Patton’s keynote
© 2010 Desirée Sy, All rights reserved
42. output outcome
we build this we want this
©
2009
Jeff
Pa+on,
all
rights
reserved,
www.AgileProductDesign.com 42
43. solving problems
NOT
building solutions
© 2010 Desirée Sy, All rights reserved
44. Learning about the
world, imagining
solutions, evaluating
working solutions in
the world
Building high-
quality working
software
Pay equal attention to “discovery”
practice and “delivery” practice
45. discovery:
problem definition
© 2010 Desirée Sy, All rights reserved
46. some problems take
>2 weeks to solve
(but they can still be solved in 2-week increments)
© 2010 Desirée Sy, All rights reserved
47. output outcome
we build this we want this
©
2009
Jeff
Pa+on,
all
rights
reserved,
www.AgileProductDesign.com 47
48. Outcomes ARE
measurable
© 2010 Desirée Sy, All rights reserved
52. flexible tunnel vision
just enough sprint tools
small increments
quality faster to wrong
timeboxed
product
iterative
change-friendly
t collaborative
react instead of
faster to product reflect
continuous treadmill
© 2010 Desirée Sy, All rights reserved
54. big picture symptoms
• Incomplete user workflows
• Feature creep (but in smaller units)
• “Value” thresholds aren’t defined
• Can’t cope with new feedback
• Don’t know what “done” means
© 2010 Desirée Sy, All rights reserved
55. agile big picture
• Big = “high-level” NOT “detailed”
• Not just up front
• Capable of continuous improvement
• Shared + visible
• Just-in-time detail and documentation
© 2010 Desirée Sy, All rights reserved
58. Goals
• Applied to backlog, let you:
• discard
• sort
• rank
• Focus UX investigations
• As requirements, they can define “done”
© 2010 Desirée Sy, All rights reserved
60. Example
• SketchBook Pro
• Tablet PC + Wacom tablets
© 2010 Desirée Sy, All rights reserved
62. Before breaking
designs into iterations...
© 2010 Desirée Sy, All rights reserved
63. ... think about
Product and Release
goals
© 2010 Desirée Sy, All rights reserved
64. Product goals
Product vision
• Who it’s for (and not)
• What it is (and isn’t)
Design/Engineering/Business
Principles
• Define product characteristics to drive
decisions
© 2010 Desirée Sy, All rights reserved
65. In action...
Product vision
• For creative professionals
• Sketching: responsive, quick, loose
• Drop: Image processing
• Rank: Brushes, make it faster,
promote flow
© 2010 Desirée Sy, All rights reserved
66. In action...
Design Principles
• Elegant simplicity, Stylus-friendly,
Self revealing, Maximum work area
• Drop/Rank: Don’t add because we can
• Design “Done”: All features must have
access without a keyboard
• Investigate: Discoverability, Clutter
© 2010 Desirée Sy, All rights reserved
67. In action...
Design and Engineering Principles
• Self revealing/Optimize (fast + small code)
• Design had large set of icons, but that
added to code weight. We redesigned.
Business Principles
• Enter broader market
• Design and code for trial version
© 2010 Desirée Sy, All rights reserved
68. In action...
TiVo Design Principle
• It’s entertainment, stupid
• “Lean back, not forward”
• Drop/rank: No keyboard entry
- “How (Not) to Destroy a Great
User Experience” UPA 2006
Rich Fulcher, Rachel Garb, Alex Liston, Donna Slote
© 2010 Desirée Sy, All rights reserved
69. In action...
Apple iPhone
iOS 1.0 and 2.0
• “Done”:
Cut + Paste
© 2010 Desirée Sy, All rights reserved
70. When?
• Good projects already have them
(regardless of SW methodology)
• Before Sprint Zero
• At the time project is ‘green-lit’
• OR if a product is being ‘reset’
• For small products, could be Sprint Zero
of v1 release
© 2010 Desirée Sy, All rights reserved
71. Release goals
• Pragmatic distillation of business goals
• Although business-focused, needs to be
input from development and design
• Aligns the team trajectory
• Guidance for course corrections
• Not the backlog (or a subset of it)
© 2010 Desirée Sy, All rights reserved
72. In action
• SketchBook Pro v2
• “Remove barriers to purchase from trial”
• Research: Survey. Focused the ‘who’
• Drop/Rank: 200 > 25 > 10 (top 5)
• Drop: Saving colours
• Consensus: Dropped Rotate Canvas
© 2010 Desirée Sy, All rights reserved
73. In action
• Rare but powerful: Redefine the release
• SketchBook Pro v1.1
• “Mac OS X port”
• Reset the alignment
• Promote: Add keyboard shortcuts
© 2010 Desirée Sy, All rights reserved
74. When and how?
• Sprint Zero of upcoming release
• How many iterations per release?
• NO designs!
• Just enough detail to share direction
• Define problems, not solutions
© 2010 Desirée Sy, All rights reserved
76. Once you have the
big picture...
© 2010 Desirée Sy, All rights reserved
77. ... set design goals
at the Capability level
© 2010 Desirée Sy, All rights reserved
78. Capability/Sprint goals
• Articulate problems to solve for a
workflow/user story
• Carry forward as sprint goals
• Defined through chunked research
• Used to chunk designs
• Used to chunk mini-releases
• Used to define “done”
© 2010 Desirée Sy, All rights reserved
79. In action
Brush Resize
© 2010 Desirée Sy, All rights reserved
80. In action
Brush Resize
• First 5 minutes: learn without documents
• Resizing without Brush Editor
• One control for size, not 2-5
• Keep focus in-canvas
• Fewer dialogues (covering the work)
• Stylus only (no keyboard)
© 2010 Desirée Sy, All rights reserved
81. Tear and build
• Design a capability over >1 cycle.
• Break a design into chunks.
• Mix and match chunks in investigations:
mini-research, usability test and iterate on
mini-prototype.
• Look at the design at the Capability level.
Now break it into mini-specifications, to be
coded over >1 sprint.
© 2010 Desirée Sy, All rights reserved
83. (To repeat:) Stay tuned for...
agile UX planning
(Agile 2010)
© 2010 Desirée Sy, All rights reserved
84. Caveats
• You’ll need to establish a buffer first
• Even with the buffer, you’ll still need to
write mini-specs for the next cycle
• It is Big Design if
>1 = too many sprints
© 2010 Desirée Sy, All rights reserved
85. Design chunking
• Look at the list of capability goals
• What can you investigate over next few
sprints?
• Layer sprint-sized investigations and
prototypes to meet all required goals
© 2010 Desirée Sy, All rights reserved
86. In action
Brush Resize design goals:
• First 5 minutes: learn without documents
• Resizing without Brush Editor
• One control for size, not 2-5
• Keep focus in-canvas
• Fewer dialogues (covering the work)
• Stylus only (no keyboard)
© 2010 Desirée Sy, All rights reserved
87. In action
Brush Resize design chunks:
• Brush Resize with hotkey
• Brush Resize with stylus (interaction)
• Brush Resize with stylus (look)
• “Workflow” prototype
© 2010 Desirée Sy, All rights reserved
88. In action
Brush Resize with hotkey:
Disposable code prototypes
• Resizing without
Brush Editor
• One control for size,
not 2-5
• Keep focus in-canvas
• Fewer dialogues
(covering the work)
© 2010 Desirée Sy, All rights reserved
89. In action
• Brush Resize with stylus (interaction):
Whiteboard prototype
• Stylus only (no keyboard)
© 2010 Desirée Sy, All rights reserved
90. In action
• Brush Resize with stylus
(look):
Graphic designs
• Stylus only (no
keyboard)
© 2010 Desirée Sy, All rights reserved
91. In action
• Workflow prototype:
Disposable coded prototype
• First 5 minutes: learn without documents
• Combined with 2 other user stories:
Brush Palette and Custom Brushes
© 2010 Desirée Sy, All rights reserved
93. ‘Small Design’
User Stories
• Look at the list of the Capability goals
• Which users will see the next cuts + when?
• Layer the implementation to deliver on key
Capability/Release goals in every sprint
• Think worst-case scenario: is each
incremental build shippable?
© 2010 Desirée Sy, All rights reserved
94. In action
Brush Resize implementation:
• Per-brush Property Editor, with Size control
• Brush Resize widget
© 2010 Desirée Sy, All rights reserved
95. In action
Per-brush Properties dialog
with Size control:
• Overlap with Custom Brushes
• First 5 minutes: learn without
documents
• Resizing without Brush Editor
• One control for size, not 2-5
• Stylus only (no keyboard)
© 2010 Desirée Sy, All rights reserved
96. In action
Brush Resize widget:
• Keep focus in-canvas
• Fewer dialogues (covering the
work)
© 2010 Desirée Sy, All rights reserved
97. Usability
acceptance criteria
• Sit with developers as they are turning the
user stories into hard estimates.
• Make sure you understand how each of
their pieces fits in the capability.
• Sit with testers to add code-testable
usability criteria if needed.
© 2010 Desirée Sy, All rights reserved
98. In action
Heads up display
• Fixed decimal point
© 2010 Desirée Sy, All rights reserved
100. “Big picture” design
• product + release goals = big picture
• capability goals come from this
• multi-sprint designs become design chunks
• design is “done” when design goals are met
• write Small Design user stories
• UX requirements: on unit with estimates
• check incoming reqs against all goals
© 2010 Desirée Sy, All rights reserved
101. expanding
agile UX activities
© 2010 Desirée Sy, All rights reserved
102. • Create prototypes
• Rapid usability testing
• Identify and fix problems
• Define mini-specifications
• Check implementation
© 2010 Desirée Sy, All rights reserved
103. Machete
Clear obstacles
(faster and better)
© 2010 Desirée Sy, All rights reserved
104. Compass
Check direction
(refine intent)
© 2010 Desirée Sy, All rights reserved
105. • Rapid longitudinal user
research
• Set design goals
Help to:
• Group and prioritize backlog
• Plan product exposure
• Recognize “done”
© 2010 Desirée Sy, All rights reserved
107. Thanks.
dsy.agileUX@gmail.com
@DesireeSy
© 2010 Desirée Sy, All rights reserved