I had the opportunity to present a brief overview of how to use user stories to facilitate iteration planning.

The accompanying presentation details a recently completed engagement for a VOIP services company in which we paired down the existing product requirements documentation and prioritized user taskflows to be built in the alpha release.

The mantra of User Centered Design is "involve users throughout."  To a manager concerned about time, budget, and the project plan, this can seem like a logistical nightmare.  For internal application projects this can mean business analysts and interface designers are directed to get requirements by proxy from end user's managers.  Too often, this approach leads to analysis and design failures not caught until user acceptance testing at the end of the release cycle. 

It is paramount to leverage the "what's in it for me" factor to engage end user's at the beginning of the process. When end users feel ignored during the requirements phase they approach UAT as their only opportunity to voice displeasure with the development process instead of focusing on constructive feedback geared at improving the application they will have to use on a daily basis.

Let me start by saying layout and design are important. For the casual observer, usability means a visual design that is pleasing to the eye. Historically, web designers came primarily from print design backgrounds and as such, focused their talents on the static visual design aspects of early websites; headers, icons, logos, backgrounds, etc. While important, the implied focus of web design is too heavily weighted on expressing the individual creativity of the designer than it is on satisfying the needs of the customer.

Commercial websites and application must primarily address end user interactions to complete tasks efficiently and effectively. To that end, consider the following non-visual aspects of usability:

Aaah yes. Six months ago you discovered the prototype and scriptaculous javascript libraries. You've put together a sexy drag and drop demo with Ajax requests reloading content on the fly and convinced upper management that you hold the future in your hands.

Then comes the DOM bloating. Your test leads are struggling to automate testing and your dev team is now saying Struts ain't so bad after all.

Relax. Here's some practical advice to ponder before going all in with Web 2.0.

1. Define the business cases which support Rich User Interaction.
Not every web based needs animated transitions or real time lookups. Remind yourself that value is what the customer wants AND is willing to pay for.

Once the user classes are established, defining and mapping user goals allows you to verify that there are no redundant user classes.

Understanding the quantitative and qualitative criteria users set to define a positive user experience up front helps prioritize the user interface designers prototyping workload.