RUX Agile Jan 10
by Regular Joe Consulting
- 1,482 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 ...
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
Accessibility
Categories
Upload Details
Uploaded via SlideShare as Adobe PDF
Usage Rights
© All Rights Reserved
Statistics
- Likes
- 3
- Downloads
- 15
- Comments
- 0
- Embed Views
- Views on SlideShare
- 1,474
- Total Views
- 1,482
j9w
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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).
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.
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 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.
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.
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.