If you like this presentation – show it...
We’re Doing What, When? Incorporating UX Design Into Agile Su-Laine Yeo Brodsky UX Designer
2000: Usability specialist 2005: Interaction designer 2015: User experience designer UX/UI designer
User-centered design Why have one and only one application be accessible from the Lock screen?
“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.” –Jakob Nielsen Nielsen Norman Group
CHALLENGE #1 WHEN TO DESIGN? Background image: Dereckson CC-BY-3.0 via Wikimedia Commons
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 speciﬁcation: 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
Time for research and design is compressed
“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 diﬀerent than the designer’s.” –Kristen Johansen Senior Manager, User Experience Citrix
Alternative: Parallel track for design work Sprint Zero: Rough Design Up-Front Staggered Sprints: Designer Works 1-2 Iterations Ahead
Design walkthrough #1 Week 1 #2 Week 2 Week 3 #3 Conversations throughout the process Design ready to implement
1 Design walkthrough #1 #2 Week 2 Week 3 Conversations throughout the process #3 Week 1 Design ready to implement
CHALLENGE #2: CREATING COHESIVE DESIGN
“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.” –Dave Malouf
One user story for design → Multiple user stories for implementation
Design for multiple iterations
Consider organizing sprints by ﬁdelity Early sprints = lower ﬁdelity Later sprints = higher ﬁdelity
How to survive low-ﬁdelity design Development • • • Design code to be refactored Separate language strings Use low-ﬁdelity placeholders for artwork QA Documentation • Automate testing • • Focus early testing on business logic, scalability, performance - not superﬁcial UI Focus early on planning, outlining, and indexing • Omit unnecessary detail • Minimize repetition • Use screenshots sparingly
Consider a mid-project sprint to clarify design vision
Develop a style guide
CHALLENGE #3: GETTING USER FEEDBACK
You love seeing this (in a user test) (before the sprint is complete)
Line up users in advance. Start before you feel ready.
“Three users every Thursday” Sit down with one user at a time for 30 - 60 minutes Usability test & ask research questions Test whatever is ready each week
Online usability testing services (pretty good) usertesting.com ﬁvesecondtest.com
Hallway testing (cheap, better than nothing) Image: rekre89 CC BY 2.0
Design walkthrough #1 Design ready to implement Sprint n Best time for usability testing Code complete and tested Sprint n +1 Second-best time for usability testing
CHALLENGE #4: CHANGE MANAGEMENT & COMMUNICATION
What makes sense to change? • Issues from user feedback • Consistency issues • Spec housekeeping: typos, etc. • Under-speciﬁed 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? • • CC BY-NC-ND 2.0, Joel Kiraly Who should make the call on whether to accept a proposed design change? How do you choose between change requests and bug ﬁxes?
Communicating Change is Hard What are we building? What has recently changed?
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 oﬃcial 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 Highlight changes with red
Step 3: Change is reviewed Where: • Silence-impliesconsent • Email/Defect Tracking System • Meeting What: • Who requested the change, and rationale • Focus on future risk/beneﬁt 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 oﬃcial spec 3. Archive: Designer updates the spec version number and archives the previous version
SUMMARY: TWEAKING AGILE
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 • Stuﬀ getting built
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 Jeﬀ Gothelf and Josh Seiden • Software Project Survival Guide by Steve McConnell www.construx.com Presenter: Su-Laine Yeo Brodsky www.sulainebrodsky.com @sulaineyeo