vanderwal.net

Last evening I was chatting with Nate Bolt who mentioned he had done some usability studies with a large client who brought their developers with them to watch the studies live. He mentioned that the developers would go back every evening an code the site/tools they were testing and then test the new site the next day. Others that were chatting thought this was nuts, which a year or two ago I would have thought the same.

A couple years ago I started talking to people doing development and usability sprints that start-ups, open source projects, and small development teams had been trying.

Usabilty Test Built into Sprints and Hack Days

In the past year I have talked with at least three teams working on projects that are doing one-day to four-day sprints or hack days to gather information from usability tests regarding how people use or are unable to use their products as well as collect wish-lists of desired product improvements. In the multi-day sessions some of the identified front-end tweaks and quick development tasks are knocked out, tested with people who use the product, and iterated a few times. The instant feedback on tweaks is very helpful and allows for rapid product development.

Quick Fixes and Long Term Tasks

The time between the intense sessions are used to build the deeper and more wide spread changes. These release cycles are now quicker and more on target. One project also has done usability sessions in addition to the intense sessions to catch some of the more subtle issues (with people new to the sites/tools as well as those with long term use).

Listening and Fixing Before Their Eyes

I definitely see the strong advantages of the intense sessions mixed with the usual longer term development. Finally it seems a broad section of the development world is finally learning that the best way to build out stuff is to sit with the people that use it, see their pain and frustration. But, even better is fixing that pain overnight. These intense iterations build positive feedback for the developers and designers on the projects, the business owners seeing quick improvements, and the people who want and need to use the products. The people using the tools will most likely go away and become evangelists for the products as the developers and designers not only listened to their needs, but fixed it so it worked better for them right before their eyes.

What It Takes

This approach not only takes solid developers and designers, but smart project managers that can assess (more accurately triage) the needed fixes, prioritize the short term and long term solutions, assign and manage these quick solutions. Smart and passionate people is the key to these solutions as well as nimble teams.

Small Projects Get It, Will Enterprise?

I am wondering if the quick intense iterations will be where we are going. I definitely see it for the small and nimble. But, can enterprise iterate this quickly? Or will the hands that need to bless the iterations have to stay involved with meeting cycles that will slow down the progress?

I have been impressed with the discussions around Yahoo! Hack Days and Yahoo is a large enterprise with many meetings, but they "get it" (or are in the process of internalizing "getting it"). I think Yahoo is showing enterprise can get there. But getting there will take faith that the enterprise has hired well and have the right people working for (and with) them and the right managers in place that trust their developers and designers, but most importantly trust their customers and people that use, as well as want to use, what they produce.