Agile and IXD Case Studies
|
|
|
| Allison | Teresa | Jack |
Case Study 1: AllisonWe have been following our own "home-brewed" version of Agile development for that past year. We are a young company, so this was the plan from the beginning.
We work in short (1-2 week) iterations. Deliverables may include task flows, wireframes, a prototype, and new functionality added to the working product. The project typically starts with an iteration zero, where we (usually the designer and project lead) do things like gather requirements, identify goals, document ideas, and outline the first "chunk" of functionality (goals, and activities that support those goals). The next iteration, or series of iterations, is focused on that particular chunk. I usually try to work 1-2 iterations ahead of development.
Our team is small, so we all sit in one big room. I interact with the developers daily, and with clients daily to weekly (depending on the project). We like to approach projects as a collaborative activity, and when our clients are local, we have regular in person meetings.
My biggest problem is staying far enough ahead of the development team to allow enough time for feedback and refinement. Also, because requirements may change at any time, one small change may impact a number of design decisions, and I don't always have enough time available to go back and reevaluate. So yeah, I guess my biggest problem is timing. The development team may only need a few days to implement something that took several weeks to design, so finding a good balance there can be tricky.
My other gripe about Agile is agile developers. ;-) Not all of them are bad, and most of them are *excellent* developers. It's just that some of the agile developers that I have worked with are very vocally against *any* sort of upfront design (see this blog post written by my business partner: http://www.robbyonrails.com/articles/2006/08/30/ agile-interaction-design), and so find my work to be pointless ("I could have done that"). My work has been called waterfall one too many times. :
Case Study 2: Teresa I currently work in an Agile environment. I'm fairly new to it, but am really enjoying it. We work with a 2 week sprint cycle. The product team (which UED is a part of), has a high-level concept (we call them themes) of what will be worked on two sprints out and is defining and writing user stories for one sprint out. As the UED resource, I try to do UED research for the upcoming themes that are two sprints out and actual design work for the stories for the next sprint. By the time engineers start building, the stories are designed and tested, so engineers can build with confidence.
I have definitely had to learn to work in a compressed product cycle. I don't have the luxury of spending a couple of weeks to do user research before a big project starts. Instead I have to figure out how to do UED research for a day or two for the next couple of weeks worth of work. I have found that it's a lot easier to get buy-in on research time when it's in smaller chunks and has immediate impact. But it is definitely redefining my definition of guerrilla UED tactics.
Since Agile environments force your team to collaborate far more often then in a waterfall approach, I have found it to be a lot easier to integrate UED into the whole process. I find that in more traditional approaches, UED documents get created and ignored or research gets put off as too time-consuming. I'm sure everyone has seen their research or validation time compressed due to a late project. I am finding this happens far less often in an agile environment, as long as I am willing to adapt my approach. I find myself doing more UED work and less evangelism than in any of my prior positions.
Instead of creating a ton of documentation, I disseminate my knowledge to the whole team as we build. We do use personas and scenarios, but we don't use a lot of other traditional UED deliverables. I rarely create site maps or process flows - they would just be out of date after two weeks. I haven't written a behavioural spec since I started here. But I do help write user stories and my mockups definitely add constraints to existing user stories.
Instead of writing formal usability reports, I maintain a design library where I include before and after screenshots, list design notes which include any validation metrics or usability findings that either influenced the change or supported not making a change. This is all done on our corporate wiki and is nothing like formal documents.
It's definitely required a lot of flexibility, but I see it paying off. I'm an integrated part of the product cycle, not just a resource that allows our company to say we have a user-centered design process. I'm a big fan so far.
Case Study 3 Jack I think "Agile" like any method should be considered a framework that you customize based on the constraints and opportunities of the project you're considering it for.
That said, I recently proposed a method for a project that leverages some aspects of "Agile", but doesn't follow it to the letter of official defined process. In our approach we proposed a traditional discovery and definition phase, then followed it with a sort of "setup" phase where would explore the overarching IA and interaction patterns that could be applied across multiple features.
This meant things like forms, search, navigation, methods for tagging, etc... There would also be a traditional graphic design phase in where you did the explorations, mood boards, comps and then applying the design across several represented screens.
From that point, we broke the rest of the design work into 8 stories (scenarios, high level feature sets, whatever you want to call them). We then sequenced the 8 stories based on priority and some other factors. Then, we decided to have 2 teams running simultaneously which included an IA, Graphic Designer and two developers. One team was focused on re-designing the core product, while the other team focused on new and significant changes. This insured that the work of the new and unknown was not slowing down the work of the baseline features of the product.
Each developed story would be approached through some traditional wireframing, but with the entire team and mostly on whiteboards. We would use digital photos of whiteboards as a way of capturing and sharing our work with the clients. We then would then extend the visual design, the developers would code the templates for that story and we would test the actual code with users using some dummy server side code to simulate the real thing. Any AJAX used would be part of the code and the test. Then we would iterate based on the findings.
Now of course there's a concern about integration and consistency so we proposed dealing with that in two ways. First, the entire team would be working together in one big room and my experience has taught me that "osmosis" tends to fix a lot of that. The other idea is to have an integration phase at the end to pull things together.
Some of the big advantages to this method....
So far, feedback has been on all sides...