RUX Agile Jan 10
•
4 gefällt mir•1,223 views
Agile team professionals often find themselves working on projects with tight deadlines, tighter budgets, and unreasonably high expectations for success. Too often user research, usability, and design processes are compressed or even cut entirely for the sake of time, while development and business analysis time is increased. As UX professionals become more involved with agile development methods, we have discovered novel approaches to user-centered design that are adaptable to any budget or deadline. This discussion will explore how user research, usability, IA and interaction design practices are adapted and thrive in agile projects. Focusing on their experiences at Agile 2009 in Chicago this past fall, they will discuss: * How to provide timely and valuable UX support to stressed web development teams * How to let go and modify research/design/development dogmas * How to advocate for users when time for user research and usability are unavailable * How to balance rigor, quality, and speed
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie RUX Agile Jan 10
Ähnlich wie RUX Agile Jan 10 (20)
Mehr von jsokohl
Mehr von jsokohl (12)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
RUX Agile Jan 10
- 1. Agile User Experience: Two Stories & a Conversa9on January 12, 2010 Richmond User Experience (RUX) richmondUX.com AgileRichmond agilerichmond.com Presented by: Joe Sokohl and Tom Illmensee Sunday, January 24, 2010
- 2. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 3. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Agile/Scrum iteraJve soLware engineering process culture of close collaboraJon face-‐to-‐face communicaJon (less documentaJon) deliver well-‐craLed, working code in short cycles challenging environment for tradiJonal UX Sunday, January 24, 2010
- 4. Agile User Experience: Two Sales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Ttories & Manifesto: agilemanifesto.org 12 principles: agilemanifesto.org/principles.html Global organizaJon: agilealliance.org Yahoo! Agile UX group: 9nyurl.com/4vrwpd Scrum: www.controlchaos.com Sunday, January 24, 2010
- 5. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 User Experience Designing soluJons for real users doing real tasks Basing designs on observable behavior, not opinion Focusing on people while understanding business and technology User Busin Services Sunday, January 24, 2010
- 6. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 7. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 8. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 User Centered Design Business Process & Agility Focus Services-Oriented Architectures/ Web Services Enterprise Data Integration Sunday, January 24, 2010
- 9. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Communities of practice Boxes and Arrows: boxesandarrows.com UX Matters: uxmatters.com Usability Professionals Association: upassoc.org Information Architecture Institute: iainstitute.org Interaction Design Association: ixda.org Johnny Holland: johnnyholland.org Konigi: konigi.com People Don Norman: www.jnd.org Anders Ramsay: andersramsay.com Jared Spool: www.uie.com Luke Wroblewski: functioningform.com Lou Rosenfeld: louisrosenfeld.com Carolyn Snyder: snyderconsulting.net Sunday, January 24, 2010
- 10. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 11. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Spool’s clo sing keynote 1,400 attended Jared Sunday, January 24, 2010
- 12. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Joe’s story Joe Sokohl joe@RegularJoeConsul9ng.com @mojoGuzzi Sunday, January 24, 2010
- 13. A Tale from the LiveAid Trench Sunday, January 24, 2010
- 14. Agile ’09 ➡ Challenge: Create a functioning iPhone-enable Web app in 4 days ➡ Charity: www.ManoAMano.org ➡ Goal: Raise $1,000 at the closing banquet Sunday, January 24, 2010
- 15. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Guerilla Research Sunday, January 24, 2010
- 16. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Crafting Better Research Questions Sunday, January 24, 2010
- 17. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Interviewing Research Participants Sunday, January 24, 2010
- 18. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Personas Sunday, January 24, 2010
- 19. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Tell us about Alice... Sunday, January 24, 2010
- 20. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Task Analysis Sunday, January 24, 2010
- 21. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Sketching and Rapid Design Sunday, January 24, 2010
- 22. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Teaching the Design Studio Method Sunday, January 24, 2010
- 23. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Presenting Sketches Sunday, January 24, 2010
- 24. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Day 2: Design Review Sunday, January 24, 2010
- 25. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Critiquing the Design Sunday, January 24, 2010
- 26. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Paired Programming Sunday, January 24, 2010
- 27. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Day 3: From Prototype to Production Sunday, January 24, 2010
- 28. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Craftsmen at Work Sunday, January 24, 2010
- 29. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 Day 4: Finish and Launch Sunday, January 24, 2010
- 30. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 31. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 32. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 33. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 We didn’t meet our goal... We exceeded it. Sunday, January 24, 2010
- 34. Agile User Experience: Two Tales and a Conversa9on RUX + AgileRichmond – January 10, 2010 ...we raised $5,400 during Jared’s talk ($2,700 from app with $2,700 matching funds) www.manoamano.org Sunday, January 24, 2010
- 35. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Tom’s story Tom Illmensee illmensee@gmail.com Sunday, January 24, 2010
- 36. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 U.S. economy – 2007/2008 S.S. Short Circuit hNp://www.flickr.com/photos/amphalon/489866219/ Sunday, January 24, 2010
- 37. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Wireframes >> days/weeks Plan usability study >> 1 week Recruit users >> 1.5 weeks Conduct sessions >> 2 days Analyze data >> 1 week RecommendaJons >> 3 days Write report >> 1 week Sunday, January 24, 2010
- 38. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 39. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 hNp://www.flickr.com/photos/gabriele/68282411/ hNp://www.flickr.com/photos/opera-‐nut/2752861268/ Sunday, January 24, 2010
- 40. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 41. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 42. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 43. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 44. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 45. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 46. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 47. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 “[Customer] research collateral, including original paper prototypes, were all prominently displayed [in Agile work rooms], giving the en9re team a sense that the [shopper] was always in the room. I heard repeated feedback that team members from the QA and technical teams were especially interested by this new way of seeing things—it really opened their eyes to designing soluJons for people.” -‐ Senior Business Strategy Manager Sunday, January 24, 2010
- 48. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 Sunday, January 24, 2010
- 49. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 hNp://www.flickr.com/photos/lorda/129806123/ Sunday, January 24, 2010
- 50. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 “One of the responsibili9es of soaware development is to assure that the right product is being created, and then to create it in the right way. The only way to accomplish this is to apply the best prac9ces of programming, design, and all of the other associated disciplines and craas. *TRUE* agile means integra9ng these craas into a joyful, unified, produc9ve whole.” -‐ Alan Cooper “Usability's role in a design project is to be the source of truth about what really works in the world, as opposed to the team's hopes for what might work.” -‐ Jakob Nielsen Sunday, January 24, 2010
- 51. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 hNp://www.flickr.com/photos/15302763@N04/3386432469 Sunday, January 24, 2010
- 52. Agile User Experience: Two Stories & a Conversa9on RUX + AgileRichmond – January 10, 2010 What’s your story? Sunday, January 24, 2010
Hinweis der Redaktion
- CC in crisis. The company’s stock price was plummeting. Market share was eroding. leadership looked desperately for new modes of strategic flexibility and fast execution. The e-commerce division saw Agile as a means to accomplish more, faster – and as an antidote to waterfall’s long and cumbersome cycles. Agile > navigate better through the stormy seas ahead by quickly improving and expanding the web site’s capabilities.
- CC in crisis. The company’s stock price was plummeting. Market share was eroding. leadership looked desperately for new modes of strategic flexibility and fast execution. The e-commerce division saw Agile as a means to accomplish more, faster – and as an antidote to waterfall’s long and cumbersome cycles. Agile > navigate better through the stormy seas ahead by quickly improving and expanding the web site’s capabilities.
- What were all of these UX bottlenecks? Wireframes and diagrams could take days or weeks to develop and were often entwined with detailed, written requirements and use cases. The bigger jam was around research. It could take weeks just to plan a usability study. It could take a month to conduct usability sessions, analyze all the data and write recommendations (listed in epic reports). We knew this was a problem. And no matter how much we protested, the Agile train was not going to slow down for us.
- The bottleneck factor was evident in how the Agile rooms were arranged. UX tasks were so long and time consuming they were not even associated with user stories. We had our own parking lot far away from the task board. Needless to say, this symbolized an “us” and “them” dynamic that was not going to lead anywhere constructive. With Agile’s emphasis on development and engineering tasks – research seemed irrelevant at worst and additional at best for mission success. It was too cumbersome – and results came too late. Some on our team got upset. Suddenly we were back to justifying usability – and feeling like engineering was racing ahead without considering the needs of users. It was a UX nightmare.
- Agile was not going to slow down. We had to get faster. It was at this point Alyson and I realized Agile was kicking the beat and playing the chords, and maybe it was our job to find ways to harmonize with it. Agile can be defined as “the ability to move with quick and easy grace.” Kind of like this Finnish speed metal band. They are STRATOVARIUS! UX was trying to jam with Agile - the speed metal band – with something like these alpine horns. Slow and deep does not rock. Our problem: Planning and recruiting for usability tests could take a week or more. Running protocols with up to 8 users could take us up to 12 hours. Data analysis could take another week. The report takes a week to write – and a week to read. About 4 weeks – tough when sprints are only 3. No wonder we couldn’t keep up.
- Inspiration and advice. Desiree CEE, Jakob Nielsen, Carol Barnum, Jared Spool, Jeff Patton, Frank Maurer – all have explored in great detail the nuances of end-user research in Agile environments. In the handout packets you’ll find a list of articles Alyson and I found helpful. We absorbed their recommendations and crafted an approach tailored to our environment.
- The idea was to compress all the steps to fit within a week. Here’s the basic pattern in 5 beats. Planning starts on Tuesday. Here we’re deciding what our questions are and how we’ll try to find answers. We finish the test plan and prep on Wednesday and Thursday. This might include some wireframes, design comps, or setting up a semi-functional prototype. We wrote task scenarios designed to help users experience the interface realistically. We handled test logistics, too: recruiting participants and getting our lab prepped. We ran usability tests on Friday – starting first thing in the morning. By late afternoon we had started analyzing data and dashed off a quick results summary for the team before leaving for the weekend. Monday we finished the analysis and got ready for a review session with the team. Tuesday we reviewed research-based recommendations and started planning for the next round of tests. Each beat was a minefield of potential bottlenecks. Here’s how we dealt with them.
- Here’s a rough mockup for a feature designed to collect email and cell phone numbers from customers who want to receive an alert when a TV goes on sale. We wanted to know if shoppers understood the service and find any potential design flaws. Essentially we wanted to observe users interacting with the stuff before we coded it. We catch the big problems at this early stage so we don’t have to do a lot of rework later. We would often test with conceptual sketches like these and wireframes. We usually had an hour with each shopper, so sessions might include a variety of stuff: paper prototypes, mock-ups, semi-functional prototypes, even stuff in production. We usually conducted short interviews with customers about their shopping habits and preferences to break the ice – so over time we collected a lot of useful data we could have used for personas. We would write a script with scenarios to help shoppers understand the task and context of use. Let’s talk about another bottleneck: recruiting.
- So we have our test plan, a script, prototypes, and 5 users scheduled and ready to go. Here lurks another potential bottleneck: access to a lab. Professional labs are great, but they can be expensive, too elaborate and inconvenient for busy teams. So we took Jared Spool’s advice and found an alternative: a conference room at HQ. This had lots of advantages: Easy for us to set-up the room and control the environment Easy for team members to observe sessions – they just had to walk down the hall. No additional cost
- Here’s how we set up a typical conference room for tests with semi-functional prototypes. On Friday – test day – our first participant – Joe shopper – would arrive around 9. Joe sits at the head of the table in front of the computer. That’s me sitting next to Joe. I’m listening, making notes and asking questions. My team members are in the room, too. They sit at the front of the table and can see what’s happening on the screen. This arrangement lets everyone see things through Joe’s eyes – they can even talk to Joe at the end of the session. This arrangement was something new in our organization. We were used to labs with mirrors and observation rooms. Having everyone in one room was a leap – but it worked phenomenally well. Users did not seem distracted by the observers, and observers seemed to be more attentive. Observers knew not to make changes until all the sessions were complete and only after recommendations were discussed as a team.
- We had other configurations depending on what was in the test plan. Here’s a lab at a local store. Stores provided convenient access to our users. We usually exchanged a $25 gift card for 25 minutes of feedback. If Alyson were here, she would tell you about her many spur of the moment research expeditions – with QA and business analysts running protocols and collecting the data. The stores were usually noisy – and shoppers with 30 minutes to burn were sometimes hard to find. But this worked in a pinch. Fact is, your lab is wherever you are collecting data. It doesn’t need to be fancy.
- On a related note. If you’ve observed formal usability tests then you’ve probably seen some of the gear involved. Cameras, mirrors, microphones, Morae software for video playback and session analysis, electrodes (kidding), eye trackers. All great and powerful tools – and in our case, bottlenecks, too. Why record hours of sessions if you and your team have absolutely no time to review later? The best data collection tools for the job – in our situation: a laptop or paper prototype A digital camera (for paper sessions) Active listening skills Notebook and pen By the third week we were simply logging observations by hand -- noting significant events (clicked button on page X) a comment (didn’t see grand total change, seemed confused) and severity (high).
- The Agile rooms were plastered with these research guides and prototypes. After a few weeks we were literally immersed in research. This helped reinforce the teams’ awareness of usability and the plight of our shoppers. This quote from a senior business strategy manager shows how research affected the quality of the work and team culture. We did get into a pretty good rhythm, and by the 3rd or 4th week Agile rooms started to look a little different.
- UX tasks – now leaner and more efficient – we’re easier to include with engineering tasks on the board. Stand-ups covered all the efforts of the team, including research. Not only that. Alyson and I relaxed the boundaries of our discipline – we let others help with the research and design and we took advantage of opportunities to help out with QA and development tasks. There was transparency. By the 7th week there was a distinct blurring of lines between roles. UX got involved with QA, QA got involved in UX. Developers made wireframes. BAs were observing shoppers and collecting usability data. Teams felt involved and proud of the UX efforts because they were making a difference – we were making informed decisions based on data – while keeping shoppers central in the process. Demos featured highlights from weekly research sessions. Insights from research were a team product! All this speed did come at a price. Turns out bottlenecks do have some value – they provide opportunities to pause, to catch your breath, to reflect.
- Maybe it was the frantic, desperate environment of a troubled company. Maybe it was our own reckless ambition – but we got tired. Fatigue was becoming an issue. But we were not the only ones dragging! Velocity, the number of stories attempted in iterations – and long hours taxed the teams to their limits and affected morale. Has anyone experienced fatigue in Agile? Here’s an opportunity for further research: fatigue and burn out in Scrum. On top of this the sense of desperation within the company just intensified. Weird emails from leadership about cost cutting* and the tumbling stock price added more stress to an already intense environment.
- Our story is nearly at the end – so I’d like to reflect on why research matters in Agile. Why did we work so hard to make it happen? Was it worth the effort? When it’s done carefully, efficiently, and creatively usability brings truth to the table. And truth, when it’s accessible and timely, leads to better design decisions. Better design decisions produce functionality that is easier and more satisfying to use. Which was really the essence of Agile in our environment. To build quality stuff quickly, fluidly and collaboratively. Alan Cooper wrote recently about the need in Agile to build the right product – and to create it in the right way – drawing on the skills of all disciplines. This notion , combined with Jakob Nielsen’s idea that the role of usability is to be the source of truth – help to summarize our experiences with Agile UX.
- The secret is simple. Agile has its own rhythms – its own cadences – its own song. It’s a Swedish metal band. User experience can be successful in Agile if we listen to its beat – find the groove – and improvise melodies over that groove with the right instruments. And understand Agile tends not to play the slow ballads. It’s gonna be fast and funky. Imagine Thelonious Monk playing Flight of the Bumblebee.