visiting customers

Visiting customers in the environment in which they use your product is the single best way I know of validating assumptions about design. It's also nearly free and engenders ongoing conversation and good will.

Despite this, companies tend to resist building in time for direct feedback or leaving the building to obtain it. At the last company I worked at, we actually got in trouble for visiting customers! Often Sales worries about what Development is telling/promising users. In that case, you could bring Sales along, or find less important customers to visit.

Personally I don't see any point in being a Pollyana. Bugs are bugs. Part of the way you gather requirements is listening to dissatisfied customers. You probably have more to learn from them than from users who send you fan mail about how the product changed their life. And from a PR perspective, if you can turn around dissatisfied users, they tend to become your biggest advocates.

I should probably distinguish here between customers and users. With consumer software, they're the same people. But in business software or in the educational market, customers are purchasers or stakeholders. They may control the cash, but they are also gate keepers. They set standards and evangelize within their organizations or spheres of influence. However they may not use your product day to day or ever, and while they think they speak for the people in their organization, it's always better to hear it directly, especially if your focus isn't just selling another upgrade but delivering a pleasurable user experience.

When a client tells me they don't visit customers or don't have time to do so, this is a warning sign. It indicates a company that is either on such short deadlines that they're nervous feedback will endanger the schedule (a common problem and easy to sympathize with) or more worried about politics than quality. Either way, it's easy to fix.

Unlike usability testing, establishing relationships with your customers in their place of work isn't expensive, nor does it require following an established methodology. You just have to set expectations properly and let them talk more than you do.

You visit customers not so that they can tell you how to design your product but to listen to their problems and better understand typical workflow. Users may not always be right about solutions, but they are always right about problems.

When we were working on Kid Pix this past year, we heard a lot from administrators and teachers about what they needed. But it wasn't until we visited elementary schools that we fully understood how difficult entering text or saving a file to a server was for a six year old.

It's one thing to hear that users want more levels of undo and something else to see a child who has worked on an assignment paintstakingly for an hour or more accidentally spill paint across the screen or overwrite the wrong version while saving a slide. It was worse for a six year old who had grown up without a computer at home, in a lab setting only forty minutes a week, surrounded by twenty other rambunctious kids.
You also don't need to visit a lot of customers to come away with key data. The best time to visit is after your core team has outlined a common understanding of the problem and requirements for solving it.

The purpose of the visits is to prove and disprove that model and to look for new information, data a happy customer might not report over the phone but that will be readily apparent in person.

What books and magazines are they reading? How busy is their company and what percentage of time do they spend using your software? How old are their workstations? Do they have offices or work collaboratively?

Be sure there are fewer members of your team than are being visited; ideally no more than three people should go on a visit, although I've brought as many as seven. If you bring a big group, you change the dynamic you came to observe. And worse, they'll put you in a conference room and present to you as guests of honor, rather than letting you be a fly on the wall.

After three or four visits, you'll either start hearing the same issues over and over, or you'll have discovered different segments of usage.

When I worked for Macromedia, I visited Director and Flash developers in Tokyo. I speak about fifty words of Japanese, most of them names of sushi, but within 10 minutes, I understood exactly the issues being mentioned because I'd heard them so many times before visiting developers in the US. At that point, I knew to listen for the differences between Japanese and American users rather than commonalities.

I'll write more about customer input in a future column, because contact with users is something I believe so strongly in, whether it's a phone call or an online focus group or a site visit. I say this not because I'm insecure about my own ability to define requirements and usage scenarios, but because I'm very good at it.

I've never failed to learn something when I visit a customer, and the products I design are all better for it. Besides, it's fun.


Tags: feedback, user experience