From Look at it Another Way by Indi Young

The people who designed the bike talk about what the bike can do, but the rider wants to find out what she can do. In the former vocabulary: “We give you 20 gears.” In the latter vocabulary: “I’ve decided to bike to work twice a week, but I fear the pain of getting up that steep hill on the way there.” If the bike company were smart, they’d be talking about making it easier to get up hills while commuting to work, or suggesting alternate routes or techniques so that you’ll arrive at the office without needing a shower and a nap.

From the excellent introduction by Karl Fogel to Version Control with Subversion:

No one ever called the tech support line and asked, “How can we maximize productivity?”. Rather, people asked highly specific questions, like, “How can we change the calendaring system to send reminders two days in advance instead of one?” and so on. But it’s a lot easier to make up imaginary Frequently Asked Questions than it is to discover the real ones. Compiling a true FAQ sheet requires a sustained, organized effort: over the lifetime of the software, incoming questions must be tracked, responses monitored, and all gathered into a coherent, searchable whole that reflects the collective experience of users in the wild. It calls for the patient, observant attitude of a field naturalist. No grand hypothesizing, no visionary pronouncements here—open eyes and accurate note-taking are what’s needed most.

In February I’ll be traveling to Denver for the next Web Directions conference. Web Directions is officiallly described as “a highly focused conference and workshops for web designers, developers, UX and ID designers, and other web professionals whose day to day job is building web sites and web applications. It features two dozen world class experts, with a razor sharp focus on practical techniques and technologies you can use right away to build even better sites.”

I’ll be giving a talk on building empathetic corporate cultures and co-leading a workshop with Mark Trammell on setting up a user research program.

Beyond usability: How to build a culture of customer empathy

When everyone at your organization cares deeply about the customer experience you will build better, more inventive, and more delightful products. So how do get everyone to really care about and understand not just the usability but the overall experience of your products? Though it takes time, an empathetic corporate culture is not impossible to create and nurture.
In this session Juliette Melton will share several case studies in how to build a culture of empathy at your organization, including best practices for running usability tests, sharing web usage statistics, and developing user personas.

Know Your Users: How to start tomorrow with guerrilla user testing

Right now, someone, somewhere, is using something you’ve built. Who are they? Are they having a good time? It’s not that hard to find out.
User testing doesn’t have to be difficult or expensive, and shouldn’t only happen at the end of the product development cycle. The best and most useful research is distributed throughout the product lifecycle and can be done within a stone’s throw of your office using inexpensive tools. At this workshop, Juliette Melton and Mark Trammell will show you how to build an effective user testing program from scratch and how to keep it going over time.

Who is this workshop for?

This workshop is for those who want to understand how to learn about user experiences, including project/product managers, designers, and usability professionals.

What will you learn?

• A structured approach to building a user testing program
• Web analytics basics
• Surveying tips
• How to include coworkers in your research
• How to perform task analysis
• Recruiting testing participants tips
• Best practices when sharing research findings

(Wondering about the spaceship I would land in Colorado? Full lyrics here. Anyone who lived in Colorado as a kid will probably know it by heart.)

The ever-observent Killface of Frisky Dingo is displeased that a map is missing some essential information. “Oh, here’s a good idea — indicate north! Otherwise, it’s not technically a map. It’s just a drawing.”

I recently decided to cut back on media consumption and increase vegetable consumption in one swift move, by cancelling Netflix and Rhapsody subscriptions and joining a CSA (Community Supported Agriculture — basically a farm subscription). I was generally pretty happy with Netflix but didn’t cycle through DVDs frequently enough for it to be worth it. I thought that Rhapsody was basically OK, but had enough annoying bugs that I didn’t feel like it was worth keeping around.

Canceling Netflix was as easy as signing up for Netflix. The feedback mechanism was spot-on, as well; the cancellation page included a survey to provide feedback on why I was leaving, and the reasons listed were clear and well thought-out, as well as being actual weaknesses with the service. For example: “I am disappointed with the technical quality (i.e.the software doesn’t work on my computer or I am a Mac/Apple computer user) of the “Watch Instantly” feature of the service where I can watch movies and TV episodes instantly on my PC.” Even the closing message was kind and well-written: “From all of us at Netflix, thank you for your patronage and we hope to have you as a customer again in the future.”

End result: I did cancel the subscription, but I still have positive feelings about Netflix, and would be willing to re-subscribe in the future.

But then, Rhapsody. Sigh. I assumed I could cancel online. I was wrong.

I did call, and the office was closed. So I had to call back from work, which meant either bugging my office-mates or holing up in conference room. So imagine this scene — I’m sitting in a cavernous, echo-y conference room, calling the Rhapsody people, going through a phone tree, waiting on hold, and then finally getting connected to a human. And, not surprisingly, this was a very unhelpful person. I don’t think it was necessarily her fault — she had to work from a pretty bad script. For example, she asked me why I wanted to cancel, and I explained that the Rhapsody website is very slow, that my libraries and playlists kept disappearing, and that there were consistent problems with the sign in process.

Rhapsody employee: “So… the service is not interesting to you?”
Me: “No. The service is broken.”

She either had to make a selection from a limited number of items, or her English wasn’t up to understanding what I meant. Either way, this would be filed as a Bad Customer Experience. I wanted to give my feedback and they didn’t want it or didn’t have a way to get it.

And then I got an email from Rhapsody, with a link to fill out a survey. I didn’t have time to respond immediately, so had to wait a couple of days. I really did want to let them know about the technical problems I was having as I thought it could be useful to them.

Alas.

I know they’re lying when they say they value my “time and opinions,” since they 1. wasted my time and 2. clearly aren’t enormously interested in my opinions.

End result: I will never re-subscribe to Rhapsody and would dissuade anyone else from joining. I had been on the fence about it, but no longer.

Subscription services generally see a large percentage of their subscribers cancel and return. Why antagonize people who are canceling? They are a lot more likely to return as customers than the average web user. Making customers jump through hoops to cancel won’t keep them leaving, but it sure will keep them from wanting to come back.

Oh, and the vegetables we’ve been getting every week from Terra Firma Farm are amazing.

Found in today’s nytimes.com, a compelling proposal for a ballot re-design.

Jakob Nielsen just released his list of the 10 Best Application UIs of 2008

Here’s what he had to say about how the winners used usability research to build superior products:

Usability Methods: Cheap but Contextual

The winning designs are revolutionary, but there’s nothing revolutionary about the usability methods employed to ensure their quality. The teams used well-known and long-established usability methods that I’ve advocated for decades.

These winning methods deviate from most companies’ usability efforts in two key ways:

• Most winners used a very rapid approach to usability, emphasizing small-N user testing and paper prototypes to generate user feedback before investing in coding. Several teams squeezed a large amount of usability work into a budget of only 80 hours. This is perfectly reasonable, and proof that good results can come from small investments — as long as the designers actually follow the user research findings.
• Many winners conducted field studies or other forms of contextual research in the workplace. After all, when you’re designing mission-critical software for print shops, you need to move your precious behind out of the office and into some real print shops.

I grabbed this screenshot from an amusingly unhelpful page of help documentation.

Want to learn more about how to set up and manage a user research program within your organization? If so, you are humbly encouraged to vote for our panel for inclusion in next year’s SxSW: Developing Super Senses: Tools to Know Your Users. My partners in crime are Mark Trammell (Digg), Carla Borsoi (Ask.com), Andy Budd (Clearleft), and Nate Bolt (Bolt | Peters).

Vote early! Vote often! And if we make it, come prepared with good questions!

Amaztype uses the amazon.com API to pull search results for a given keyword, then returns results in the shape of the search term. My name returns a lot of different editions of Julie of the Wolves.

(Another great find from Kristin.)