May 6th, 2009

What Verna Taught Me

When I was student at the University of Chicago I worked for Residential Computing, or ResCom. ResCom was responsible for maintaining all the computer labs and IT systems in the residential dorms.

I had two jobs. The first was to help manage the dorm computer labs. If a new virus broke out and computers were banned from the network because they were spamming everybody on campus, I had to go in and clean it up. I still remember when the Blaster worm infected most of the Windows machines on campus.

The second job was to help build a web-based dorm management system called Chopin. This system was at the center of the daily operation of the dorms. Students could use it to submit work requests and report problems with the dorms. Staff could use it to send out mass mailings, sell students printing credits for the dorm printers, and any number of other routine tasks.

Enter Verna

Verna was a front-desk clerk at one of the dorms. She was responsible for helping students if a problem came up and used Chopin to get her job done.

She had also lived in Hyde Park, the neighborhood surrounding the University, for most of her life and just wanted to do her job without having to deal with whiny students or crappy software. Chopin was supposed to help her do that.

One day while fixing the the front-desk computer I asked Verna, “What do you think of Chopin?” She immediately supplied a laundry list of complaints. It didn’t work well, it was confusing, she never knew where to go or what to do, and so forth.

It would have been easy to blame her. Maybe she just needed better training or maybe she wasn’t trying hard enough. But that was all ego: I was just upset because she told me the product I helped build was pretty awful.

Her critique was absolutely fair. I had built solutions I liked for problems I wasn’t even sure existed. In fact, before then, I had never honestly talked to any of the people who actually used Chopin about the product itself. In retrospect that seems completely insane.

And watching her use Chopin I saw so much waste. She would click ten times where two would have sufficed. Some features would never get used, others used for things they weren’t intended for. Once I was there, talking with her and watching how she used Chopin, I saw that the whole process was messed up, from top to bottom. Most of her energy was spent working around problems I had caused!

Go and See

If my job hadn’t required that I work on Chopin and get out of the office I never would have even realized there was a problem.

That experience taught me that whenever I didn’t understand a customer’s frustration or thought that maybe they were feeling this way or that way I should just go ask them before building solutions that might be worse than the problem. When in doubt, go and see for yourself. Actually, scratch that: always go see for yourself.

Too often I’d pass off mere belief as knowledge, or generalize from a specific set of circumstances to a fundamentally different set of circumstances. Maybe this solution worked over there, but why should it work over here? The only people who can validate your product are your customers — everyone else, including yourself, can wait their turn.

Verna taught me that.

  • This is a great anecdote and totally true. I think the real dangerous territory comes when you actually use your own product - because you then think "well, I'm a user, so I'll understand what's needed." At least with Chopin, you didn't use it so didn't have any illusions about whether you needed to observe a user.

    Last summer, before we launched Connect, one of the most humbling experiences was watching user testing. We put the users in one room and asked them to use The Run Around (since we didn't have any partners up yet). The developers sat in another room watching a video. We pulled our hair out while the user looked for the button to login ... we were like "it's right in front of you!" Eventually the analyst pointed it out and the user said "oh, I thought that looked like an ad." We fixed it to look like a button.

    So yeah, definitely humbling and it takes a good software developer to not get defensive when given honest criticism.

    BTW I second Martin's book recommendation, it's chock full of great examples and ideas.
  • That's a good story. You should write about it w.r.t. your work on OpenID!
  • Martin
    Good post I did the same mistake sort of but then I read Bill Buxton's awesome book and I saw the light. The problem in software development seems to be the collected experience only goes so far back, and think because the product cost is small compared to the product cost of for say a car, prototype research gets low priority.

    http://www.amazon.com/Sketching-User-Experience...
  • Great post, it really highlights the importance of communication in systems development. Too many people forget that there is more involved than just technical skills.
  • So, did you fix it?
  • Haha. Chopin was huge, so it was more about the process than any specific problem.

    I changed how I approached it and spent more time talking with the front desk clerks to see what they needed before I started coding away. Since then that's what I've always done, because otherwise I run the risk of wasting my effort and my customers' time (and possibly money).
blog comments powered by Disqus