Users aren't dangerous

Users aren't suffering from a highly contagious disease, but it sure looks that way given how hard some developers (and managers, and marketers) work to avoid coming into contact with a live one.

Bert was a software engineer for a company that sold software systems for managing broadcasting, so his users were radio and television station employees, and it was one of those dramatic examples of where the entire company revolved around the users. Everyone at that company--everyone-- had to do regular rotations through not just tech support but customer training.

Can you imagine that? Picture the programmer writing code knowing that at some point it'll be his butt in front of a room full of confused users. And confusion leads to fear, and fear leads to anger, and anger leads...

The difference between having to come face-to-face with a user and not is staggering. Those of us who've been "on the front line" (or to use corporate speak -- in the customer-facing positions) know how stressful it can be, especially when your job is to support a product or service that basically sucks.

But when you're safely in your cubicle, where users are simply an abstract concept rather than real flesh and blood, what's the worst that can happen? You get a bug report, or maybe even a stern memo from upper management when the complaint or tech support calls get too high.

Those of us who've worked the line scoff at your little memo...we're the ones who get ripped a new one when the work built by the safe, protected people isn't right.

I gave a presentation to an all-hands meeting for a division of Sun, and I asked the group to raise their hands if they'd met a live customer in the last 30 days. Couple of hands went up. "The last 90 days?" One more. "The last year?" Another two. There were over 100 people in that room directly responsible for deliverables that went straight to users... in this case, Java training courses.

Without really talking to users the best you can hope for is to meet their expectations. You won't be able to craft that extra special magic that makes them passionate if you don't talk (and listen) to them.

This flies in the face of some software development models (and course development models) that believe if you've done your specifications right, there should be no need for the "workers" (programmers, writers, etc.) to ever come in contact with real users. That's just nonsense most of the time. Because even common sense tells us that what users are able to articulate before they have something is rarely a perfect match for what they say after they've actually experienced it. It's just like most market research... people can't usually tell you in advance exactly how they'll react to something. They just have to try it.

You just have to be there to watch. And listen. And learn. And then take what you learned and go back and refine, which is why the old waterfall model is pretty much the worst thing to happen to users.

What if you aren't in a situation where you can bring users to meet your employees? What if there's simply no way to get your developers out to watch and interact with real users in the field?

I found someone with a video camera and we grabbed customers coming out of a Java training course, where I was hoping to get some of them complaining on tape. Because the image and sound of someone yelling at you carries way more emotional weight than, say, reading a nasty letter sent by even the most irate customer.

And I did get a little of that. But I got something else, something I didn't expect, that I believe had a much bigger impact on all of us. Because what the customers wanted to express was how important this learning was to them. Course developers got to hear students explain what their courses really meant to these users--complete with fears ("Will I be able to learn it in one week? Will learning Java be enough to save my job?"), hopes ("I'm planning to take the exam next month and then transfer into a better department.), and dreams ("I'm going to use Java to program a game to teach kids the effect of ecological changes").

The developers got to hear how their work had a deep impact on real, living, humans. People with names, faces, and voices. From that moment on, the employees who watched that video lost the luxury of seeing customers as an abstract notion, and forever had the sound and image of real humans to haunt them when trying to decide if something with errors was still, "good enough to ship."

If you're a manager, I'll assume that you spend time with users. But if you don't make sure that your developers do, you're robbing them of the chance to learn first-hand just how important their work really is. It's so easy for so many of us to forget that the result of our work ultimately touches another person's life in some way.

Of course one of the downsides of creating passionate users is that when you do meet them in person, they might just want to hug you. : )