Tracking the tools that decentralize the media. tools process ideas resources eventsav

unmediated

 

March 18, 2005

A month ago I participated in the Open Source Usability Sprint.

For me it was revelatory. Something I started doing last August and September with Tantek Celik, at Technorati (I used to work there). We would sit, side-by-side, working on the usability of the site, where we picked through about 50 little niggling problems that I'd found over the previous 9 months (yes, I'd found more.. but fixing 50 was great) to make those little problems go away. We started out deciding just to fix a couple of things, so I took him through the user's perspective about why something might be broken from their perspective, and it was boring, tedious, time-consuming to do this.. and yet.. immediately as we refreshed the changes, we would both see the improvement and understand how users would like the change. So we fixed another and another.

These were problems that I knew about, had documented, or had found in several rounds of user testing. I did what is common in usability, documenting these issues. The engineers would read the reports, comment on them in conversation, quote the user's, and generally agree. But then, nothing would change. And that's not to say that these engineers at Technorati, or the ones I've worked with elsewhere, weren't brilliant or personable, or desiring of good usability and user satisfaction. They are.

But the reality is, written reports, while read and interesting to engineers, are hard to translate into change. But this extreme usability (we didn't call it that then) actually worked (though I left Technorati just after so it didn't continue there that long).

One thing to note is that this sort of extreme usability takes different forms depending on the stage of engineering development. I have worked with it at early state needs assessment and prototyping, in the form of rapid iteration during development of working software and web services, and even well after a site or software has been in use. What is important to know though, is that all the usability work that would normally be done, whether needs assessment, user profiling, interviews of one sort or another, or led discussion focus groups, has to be done on the usability side, and reporting and documentation is still necessary. But after that, extreme usability or pair programming with engineers is very effective, just as engineers will spend time coding and developing before they get to the pair programming session with a usability person.

This fall, I worked with several engineers, and I just insisted we sit down, and pick through the problems side-by-side. Wow, they said. This is fantastic, we are making really good progress and users are responding quickly and favorably to the changes!

By the time we got to the Usability Sprint in February, where we did this for three days, and named it as extreme usability, I have become fully convinced that this style of usability and engineering partnership is really key to the next generation of interface and information architecture development. It's pair programming. And I highly recommend it.


Originally from Napsterization, remediated by yatta on Mar 18, 2005 at 01:54 PM