On User Interviews: The Lens of a Rubber Duck

These days I've been doing some user interviews for our software, Numenon.

What are user interviews?

Well, for me, that's just a fancy way of saying I'm hopping on calls with users to watch them use the software. I walk them through the optimal usage of Numenon for their specific scenario, intervening as little as possible, to see where they naturally head.

While doing that, I note things like whether or not they find a button easily, what catches their eye, what they seem to grasp easily or struggle with, and so on. At the end, they give me open ended feedback and then we part ways amicably. Unless, of course, they say something bad, in which case I banish them to the depths of Khazad-dûm. Just kidding. Mostly.

Then comes the sorting of the feedback to actionable tasks, and whether these will go to a specific release or stay in the icebox until way later. It all depends on how often a specific issue comes up, weighed against our own evaluation (unsurprisingly, we're our most active users at this point).

Well, user interviews are a curious beast.

And in all their curiosity or greatness, they resemble a "rubber duck" situation.

What's a "rubber duck"?

Well, apart from the cute little toy one uses for a whimsical soak in the tub, "rubber duck" is also a development term.

As programmers, we spend a large part of our lives debugging (often more than coding), and we frequently get stuck. Sometimes, when you describe an execution flow from start to finish to someone else, your brain hits that 'a-ha' moment and you suddenly spot where the bug lies.

But programming is often a solitary profession, and you might have no one to talk to. Enter the rubber duck. You plonk it right next to you and tell it all your coding problems. I guess you can do it with your relationship problems too, but it might start charging you.

Ok, back to user interviews.

They can be extremely useful or dangerously misleading.

And it’s mostly about detecting patterns.

If a certain number of users have a difficulty with x or y, then you know you need to work on x or y. Or, if a specific workflow sparks joy, lean into it. Keep it, protect it, maybe give it a bit more spotlight in the UI.

But you must be careful not to put too much focus on one user's opinion. She may be convincing, present great arguments, but she is still just one data point. You must not allow yourself to get carried away. Note the feedback, but don't act on it yet. Unless...

Unless she is the archetype for your target audience. If she perfectly represents the specific group you are building for, then it doesn't matter that she's just one, her single voice carries the weight of a whole audience.

A lot of variables to juggle.

But, in any case, regardless of whether the feedback itself is directly applicable, the process is always useful.

And here is where the rubber duck comes in.

The rubber duck lens

By walking through your app with a new user, you see it through their lens, a new one.

That's the most valuable part of it all, I think. Having the opportunity to view your app with fresh eyes. And that has both positive and negative aspects, in the sense that you'll probably see A LOT of things that need improvement, especially during early stages.

But, you also see it as a creature of its own. A wonderful creature that you fall in love with all over again.