Friday, January 30, 2009

User Experience Designers...Listen up!

A couple days ago I posted a question here (and on some other discussion lists) regarding how usability can fit into the Agile process. I revised it slightly and added some clarification:

What are the best methods you’ve experienced with regard to incorporating quality design & usability practices into Agile software development?
There is some debate in the software industry regarding the scope of UI design work to be completed before Agile software development can begin. What are your thoughts? When is a detailed prototype necessary? When is it not necessary?

I promised to post my thoughts so here they are.

The method that I am currently using involves some upfront design time which I consider the architecture phase. During this phase is when you gather and process all the data about various types of end users and their goals. Throughout the architecture phase, we work on low-fi wireframes and/or mockups that address high level global interaction patterns such as type of navigation, inline editing vs. popups vs. separate edit screens, etc. I liken this to the engineers' decisions to use a particular technology, library or persistence strategy. Some of this stuff needs to be thought out early since changes later are expensive and destabilizing. Because, end user satisfaction is a top priority for our customers, I propose doing usability testing during this phase (and all through development). 

While wire-frames and paper prototypes can certainly be tested, we have found that nothing works as well as a clickable prototype. Someone suggested above that just build the real thing and test that. We have repeatedly seen that a very detailed prototype can be built in 4 to 6 weeks where the actual product can take 6 -12 months. Of course with agile development you have something every 2 - 3 weeks but it does take a while to get to something that can be a true test of the user experience. The level of detail in the prototype and wireframes/mockups is really determined by the complexity of the interaction. If one pattern can be reused, there is no reason to prototype every use case of it.

This process can work very well but requires some commitment of time before development begins. This doesn't have to be a year long effort but depending on the type of application somewhere between weeks and months seems appropriate. Regardless of the amount of time required, this is often labeled "Anti-Agile or Waterfall". 

What lead me to asking my original question was my desire to know how others are doing it from a tactical perspective. Can the process I describe above scale? Is it truly anti-Agile? If it is, does that really matter if the result meets user's needs better? 

If the goal is to deliver really good software, not just really good code, I am ok with being slightly less Agile.

Thursday, January 29, 2009

Do prototypes help or hinder the Interaction Design process

Almost ten years ago, Alan Cooper (author of About Face and The Inmates Are Running the Asylum and my personal hero) of Cooper wrote a journal article titled "The Perils of Prototyping". It made me think about today's software and the way in which we designers communicate our vision to developers. I posted a comment on that blog asking this question:

"Do the capabilities of today's tools and the expectations of today's users change the need for prototyping?"

The reason I ask is because it isn't as easy to test interaction design patterns on paper if they require visual transitions, sounds, tactile responsiveness (on touch screens), vibration (think Nintendo Wii).

I have seen numerous times that communicating complex interactions to developers with paper mockups, or even digital mockups, is far more difficult than showing a prototype that actually does what is required. 

I have also heard first hand from developers that say a prototype really helped them with the details. Not only does it display how the software should behave, it provides and idea of how it might be implemented. This might be unique to the fact that the prototype built with Flex was for an application that was also built in Flex. So there was the ability for direct reuse of custom components, etc.

What do you think. Is there value? Can it work in an Agile environment? Or is it still as unnecessary as it was ten years ago? 

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.

Monday, January 26, 2009

Handy IPhone app for... Flex/ActionScript developers?

Mike Chambers released a cool little reference guide for Actionscript for the IPhone. Now, to me, there seems to be something wrong with using an IPhone app to create RIAs that won't run on the IPhone. Plus, if I am in Flexbuilder working on a Flex app, the Actionscript reference is only a key (ok... two keys Shift + F2) away.

But, since I have a new found love for my IPhone, I will probably install this to check it out anyway.

For more info, visit Mike Chambers' blog or you can find it on the App Store.