Users do not care about what is inside the box, as long as the box does what they need done. (Jef Raskin)

Think of your car. If you’re like me, you know that you put the key in the ignition, you start the thing, and you drive somewhere. Oh, sure, there are some other details – turning signals, reverse, headlights, filling the thing up, taking it in to get the oil changed ... But that’s pretty much it.

I can’t remember the last time I opened the hood. Actually, I do!. But it was only because something was wrong. My battery had run out, and I had to get a AAA mechanic to come give it a charge. I opened the hood for him, then peeked inside. Yeah, I could make out a few items – the battery, the air filter (which I never change), maybe the windshield washer fluid, perhaps the radiator cap …

Honestly, though, I’m not a mechanic. I just care that the thing takes me where I want to go. 

Now, here’s the thing. As a user researcher, you may very well work with a bunch of mechanics. This goes without saying when it comes to the developers. I’m always kind of amazed, though, how interested designers, and business owners, and even content types are in technology in general and the inner workings of whatever they happen to be working on in particular.

If you think about it, though, they kind of have to. They really can’t help themselves. If they’re going to produce something, they have to care about the nuts and bolts, they have to get involved in the details.

User researchers, on the other hand, often stand a little apart from that. Our identification is primarily with the user. And the typical user is not the mechanic type, but really just someone who wants to buy a book, transfer some money, stream a video, reserve a plane ticket …

And what that all means when working with your team of “mechanics” is several things. First, there is the advocacy aspect. I find personas really work great here, but simply speaking up and getting teams back on track in general can be really useful. Another important thing to do is to occasionally bring up the idea of mental models – in particular, what they are, that users have them, and that the team’s mental models will tend to be a lot different than the users’. A final idea relates to pushback. I’m always a little amazed when I hear developers say that they can’t do a modal here, or that a table would be too much work there. I often think it’s a knee-jerk reaction, and the team really needs to orient less around what’s difficult for them and more around what’s good for the user.

For, in the end, your user base is going to be a ton more people who really just want to do the online equivalent of getting to work, or going shopping, or picking up the kids from soccer practice. Anything beyond that – or anything that gets in the way of that – may be of interest to a lot fewer users than the team might think.

Jef is mainly known as the guy who created the first Mac

(and, I guess, whatever weird thing that is on his head)