Agile ux fullday-uxpa2016
-
Upload
uxpa-international -
Category
Technology
-
view
527 -
download
0
Transcript of Agile ux fullday-uxpa2016
![Page 1: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/1.jpg)
Making UX Agile and LeanUXPA 2016, Seattle, WA
![Page 2: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/2.jpg)
Introductions• John• Thyra• Carol
![Page 3: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/3.jpg)
Agile Basics
![Page 4: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/4.jpg)
Agile is• Small teams • Making small pieces of work - “shippable
increments”• Effective communication• Ideally co-located
Original Via Spotify (original presentation not available). More at: http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14 and https://labs.spotify.com/
![Page 5: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/5.jpg)
Photo by Federico Bierti - https://www.flickr.com/photos/53318225@N00/
We all need to be in the same boat…
Test
Developers
Product Owner
Sales
Service Engineering
Globalization
User Experience
Content
Operations
Marketing
![Page 6: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/6.jpg)
WaterfallDefine
Design
Build
Test
Deploy
Months & Years Learn
Learn
Learn
![Page 7: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/7.jpg)
Agile
TestDeliverableDefine & DesignBuild
Weeks LearnLearn Learn
TestDeliverableDefine & DesignBuild TestDeliverableDefine & DesignBuild
![Page 8: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/8.jpg)
Agile History• February 2001: The Agile Manifesto written
at Snowbird Ski Resort in Utah• Authors:14 male software engineers• Agile, as originally conceived, understood
nothing of UCD or UX processes
![Page 9: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/9.jpg)
Agile Manifesto
We have come to value the items in the dark boxes more.
Full version: http://agilemanifesto.org/
Individuals and Interactions Customer Collaboration
over processes and tools over contract negotiation
Working Software Responding to Change over comprehensive
documentationover following a plan
![Page 10: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/10.jpg)
Individuals and Interactions• Individuals and interactions over processes
and tools• Communication• Working together• Creating opportunities to learn and share
• Not doing activities just to check a box• Not allowing tools to get in the way• Finding faster/better ways to work
![Page 11: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/11.jpg)
Shared Documents Aren’t Shared Understanding
Cartoon by Luke Barrett © Jeff Patton, all rights reserved, www.AgileProductDesign.com
![Page 12: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/12.jpg)
Working Software• Working software over comprehensive
documentation• Working software is the measure of work• Documentation doesn’t improve a system
• Complex systems • Documentation is sometimes necessary to make
“self serve”• System should be clear and well designed
![Page 13: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/13.jpg)
Customer Collaboration• Customer collaboration over contract
negotiation• Software was built for a client (not broad sets of
users)
• We interpret as Users
![Page 14: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/14.jpg)
Responding to Change• Responding to change over following a plan
• Planning is short-term and flexible• Change is a constant – embrace it and prepare • When things change, so does the plan
![Page 15: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/15.jpg)
Benefits of being Incremental• When development runs out of
time/resources, the shipped solution• Delivers maximum value• Has a complete design without holes• Has much higher quality• Has no wasted design work
![Page 16: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/16.jpg)
Agile Qualities• Iterative• Incremental• Continuous• Collaborative• Transparent
![Page 17: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/17.jpg)
Agile Terminology
![Page 18: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/18.jpg)
Scaling Agile at Spotify via Slideshare of Vlad Myslahttp://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
Squads, Tribes, Chapters and Guilds
![Page 19: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/19.jpg)
Scrum• Daily Ceremonies - Standup
• 15 minute standing meeting• What you did, what you are doing, blockers
• Sprints• 2 – 4 weeks of work • Culminate in a potentially shippable product
increment
![Page 20: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/20.jpg)
mountaingoatsoftware.com
Scrum
![Page 21: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/21.jpg)
Sprints
TestDeliverableDefine & DesignBuild
Sprint 2Sprint 1 Sprint 3
TestDeliverableDefine & DesignBuild TestDeliverableDefine & DesignBuild
![Page 22: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/22.jpg)
Kanban• Finite number of “tickets”• Cannot put more work in until previous work is
done• Team members pull work as work is
completed• Time-boxing is optional• All work is a collaboration• Information radiators
![Page 23: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/23.jpg)
Kanban - work is shared on walls/boards
![Page 24: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/24.jpg)
Story=
User Problem with acceptance criteria
![Page 25: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/25.jpg)
Epic > Story > Task
BacklogEpic
1
Epic 2
Epic 1Story
AStory
B
Story BTask X Task Y
![Page 26: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/26.jpg)
Name this…
https://www.thunderbolts.info/wp/2015/01/22/the-curls-of-ares-2/
![Page 27: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/27.jpg)
Fibonacci Sequence
![Page 28: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/28.jpg)
Estimating Stories• T-shirts, Fibonacci, days work, etc.• Minimal effort to guess• If cannot guess, further define story
![Page 29: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/29.jpg)
UX Activity Estimation• Should UX activities be estimated towards
team velocity?• A hotly debated topic
• No. They UX stories should be tracked separately, in parallel
• Yes. UX stories should be tracked with other work, especially when part of active work
• “Working software is the primary measure of progress”
![Page 30: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/30.jpg)
Velocity• Measure amount of work done • Determine our velocity or “burn down”• Estimates and velocity tell us what we can get
done• Longer term, squads can improve velocity
![Page 31: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/31.jpg)
![Page 32: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/32.jpg)
Parking Lot• Used to get to a firm estimate and clarify
questions • Able to respond Go/No Go• Problems that can be solved in a single
conversation
![Page 33: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/33.jpg)
Design Spikes• Used to get to a firm estimate when not
enough information to determine in a parking lot• Intense focus on issue with multiple resources• Done by a few while other work continues
• Multiple resources (not just design)• Must continue to support ongoing
development
![Page 34: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/34.jpg)
User Acceptance Testing• Customer/client feedback in traditional Agile• Clients (not users):
• Are shown a demo by team• Do not touch or interact with system• Not typically a member of the Agile team• Are rarely the users of the system being designed
• When feedback is collected in traditional Agile – after iteration/sprint
![Page 35: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/35.jpg)
Demos and Retros• Demos are “playing back” what was done
during the sprint• Matches the Epics/Stories from the Sprint• Celebrate progress
• Retrospective• Looking at what went well (continue doing)• What could be improved• What we should stop doing
![Page 36: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/36.jpg)
Customers and Lean UX
![Page 37: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/37.jpg)
Customer Feedback – in traditional Agile• Fails to find most learnability and usability
issues• Misses opportunity to inform future design• Misses opportunity to gain better user insight
with prototypes, observation, etc.
![Page 38: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/38.jpg)
Bring Users into Agile• UX brings the end-user into Agile and expands
the meaning of “Customer” to extend to the end-user
![Page 39: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/39.jpg)
Lean Startup• Lean is a business development method,
popularized by Eric Ries.
• It’s like Agile for the business side of things• Uses the same build – test – learn cycle
for business models and product development• Only measure of success is market behavior
![Page 40: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/40.jpg)
Lean UX• Agile is the perfect product delivery method
for Lean businesses• Same adaptations that make UX practices
work in Agile also make them work in Lean• Lean UX = Agile UX
• Rely on early research and usability testing (learn as you go)
• Less time to conduct research and think through problems
• Handled as a spike if needed
![Page 41: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/41.jpg)
Eric Ries @ericries via @MelBugai on Twitter at LeanStartupMI in 2011
"The biggest waste of all is building something no one wants“
- Eric Ries @ericries
![Page 42: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/42.jpg)
Developing Software in AgileGetting Agile Teams to Care About Usability
![Page 43: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/43.jpg)
We Come from Different Places
By Jeff Patton as interpreted by Jim Laing – Source: http://www.agileproductdesign.com/blog/user_experience_relevance.html
![Page 44: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/44.jpg)
Agile• Agile is a philosophy, not a specific set of tools
• Principles are not mandates• UX was not deliberately excluded
• Software development methods• Scrum, Kanban, XP, etc. meet the criteria for Agile• “Waterfall” does not
![Page 45: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/45.jpg)
Agile Frustrations
Scaling Agile at Spotify via Slideshare of Vlad Myslahttp://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
team member
![Page 46: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/46.jpg)
Agile UX: The Good• Most important features are done first • Working together – not “over the wall”• Keep up with technology and environmental
changes• Enables iteration of requirements• Less “design drift” and less wasted design
![Page 47: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/47.jpg)
Agile UX: The Good (continued)• Issues get fixed• “Done” includes design• Satisfying to see designs in real use• Learn from actual product use• User data has effect on current release
![Page 48: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/48.jpg)
So Now What?• If Agile doesn’t care about UX, why should my
Agile team care about what I do?
![Page 49: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/49.jpg)
Getting Developers to Care• UX Fail strategies:
• “I’m just going to keep doing my job the way I always have and telling the team what they need to do.”
• “I’m just going to let them go ahead and fail. Then they’ll come to me begging and let me do my job.”
![Page 50: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/50.jpg)
Be Part of the Team• They’re not going to “stop the train” for you• Make UX processes Agile• Build trust by providing value of work• Attend daily standups/scrums
![Page 51: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/51.jpg)
Get Ahead of the Train• Design one iteration ahead if necessary, so
you have designs ready to go when they are needed
• Regular usability testing (iteration-aligned)• Test whatever is ready that day• Plus your look-ahead designs• Plus user research for existing issues and potential
future work• Test designs before developers build them –
saves arguments
![Page 52: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/52.jpg)
Welcome the Team to your World• Invite developers to observe tests of features
they wrote • Seeing someone struggle is strongly motivating to
them• Even more so for product managers
• Engage developers in helping you to figure out solutions• Their knowledge of code and systems provides
ability to come up with innovative solutions• Credit developers when features they wrote
work well (even if you designed it)
![Page 53: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/53.jpg)
Bring Your World to Them• No time or inclination to watch your testing?
• Record the tests • Bring key clips to the next meeting(s)• Provide easy access to sessions (always consider
ethics)• Information radiators
• Share info on the walls• Use online tools• Get it in the backlog
Photo: https://medium.com/@FBResearch/beyond-bullet-points-four-creative-ways-to-share-research-c10fa047f025#.cdauyngei
![Page 54: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/54.jpg)
Fit into the Process• Time product testing: results ready when most
useful• Track usability metrics on the team dashboard
• Ensure they are reported upwards• Help prioritize usability problems to simplify
backlog grooming• Add preemptive cards to the schedule for
“problems we will find while testing”
![Page 55: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/55.jpg)
Design Adapts to Agile• Falling short of end goals is a constant
• Focus on meeting user’s primary needs • Constant Improvement is key
• Widen the Design family• Distribute the work• Empower entire squad to inform design
• Agile is reactive – no time for predictive work• Prepare to react
Adapted from Jim Laing’s presentation at UX Pittsburgh, May 2014
![Page 56: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/56.jpg)
Participate in Retrospectives• Encourage retrospectives if they aren’t
happening• Information provided enough/too much?• Questions still open?• Still confusing/frustrating?• More effectively communicate user needs?
Image: http://intland.com/blog/project-management-en/tips-and-tricks-to-make-the-most-of-your-retrospectives/
![Page 57: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/57.jpg)
Let’s Chat
![Page 58: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/58.jpg)
Let’s Get to Know Each Other• Who has had agile training?
• Reading, no formal training• Other team members trained• No training• Some training
• How long have you been doing Agile?
![Page 59: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/59.jpg)
Who’s Here?• Roles?
• UX practitioner, UX manager -- is this who we all are?
• Resources?• Single UX resource on a single Agile team/project• Single UX resource on 2+ Agile teams/projects• Part of a UX team on a single Agile team/project• Part of a UX team on 2+ Agile teams/projects
• Maturity of UX Practice?
![Page 60: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/60.jpg)
What’s Your Team Like?• Distributed/remote?• Large/small?• Who else is on the team?• How long have you been together?
![Page 61: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/61.jpg)
Balancing Team Work• Within UX team
• Research• Wires/clickable prototypes• Usability testing preparation• Usability test facilitation• UX Issue wrangling• Visual design• What else?
• Split team up on different items or attack together
![Page 62: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/62.jpg)
Marketing, Sales and Business Analysts• Have customer access• Knowledge
• Business rules• Usage patterns, what other tools customer has
• Can support• Research (users/stakeholders)• Wires• Demos/Clickable prototypes
![Page 63: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/63.jpg)
Developers and UX• Trust is key• FED (front end developers) and UI Developers
• Can provide• Clickable prototypes • Coded “prototypes”
![Page 64: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/64.jpg)
product owner =
product manager+
dev lead+
interaction designer
![Page 65: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/65.jpg)
Break
30 Minutes, Fifth Avenue
![Page 66: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/66.jpg)
Scaling Agile at Spotify via Slideshare of Vlad Myslahttp://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
Squads, Tribes, Chapters and Guilds
![Page 67: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/67.jpg)
Parallel-Track Workflow
a.k.a. Staggered Sprints
![Page 68: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/68.jpg)
Agile Design Timing: Parallel Tracks• Developer track: Focus is on production code• Interaction designers track: Focus is on user
contact
![Page 69: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/69.jpg)
Iteration 1: Developer Track• Underlying architecture work• Critical features with little user interface
design required
![Page 70: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/70.jpg)
Iteration 1: Interaction Designers• Design, create prototypes, usability test
(UTest), and iterate (RITE method)• Field studies to understand user needs (contextual
inquiry)
![Page 71: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/71.jpg)
Iteration 2: Developers• Take the verified designs and start making
them a reality
![Page 72: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/72.jpg)
Iteration 2: Interaction Designers• UTest completed code for integration and implementation
issues
![Page 73: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/73.jpg)
Iteration 2: Interaction Designers• UTest completed code for integration and implementation
issues• Use data gathered in the last iteration to create designs for
next iteration
![Page 74: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/74.jpg)
Iteration 2: Interaction Designers• UTest completed code for integration and implementation
issues• Use data gathered in the last iteration to create designs for
next iteration• Field studies for detailed information needed for upcoming
iterations
![Page 75: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/75.jpg)
And so on…• Constant communication between the two tracks is
essential for success• These are not just hand-offs
![Page 76: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/76.jpg)
We repeat:• Constant communication between the two
tracks is essential for success
• These are not just hand-offs
• This is the most misunderstood thing about staggered sprints.
![Page 77: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/77.jpg)
During Each Iteration• Be present with developers day to day• Are they building what you expect?• Get their feedback on your designs in
progress
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 78: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/78.jpg)
During Each Iteration• Look back• Validate the work done in previous iteration
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 79: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/79.jpg)
During Each Iteration• Look ahead• Design for next iteration (n+1)• Research for future iterations (n+2, n+3…)
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 80: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/80.jpg)
Combine Your Investigations• Maximize your time with users• Test completed code• Test paper prototypes of upcoming design• Elicit data for future design
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 81: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/81.jpg)
Agile Roles and Parallel Tracks• UX Takes Time• Having multiple roles (e.g. UX + product
owner, UX + scrum master) leads to overload
• Working on multiple teams is a bad idea
![Page 82: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/82.jpg)
Incremental Implementation
Getting to complete workflows, one DONE at a time
![Page 83: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/83.jpg)
“Story”=
User Problem with acceptance criteria
![Page 84: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/84.jpg)
Story Myths• Story = feature• Story = specification• Story must fit in one iteration• Stories are time limited• All stories have firm estimates and specs in
Iteration Zero (or even Iteration One)• These are NOT true.
![Page 85: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/85.jpg)
Story Examples
Advantages of the “As a user, I want” user story template. By Mike Cohn
http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user-story-
template
![Page 86: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/86.jpg)
To make a story INVEST• A good story is:
• Independent• Negotiable• Valuable to users or customers• Estimate-able• Small• Testable
User Stories Applied for Agile Software Development, By Mike Cohn
![Page 87: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/87.jpg)
What if your story is too big?• If work can’t be completed in one iteration• Where are the break lines?• How do you prioritize the feature cards?
![Page 88: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/88.jpg)
Big Design - Waterfall• Everyone signs off before Dev begins
• One big design document contains everything• Dev builds it until they run out of time• QA doesn’t test until Dev has run out of time
• Result• Whatever is built first is completed• Details are left out, quality issues identified too
late• Holes are left in the design
• Much of your design effort is wasted
![Page 89: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/89.jpg)
Big Design - Agile• Deliver incremental value quickly• Break the story into small pieces• What is the smallest piece that can be built?
• Delivers value to the user• Incremental • Something to learn from• Minimum Viable/Valuable Product (MVP) – from
Lean Startup
![Page 90: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/90.jpg)
Big Design – Agile (continued)• Schedule the pieces in order of importance• Design incrementally, as if the each piece
were the final one• Change your future plans between iterations if
you have learned new things
![Page 91: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/91.jpg)
Original via Spotify (original presentation not available). More at: http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14 and https://labs.spotify.com/
![Page 92: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/92.jpg)
Story Card Progress• Is UX Needed?
• What is the story?• What do we know? • What do we need to know?
• Conduct Lean UX to answer outstanding questions• Interviews, observations, prototype testing, etc.• Work with Dev to respond to questions as needed
92
Kanban
Do Review Done
![Page 93: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/93.jpg)
Benefits of being incremental• When development runs out of
time/resources, the shipped solution• Delivers maximum value• Has a complete design without holes• Has much higher quality• Has no wasted design work
![Page 94: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/94.jpg)
Mistakes to avoid• Designing all the detail up front• Not thinking about the full experience up front• Not breaking things down far enough• Not delivering a complete (sub) story each
iteration – “now the user can…”
![Page 95: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/95.jpg)
Incremental Example: Doorway• User story: The user can get in and out of her
house easily.• Completion Criteria:
- Secure - Insulated - Lets light in - Allows large furniture items to pass - Fits with house décor - Works even without keys
![Page 96: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/96.jpg)
Incremental Example: Doorway• Initial Rough Design:
- Beautiful Colonial Door - Unbreakable translucent window - Programmable digital lock - Steel deadbolt - Metal-clad on the outside - High R-Value
![Page 97: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/97.jpg)
Incremental Example: Doorway• What is the minimum work that will give the
user incremental value towards their goal?• What needs to be designed for that?
• What is the next smallest item that will give the user an added capability?
• What needs to be designed for that?
![Page 98: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/98.jpg)
ActivityStory Selection
![Page 99: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/99.jpg)
Activity: Early Story Selection• Select the first 10 stories that should be done.
• How many do you have to complete before
you would be willing to try it with real customers?
• See handout
![Page 100: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/100.jpg)
Incremental Implementation
Continued
![Page 101: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/101.jpg)
Fitting This to Your Process• The purpose of incremental implementation is
to get feedback early and often• After each iteration, gather feedback• Questions that can affect your breakdown:
• Who evaluates your product?• Is it always the same people?• Are your target users internal or external?
![Page 102: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/102.jpg)
Gather feedback from• Internal ‘expert users’• Beta/Usability testers under NDA• The general public (after release or open beta)• Internal users in a protected ‘sandbox’• Internal users after general deployment
![Page 103: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/103.jpg)
Before releasing, consider• Are you getting the feedback you need?• Is there enough completed for an external
user to evaluate?
• Sometimes you may want to hold back certain work until more is done.
![Page 104: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/104.jpg)
Make it Easier for the Team• Write staged specifications
• Best guess at breaking the design into 1-iteration Story increments
• “Break” the Stories with developers into Tasks• Remember: they own the Tasks• You need to know how to map those back to Stories &
Capabilities (See story mapping)
![Page 105: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/105.jpg)
Ways to Break a Story Down• Workflows
• Stories with many “mini-workflows”• e.g., Channel changer
• Allowed inputs• Story that applies across different data types• e.g., Image file reader
• Capacity• Completion criteria involve extreme size or speed• e.g., File transfer of large files
![Page 106: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/106.jpg)
Example: Ordering Your Sub-Stories• Big Story: User can move, duplicate, or
remove selected text in a document.
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 107: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/107.jpg)
Example: Story Breakdown• Big Story: User can move, duplicate, or
remove selected text in a document.
• Note: there are many possible designs that achieve this user capability
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 108: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/108.jpg)
Example: Story Breakdown• Big Story: User can move, duplicate, or
remove selected text in a document.
• The selected design is to provide 4 menu items with hotkeys: Cut, Copy, Paste, and Delete.
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 109: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/109.jpg)
Example: Story Breakdown• Written out as proper stories:
• The user can move selected text out of the document and into an off-screen clipboard.
• The user can copy selected text into the off-screen clipboard.
• The user can replace selected text with the contents of the off-screen clipboard.
• The user can delete selected text.
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 110: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/110.jpg)
Example: Story Breakdown• Stories: Cut, Copy, Paste, Delete• How engineering breaks it down:
• Sprint one: create memory buffer system• Sprint two: add menu items, tooltips, etc• Sprint three: Copy• Spring four: Cut, Paste, Delete
• What is wrong with this?
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 111: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/111.jpg)
Example: Story Breakdown• Stories: Cut, Copy, Paste, Delete
• How do you order these four stories?• Which one comes first? Why?• Which one comes second? Why?• Which one comes third? Why?
© Copyright 2014 Desirée Sy & John Schrag. All rights reserved.
![Page 112: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/112.jpg)
ActivityStory Breakdown
![Page 113: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/113.jpg)
Activity: Story Breakdown• Chandra needs all the application functions
available to him in his native language or another language he understands well.
• Which of these breakdowns is/are Agile? Why?
• What factors would determine which breakdown you should choose?
• See handout
![Page 114: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/114.jpg)
What if no breakdown is possible?• You can have a story with one single capability
that takes more than a sprint to build.• For example, a calculation with a difficult
algorithm.
• This is an engineering problem, not a UX problem.
• If possible, see if the work-in-progress can be validated using partial results.
![Page 115: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/115.jpg)
Discussion• What are your story breakdown problems?
![Page 116: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/116.jpg)
Lunch12:30 pm – 1:30 pm
![Page 117: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/117.jpg)
Agile Qualities• Iterative• Incremental• Continuous• Collaborative• Transparent
![Page 118: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/118.jpg)
User Story Mapping
![Page 119: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/119.jpg)
Shared Documents Aren’t Shared Understanding
Cartoon by Luke Barrett © Jeff Patton, all rights reserved, www.AgileProductDesign.com
![Page 120: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/120.jpg)
![Page 121: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/121.jpg)
User Story Mapping• Organizing user stories
into a map that communicates experience
Book: User Story Mapping, Discover the whole story, build the right product. By Jeff Patton (with Peter Economy)
![Page 122: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/122.jpg)
Visible Depiction of Available User Stories• Frame questions such as
• What is needed?• When is it needed?• Where is there value?• What is really important?
![Page 123: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/123.jpg)
Depth and Breadth of Entire System
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
time
Below each activity, or large story are the child stories that make it up
Arrange spatially to tell bigger stories
![Page 124: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/124.jpg)
Represents Complexity and Size of Work
time
Refine the map and test for completeness with the entire team - developers, designers, BA’s etc.
![Page 125: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/125.jpg)
Conversations to Understand• Relationships between stories• Structure and hierarchy of related stories• Functionality that is being built • Conversations to share knowledge and clarify
assumptions
![Page 126: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/126.jpg)
Clarity of What is to be Built• Organizes stories• Context of use for product• Clear understanding of use makes
prioritization easier• Backlog completeness can be verified
• Can be overwhelming to see entire product• Important to know information now rather than
later
![Page 127: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/127.jpg)
Enables Better Releases• Select relevant, high priority stories in
releases• Valuable functionality• Complete sets of functionality
• Plan, at a high level • What would come next• What is for “later”
![Page 128: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/128.jpg)
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
Activity: Story Mapping
• What were all the things you did to get ready to be here today?• Starting from the moment you woke up until you
arrived here• Write one item per sticky note
![Page 129: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/129.jpg)
Activity: Story Mapping
• In a small group (3 to 5) merge stickies into a single model• Arrange left to right in order that makes sense
to group• Eliminate duplicates• Cluster items that seem similar and create
labels for the clusters if items that seem to go together
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
![Page 130: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/130.jpg)
* from Cockburn’s Writing Effective Use Cases
Story Detail – Level of Fidelity
© Jeff Patton, all rights reserved, www.AgileProductDesign.com
Functional or “Sea level”I’d reasonably expect to complete this in a single sitting
Sub-Functional or “Fish level”Small tasks that by themselves don’t mean much. I’ll do several of these before I reach a functional level goal
Activity or “Kite level”Longer term goals often with no precise ending. I’ll perform several functional tasks in the context of an activity
Too abstract
Too detailed
Think about user experience at this
level
Be sensitive to your user task’s “altitude”
![Page 131: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/131.jpg)
Discover as much as possible, as quickly as possible• Prototype early • Learn from prototypes and iterate
![Page 132: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/132.jpg)
Agile UX Prioritization
Knowing what’s important
![Page 133: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/133.jpg)
Timing for Prioritization• When grooming the backlog• During formative usability testing
![Page 134: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/134.jpg)
Prioritizing Problems• It’s better to fix the few most important issues
than to find every issue because:• Big problems can mask other problems• Every fix changes user behavior
![Page 135: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/135.jpg)
Prioritizing ProblemsHigh ValueLow Cost
High ValueHigh Cost
Low ValueLow Cost
Low ValueHigh Cost
UX/Product Managementdetermines “Value”
![Page 136: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/136.jpg)
Prioritizing ProblemsHigh ValueLow Cost
High ValueHigh Cost
Low ValueLow Cost
Low ValueHigh Cost
Development determines “Cost”
![Page 137: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/137.jpg)
Prioritizing ProblemsHigh ValueLow Cost
High ValueHigh Cost
Low ValueLow Cost
Low ValueHigh Cost
A BC Seriously?
![Page 138: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/138.jpg)
“If a user can’t find or use feature, it’s the same as if the feature is broken.”
VS.
“It’s more important to fix things that really don’t work. The user can learn the hard stuff.”
Prioritizing UX vs “real” bugs
![Page 139: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/139.jpg)
Prioritizing UX vs “real” bugs• You cannot win this argument on a case-by-
case basis• Instead, adopt a strategy for getting required
investment in UX work
![Page 140: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/140.jpg)
Strategies for Getting Investment in UX• Political strategy: Create a formal equivalence
of UX versus bug priorities.• Investment strategy 1: Block out fixed time• Investment strategy 2: Block out people• End-run strategy: get your own engineer
• Fix UX problems early, if possible.
![Page 141: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/141.jpg)
Detail Matters• Users are usually more delighted by low-cost
annoyance fixes than by big flashy new features
![Page 142: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/142.jpg)
Focus and Negotiation• Keep an intense focus on fixing the most
important things
• Negotiate on behalf of users• Represent their needs as best you can
![Page 143: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/143.jpg)
Break
30 Minutes
![Page 144: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/144.jpg)
Research & Requirements
![Page 145: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/145.jpg)
Research Balancing Act
Understand users, context, etc. Create personas, mental models, etc. Prepare for story mapping
and other sessions thoroughly
Strive for UX Best Practices
Engineers need designs to develop - will move on without UX involvement
Research cannot continue forever
Meet Production Needs
Agile requires leaner methods
![Page 146: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/146.jpg)
How much is good enough?• What is being developed?• What do you know?• What questions are still open?
• Meet goal when users starting to talk about colors and icons (not functionality)
![Page 147: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/147.jpg)
Light Design - Lean UX• Familiar UX methods made lean:
• Iterative (flexible, change as needed)• Repeatable (easy to do, expected next steps)• Incremental (lead into next, small changes over
time)
![Page 148: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/148.jpg)
Tips for Lean• Usability Testing
• Insert questions to find out more for open issues• Schedule regular testing to reduce preparation
time• Reach users quickly for meaningful
information (panels, remote testing, surveys etc.)• Incentives as needed
• Put all data together quickly – no big reports
![Page 149: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/149.jpg)
Documentation & Reporting
![Page 150: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/150.jpg)
Don’t Overwhelm Audience or You• Document in Wiki or similar (avoid PPT)• Just enough to understand the “why”• Always challenging due to:
• Limited time• Multiple changes over time• Findings building upon one another
150
![Page 151: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/151.jpg)
Provide Details as Appropriate• Archive prototypes and other deliverables• Regulatory environment or complex
interactions • Test plans and guides• Detailed changes• Participant information as needed, but avoid
sharing with wider team
151
![Page 152: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/152.jpg)
Capture the Evolution• Helps avoid making same mistakes later• Helpful to capture first, middle and end
screenshots:• primary pages• primary features• contentious issues
• Don’t sweat the small stuff• Use final prototypes as a base for
recommendations (vs. written documentation and/or comps) 152
![Page 153: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/153.jpg)
Separation affects documentation needs• When team is not co-located, does not share
time zones and/or does not share language• Use additional documentation to communicate
and coordinate• Use Agile tools (GitHub, JIRA/Confluence) and UX
tools (Mural.ly, etc.) to share understanding• Use communication tools as frequently as possible
(Skype, online meetings, etc.)153
![Page 154: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/154.jpg)
Lean Reporting• Put all data together quickly• No big reports• Information as needed
• Get it to the team – quickly (Evernote, Mural.ly, Trello, Story/Bug tracker, etc.)
• Tell the story – pertinent information – who, why?• Provide solutions (wireframes, etc.)
![Page 155: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/155.jpg)
Tell the Story• Strive for “Caterpillar to Butterfly”
• Show progressions of key sections of the interactions
• Use more screenshots – fewer words• Explain what changes were made and why
155
![Page 156: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/156.jpg)
Activity: Make it Lean (45 minutes)
![Page 157: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/157.jpg)
Activity: Determine User Expectations• Early stages of a project - defining scope. • Stakeholders: “Users will never sign a catering
contract on their phone!” Doesn’t need to work on the phone.
• UX team: Not likely to be their primary access choice, but will be desired to be done on their phone.• You have 2 days: Determine if common/critical use
case • Teams of 3 people• Make a plan for what to do (10 minutes)• Share your plan
![Page 158: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/158.jpg)
Guidelines• What do you need to know?• What resources do you have?• How much effort/time do you have?
![Page 159: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/159.jpg)
Activity: Part 2• Take roles and act them out• Discuss ramifications of findings
• What's in and what's out?• Make tradeoffs – conversations• Vote within teams
• See handout
![Page 160: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/160.jpg)
Sprint Zero
![Page 161: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/161.jpg)
Sprint Zero for Scrum Teams• Time to do initial research, setup usability
testing, etc.• When technical teams are setting up
environments• Back end that doesn’t hit front end
• Getting alignment on business goals – WHY??• All bought in across board• Do just enough work to get development
started
![Page 162: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/162.jpg)
Alternatives to Sprint Zero• Can be in parallel sprints while other teams
are wrapping up previous work• Do work in Sprint 1
• Planning, story mapping, etc. (or already done)• Story creation (or not done yet, or will do later)• Create initial wires and prototypes (or in Sprint 1)
• Goal is to have initial questions answered – doesn't matter what you call it
![Page 163: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/163.jpg)
Pros and Cons - Sprint Zero• Pros
• Gives UX a head start• Lot of backend work needs to be done anyway• Establish common vision
• Who for?• Common “elevator statement”
• Cons• Can be a trap leading to Waterfall
• Big Design Up Front (BDUF)• Time box and Focus on Outcomes to avoid this
![Page 164: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/164.jpg)
Requirements• Change in presence of the artifact• Questions change as you learn more • Pointless to do ALL requirements gathering up
front• Works better iteratively – unless in hands of
those that will use it• Don't know what we don't know
![Page 165: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/165.jpg)
Make it Quick!• Proxies as needed• Quick enough analysis• Get to 80% confidence • Continued learning with additional contacts
• Usability testing• Customer visits (enterprise software)
![Page 166: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/166.jpg)
Setting Expectations• Developers
• Only get a little bit of information at a time• Need to fit work in• May need to rework as we learn• Repeat it as we go
![Page 167: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/167.jpg)
Arguments About UX• Not done (what is “done?”)• Indecisive (make up your mind!)• Never right (“more feedback already?”)
![Page 168: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/168.jpg)
Agile Usability Testing
![Page 169: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/169.jpg)
UX Made “Agile”• Any UX method can be adapted
• Don’t have to give up our favorite methods • Don’t have to learn new ones• Doesn’t take much effort to adapt our methods to
fit the Agile process• Think about “lean” and “iterative” methods• RITE is a good place to start
![Page 170: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/170.jpg)
RITE Overview• Qualitative user feedback
• actions + comments • Series of small usability tests• 3 participants each day• Minimum of 3 days of testing
• Iteration between testing days• Total of 5 days
![Page 171: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/171.jpg)
RITE Process
Test Update Test
123
High
Medium
Low
Priority & Level of Effort
![Page 172: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/172.jpg)
What Works for RITE• Best used early in project lifecycle
• Early concepts• Need to be vetted with users• Can assist in quickly shaping designs
• Doesn’t this sound “agile”?
172
![Page 173: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/173.jpg)
Evaluation + Testing• Think evaluation → testing throughout the
product development lifecycle• Start with design evaluations and move onto
testing the deliverables for each Sprint/Iteration
• Start with the big questions and narrow down quickly (what would be the top 3 things to fix/improve? would you use it? Would it be a “wow”? which of 3 approaches do you prefer?)
![Page 174: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/174.jpg)
Number of Participants• Think fast and iterative
• For example ~5 participants for each, and iterate if needed
• Key is to get the needed feedback, iterate, and move on • Do you really need 10 participants to tell you it’s
something they would never use?• Know when enough is enough
• If 3 participants so far have “failed”, do you need to test the other 2?
• Note: personas can be agile too: top 1, confirm, test
![Page 175: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/175.jpg)
Testing Cycles• Set a schedule and expectations with the
team early• User testing days (e.g., every Friday, we’ll
have 3 hours set aside for testing)• Schedule set to Sprints/Iterations (e.g., at end
of every Sprint, schedule a round of testing to cover what has been completed)
• Also consider combining sessions for multiple goals (e.g., test what was done last Sprint, get early feedback on what you are working on now)
![Page 176: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/176.jpg)
Testing Materials• Use the lowest fidelity method possible to get
the needed information (the time spent in developing the materials is time you won’t have for iterating and testing)
• Use sketches and wireframes to work on basic concepts and keep attention focused away from details
• Use higher fidelity when you are testing the details and interactions
![Page 177: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/177.jpg)
Test Only Until “Done”• Stop testing when you know enough to move
forward• Test for the big stuff first: when you start
hearing about icons and colors, not function or layout, you know it’s “enough”
![Page 178: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/178.jpg)
Light Reporting• Don’t write a report• Focus on most important changes• Record change decisions and reasons why (for
future reference, and for onboarding new designers)
• Explain changes to the team face-to-face• Tell the story
![Page 179: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/179.jpg)
Discussion
![Page 180: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/180.jpg)
Discussion• Additional topics
• Bringing work in – how do you select the right thing(s)?
• Backlog grooming and where UX fits in• Types of prototypes• Other frameworks for Agile• Working with PM’s, and leadership
• What are your experiences?
![Page 182: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/182.jpg)
Contacting the Presenters• John Schrag, [email protected]
@jvschrag• Thyra Rauch, [email protected] • Carol Smith, [email protected] @carologic
![Page 183: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/183.jpg)
Additional Reference
![Page 184: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/184.jpg)
Principles behind the Agile Manifesto1. Customer satisfaction by rapid delivery of useful software2. Welcome changing requirements, even late in development3. Working software is delivered frequently (weeks rather than
months)4. Close, daily cooperation between business people and developers5. Projects are built around motivated individuals, who should be
trusted6. Face-to-face conversation is the best form of communication (co-
location)7. Working software is the principal measure of progress8. Sustainable development, able to maintain a constant pace9. Continuous attention to technical excellence and good design10.Simplicity—the art of maximizing the amount of work not done—is
essential11.Self-organizing teams12.Regular adaptation to changing circumstance
http://www.agilemanifesto.org/principles.html
![Page 185: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/185.jpg)
• Adapting Usability Investigations for Agile User-Centered Design by Desirée Sy
• Journal of Usability Studies, Volume 2, Issue 3 (the most-cited paper in JUS)
• http://www.uxpajournal.org/
![Page 186: Agile ux fullday-uxpa2016](https://reader035.fdocuments.net/reader035/viewer/2022062412/5879ca381a28abb42a8b7027/html5/thumbnails/186.jpg)
References• Shivani Mohan and Lissette Sotelo Parr, Sharing Ethnographic research:
https://medium.com/@FBResearch/beyond-bullet-points-four-creative-ways-to-share-research-c10fa047f025#.of9i2n5g7