Tuesday, November 6, 2007

UI12 Day 1: Interaction Design in an Agile World by Larry Constantine


My first day was spent at a seminar given by Larry Constantine from Constantine & Lockwood. The focus of his seminar was about how User Experience professionals must adapt in order to work in a Agile Development world. This inherently causes distress on how all types of UX professionals are used to doing their jobs, but it touches every other department along the product lifecycle as well. It is a jolt to the UX community. One of the major themes that is difficult to digest is the idea of "evolving business requirements". His point that business requirements are already doing so unofficially as a product is developed is a valid one. We've all seen this. The tough part is to imagine a world where there isn't the map to design to provided by the business. This opens the door for input on product design from everyone, including users. I'm not sure how that will play out in reality.

One goal that Constantine is aiming for is to stop UX design from being a roadblock to the start of development. This is not trivial. This phase ideally occurs at the idea phase and involves important research. He wants to avoid "analysis paralysis" and recommends that only a minimal navigational and presentation schema is created to begin development. The focus shifts from user studies and user experience to activity modeling which evolve into business requirements. Personas become roles and scenarios become task cases. He recommends focusing on the "happy case" design and not to get bogged down with edge case "what if" scenarios.

This is a lot to swallow. This is a titanic shift for most companies that have a waterfall product lifecycle. This requires training and buy in from everyone to be successful. How does an organization get to that place? How do you avoid working the way you have worked your entire career? Interesting challenges here.

One very good result of this new process is that it affords much better traceability. It captures the "why" of decisions were made and demonstrates how they became requirements. This is very different from the 'this shalls' and 'this shall nots' of business requirements and functional specifications which typically lose this important bit of rationale.

You can learn more about Larry Constantine's work at his website, which shockingly has a very nineties "Under Construction" graphic and warning on its homepage: http://foruse.com/

No comments: