Dedicated to pushing the bounds of the user experience by blending art and technology.
Tuesday, January 27, 2009
User Experience Designers... speak up!
A colleague posed a question to me today that I think is a very important question:
What are the best methods you’ve experienced with regard to incorporating quality usability practices into Agile software development?
Before posting my answer, I am interested to hear what all of you think.
4 comments:
Anonymous
said...
I don't know how to do it, but I know how NOT to do it. Each of our Sprints in Scrum are 2 weeks. What would be nice is during our bi-weekly UAT's to do user testing on features. We don't, and now, 4 months into it, we won't know how things work beyond our internal opinion until our soft launch in 30 days. While that's ok, I gaurentee you, if we even did just 1 hour ever UAT, aka 2 hours a month, we'd catch the majority of what we're going to find out end of month. Problem is, we won't be able to rewind 5 months of time to perhaps tackle some of those issues; we'll instead have 1 month to finish features AND attempt to fix those issues. My opinion anyway.
I hear ya. And of course, when you get to that last month which is more likely to fall off the truck... finishing the "real" features or fixing the usability problems?
It seems like a no-brainer to spend some time up front to design and ongoing time to test. Waiting til the end is probably the worst possible method.
I try to draw an analogy to building an office building. It is much easier to fix problems when you are working on a model made of balsa wood and foam core (or 3d computer model) than when on the day of the grand opening, there is a traffic jam at the elevators because no one thought about the actual flow of real people.
Silver lining, as Steve Krug, author of "Don't Make Me Think" says, "Any usability testing is better than none." So, at least we're going to do some. It just happens to be during the soft launch. Most of the main features will be done, yes, but our backlog has a ton more stuff we want to do. Prioritizing design changes over adding new features will be hard as we all collectively "feel" we've got the right interface, but I feel like we're too close to it and need outside, real users to bang on it. Again, better than nothing, but certainly not the optimal way to integrate it into Agile.
4 comments:
I don't know how to do it, but I know how NOT to do it. Each of our Sprints in Scrum are 2 weeks. What would be nice is during our bi-weekly UAT's to do user testing on features. We don't, and now, 4 months into it, we won't know how things work beyond our internal opinion until our soft launch in 30 days. While that's ok, I gaurentee you, if we even did just 1 hour ever UAT, aka 2 hours a month, we'd catch the majority of what we're going to find out end of month. Problem is, we won't be able to rewind 5 months of time to perhaps tackle some of those issues; we'll instead have 1 month to finish features AND attempt to fix those issues. My opinion anyway.
I hear ya. And of course, when you get to that last month which is more likely to fall off the truck... finishing the "real" features or fixing the usability problems?
It seems like a no-brainer to spend some time up front to design and ongoing time to test. Waiting til the end is probably the worst possible method.
I try to draw an analogy to building an office building. It is much easier to fix problems when you are working on a model made of balsa wood and foam core (or 3d computer model) than when on the day of the grand opening, there is a traffic jam at the elevators because no one thought about the actual flow of real people.
Silver lining, as Steve Krug, author of "Don't Make Me Think" says, "Any usability testing is better than none." So, at least we're going to do some. It just happens to be during the soft launch. Most of the main features will be done, yes, but our backlog has a ton more stuff we want to do. Prioritizing design changes over adding new features will be hard as we all collectively "feel" we've got the right interface, but I feel like we're too close to it and need outside, real users to bang on it. Again, better than nothing, but certainly not the optimal way to integrate it into Agile.
Yeah, as Jakob Nielsen points out in this post, zero testing will uncover zero problems. It can only go up from there.
Post a Comment