we’re doing what, when? incorporating ux design into agile
TRANSCRIPT
–Jakob Nielsen Nielsen Norman Group
“Agile's biggest threat to system quality stems from the fact that it's a method proposed by programmers and mainly addresses the implementation side of system development.”
Some Terminology
• Iteration: An idea that the designer captures in a drawing or using a prototyping tool. Created quickly, e.g. in an hour.
• UI specification: A document or annotated prototype that indicates how the product should look or behave. Not evil.
The “textbook” approach
• The entire team works on the same set of user stories at the same time
• There is little or no upfront design time before development sprints begin
–Kristen Johansen Senior Manager, User Experience Citrix
“When the UX wasn’t worked out ahead of time, you’d see arguments in the middle of the sprint with accusations from the developers that the scope was being expanded because their idea of how the feature was going to work when they estimated it in sprint planning was different than the designer’s.”
Sprint Zero: Rough Design Up-FrontStaggered Sprints: Designer Works 1-2
Iterations Ahead
Alternative: Parallel track for design work
Week 1 Week 2 Week 3
Design walkthrough
#1 #3 #2
Design ready to
implement
Conversations throughout the process
Week 2 Week 3
Design walkthrough
#1 #3 #2
Design ready to
implement
Week 1Week 1
Conversations throughout the process
–Dave Malouf
“What is the poster child of software and product design success today?… NOT done in Agile. Could never have succeeded as Agile… We need THOUGHT and Vision and Innovation. NOT Expediency.”
Consider organizing sprints by fidelity
Early sprints = lower fidelity Later sprints = higher fidelity
How to survive low-fidelity designQA
• Automate testing
• Focus early testing on business logic, scalability, performance - not superficial UI
Documentation
• Focus early on planning, outlining, and indexing
• Omit unnecessary detail
• Minimize repetition
• Use screenshots sparingly
Development
• Design code to be refactored
• Separate language strings
• Use low-fidelity placeholders for artwork
“Three users every Thursday”
Test whatever is ready each
week
Usability test & ask research
questions
Sit down with one user at a
time for 30 - 60 minutes
Sprint n
Design walkthrough
#1
Design ready to
implement
Sprint n +1
Code complete
and tested
Best time for usability testing
Second-best time for usability testing
What makes sense to change?• Issues from user feedback
• Consistency issues
• Spec housekeeping: typos, etc.
• Under-specified edge cases
• Text strings
• Logic for disabling controls
• Progress feedback
• Defaults
• Feasibility problems
CC BY 2.0, Kurtis Garbutt
How should we decide what to change?
• Who should make the call on whether to accept a proposed design change?
• How do you choose between change requests and bug fixes?
CC BY-NC-ND 2.0, Joel Kiraly
A managed change scenario
1. Initial design process
2. Change request is made
3. Change Control Board reviews the change
4. Designer communicates the change
CC BY-ND 2.0, Daniele Vico
Step 2: Change request is made
1. Person requesting the change brings it up with the designer.
2. Proposer and designer pre-screen the request.
3. Designer describes the change outside of the official spec and sends it in an email or ticket to the Change Control Board
“Nobody is using the Snooze feature because the snooze option is off by default”
Highlighting Changes
- r before & after screenshots, to show what should change, relative to the last build.
Illustration
Highlight changes with red
Step 3: Change is reviewedWhere:
• Silence-implies-consent
• Email/Defect Tracking System
• Meeting
What:
• Who requested the change, and rationale
• Focus on future risk/benefit
Who:
• Product owner, not designer, should make Go/No Go call
Step 4: Communicating changes
1. Log: Project manager can keep a log of change requests
2. Highlight: Designer updates and highlights the official spec
3. Archive: Designer updates the spec version number and archives the previous version
Ideas to challenge
• That working software is the only measure of progress
• That everyone on the team must work on the same set of user stories at the same time
• That only customers, not users, matter (or that customers and users are always the same)
Ideas designers love
• Frequent customer feedback
• Retrospectives & continuous learning
• Stuff getting built
Presenter:
Su-Laine Yeo Brodsky www.sulainebrodsky.com
Thank you!Further Reading:
• Agile Development that Incorporates User Experience Best Practices by Chris Nodder and Jakob Nielsen, www.nngroup.com
• Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden
• Software Project Survival Guide by Steve McConnell www.construx.com
@sulaineyeo