Su-Laine Yeo Brodsky UX Designer

We’re Doing What, When? Incorporating UX Design Into

Agile

2000: Usability specialist

2005: Interaction designer

2015: User experience designerUX/UI designer

Participate, please!

User-centered design

Why have one and only one application be accessible from the Lock screen?

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

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

Time for research and design is compressed

–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

CHALLENGE #2: CREATING COHESIVE DESIGN

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

One user story for design → Multiple user stories

for implementation

Design for multiple iterations

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

Consider a mid-project sprint to clarify design vision

Develop a style guide

CHALLENGE #3: GETTING USER FEEDBACK

You love seeing this

(before the sprint is complete)

(in a user test)

Line up users in advance.

Start before you feel ready.

“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

Online usability testing services

(pretty good)

usertesting.com fivesecondtest.com

Hallway testing (cheap, better than

nothing)

Image: rekre89 CC BY 2.0

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

CHALLENGE #4: CHANGE MANAGEMENT & COMMUNICATION

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

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

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

• 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