Hiring the Right Software

Found this today in a book on interface design. I don't think that I could have possibly given a better metaphor for how we should think about our users when we're doing interface design.

I, like many people (whether they realize it or not), tend to “hire” software the same way I would hire a person. I look for certain qualities, like a helpful nature, reliability, trustworthiness, and other things I’d expect to find in a good Boy Scout. Mostly, I look for software that can get work done in a smart and timely fashion so I can feel productive as a result of having hired the software – just what I’d want in a prospective employee. I look for characteristics that make me say “Hey, you’re swell. I’d like to work with you, take you under my wing, and invite you over for brunch. Come, join me in a game of Parcheesi.”

Software, however, often interrupts me while I’m working, tells me I’ve made a mistake, refuses to help out in a useful way when I get stuck, spends a lot time revealing things about how it works instead of simply telling me the job is done, and exhibits many other behaviors I find undesirable in employees. But usual I’m stuck with it. I can’t find a way to live without the product because it’s so valuable to my work, for whatever reason. I can’t simply trade it in for something that may or may not be better, so I suffer through it. I yell at it, procrastinate dealing with it, and complain about it, but I live with it. This, of course, bugs me to no end.

Designing the Obvious, Robert Hoekman Jr.

Really like the metaphor here.  Every time I help people look for ways to implement technology as a tool to help make their lives more efficient, I find that a similar conversation has been playing out in my head.  If more people start thinking about the end user of the software "hiring" it to do a job and working on making the software shine as that "employee" we'd all have a lot fewer frustrated users.