Framing a prototype for user feedback

While throwing a prototype on the table with little to no preamble to solicit feedback might make for a thoroughly fascinating observational study and examination of human reaction (loaded with critical cultural theory, no doubt), it’s actually not very helpful for the designer trying to ascertain clarity about which direction to pursue. The fact is everyone approaches something with some background knowledge and expectations shaped by culture, language, metaphors, prior experience and learned skills. What is that basis? That’s the real trick and challenge of designing for your intended market, to make your product seem “intuitive”, which is to say, mapping to inherent and acquired patterns of use. I realize this might rankle veteran researchers in the field, but here’s what I’ve learned and realized about prototype testing:

A user feedback session is really a mediated dialogue. We’ve all heard the refrain, “we’re not testing you, we’re testing the product.” That’s actually bullshit. You’re totally testing the user to see if they are grasping the presented concepts. Instead, we should be saying, “We want to learn from you if this concept is successful, and if not, how we can best improve it. Let’s have a dialogue, using this prototype.” 

Prompt their “think aloud” approach with why and what if. Yes, let them struggle but also help them be successful. Probe with specifics without the anxiety or fear of “giving it all away”. I understand the fear of introducing bias, but honestly…get over it! The fact is in the real-world a user approaches a product already having been biased by the advertising, branding, social marketing, contextual framing that’s latently happening all around. Attitudes and impressions have been or are being formed already—so deal with it! :-)

You need to frame up the scene and addressed problems or foreseeable opportunities. Having the user assume a particular role and use case helps greatly. Is this an app to be used while commuting from home to work on trains and subways, or in the privacy of your own car? Suggest issues that might arise, like loss of wireless network, or limited data plans, or forgotten charger. How would the user react to these moments, in light of the app or device being designed for? You need to prompt such considerations to enable that mediated dialogue.

I realize this flies in the face of most research protocols but you really need to coach and guide a user through what it is their interacting with. You can’t simply throw down a paper prototype of a phone app UI without telling them, it’s a Phone App UI and expect effectively applicable inputs. Even basic framing of what it is, the context and device, is essential. Else you will waste the user’s (and designer’s) time with puzzling poking around, which isn’t helpful information to make a decision that will move the product forward.