1.
Su-LaineYeo Brodsky
UX Designer
We’re Doing What,When?
Incorporating UX Design Into
Agile

2.
2000: Usability specialist
2005: Interaction designer
2015: User experience designer
UX/UI designer

3.
Participate,
please!

4.
User-centered design
Why have one and only one
application be accessible from
the Lock screen?

5.
–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.”

6.
CHALLENGE #1
WHEN TO DESIGN?
Background image: Dereckson CC-BY-3.0 via Wikimedia Commons

7.
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.

8.
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

9.
Time for research and
design is compressed

10.
–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.”

11.
Sprint Zero: Rough Design Up-Front
Staggered Sprints: Designer Works 1-2
Iterations Ahead
Alternative: Parallel track for design work

12.
Week 1 Week 2 Week 3
Design
walkthrough
#1 #3#2
Design
ready to
implement
Conversations throughout the process

13.
Week 2 Week 3
Design
walkthrough
#1 #3#2
Design
ready to
implement
Week 11
Conversations throughout the process

14.
CHALLENGE #2:
CREATING COHESIVE DESIGN

15.
–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.”

16.
One user story for design
→ Multiple user stories
for implementation

17.
Design for multiple iterations

18.
Consider organizing
sprints by fidelity
Early sprints = lower fidelity
Later sprints = higher fidelity

19.
How to survive low-fidelity design
QA
• 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

20.
Consider a mid-project sprint to
clarify design vision

21.
Develop a style guide

22.
CHALLENGE #3:
GETTING USER FEEDBACK

23.
You love
seeing this
(before the
sprint is
complete)
(in a user test)

24.
Line up users in
advance.
Start before you
feel ready.

25.
“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

26.
Online usability
testing services
(pretty good)
usertesting.com
fivesecondtest.com

27.
Hallway testing
(cheap, better than
nothing)
Image: rekre89 CC BY 2.0

28.
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

29.
CHALLENGE #4:
CHANGE MANAGEMENT & COMMUNICATION

30.
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

31.
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

32.
Communicating Change is Hard
What are we building?
What has recently changed?

33.
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

34.
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”

35.
Highlighting Changes
Highlight
changes with
red

36.
Step 3: Change is reviewed
Where:
• 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

37.
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

38.
SUMMARY: TWEAKING AGILE

39.
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

40.
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