Thanks to all of you who came out last night for our Arduino workshop with Massimo Banzi. We will post a wrap up of the event shortly. The event inspired great conversation among our guests and it inspired us to to share our thoughts on the magic of low-fi prototyping.
What people say they like and dislike is often very different from what they actually like and dislike. So many people claim not to enjoy trashy TV—in fact they often scoff with contempt at the thought of it only to find themselves laughing their heads off at the Jersey Shore or Real Housewives of Wherever. We call this self-reporting bias, the phenomena of answering as one thinks she should, instead of how she really feels. Sometimes it’s not even about saying the “right thing” as much as the difference between a pre-conceived notion and an actual experience: I might not like the idea of bacon-flavored chocolate, and if you’d ask me I’d say so. But once I taste it I know I’ll be a convert to church of everything-tastes-better-with-bacon.
When designing products for real users, it’s important to understand both their expectations of how the products will work and how they actually use them in the context of what the products are meant to do. We often talk with users about their preferences and reactions to design ideas, but asking questions, while important, only tells half the story. Allowing users to try something out, experience a concept for themselves, often results in richer feedback and better ideas, and gets around the unintentional self-reporting bias. For example, ask non-iPhone users whether they would like a phone with only 3 buttons and there would be few who’d think that was a good idea.
At Kicker Studio we use low-fidelity prototypes wherever possible to test out our ideas. Because while users may think they’d prefer one solution over another, having them actually use the prototyped solution in context of their usual routine, as opposed to asking about their preference out of context, often reveals surprising results for users and designers.
Here are 3 things that we keep in mind when prototyping that can help you as well.
1. There is no experience like an experience.
On a recent multi-team project at Fort Benning, Georgia, we asked our research participants – Army infantrymen in combat scenarios – what they thought of the idea of receiving feedback in the field through haptic vibrations on their wrists instead of sound in an earpiece. To say they were skeptical would be an understatement. Five out of five guys said “no way.” They didn’t think they’d feel a vibration, and if God forbid they did, they it would distract them, or worse, give them a shock: “If I’m pointing my gun at someone and I get a jolt, that would be bad.” We noted their reservations–all very good points–and few days later we asked them to put their preconceptions aside and try a prototype that we had created to deliver vibration at the wrist, using an Arduino and Bluetooth that wirelessly controlled three different haptic frequencies from a laptop. We had the soldiers execute commands they were familiar with, in contexts that they were used to, and evaluate the experience of the haptic feeback vs their opinion of it beforehand. Unilaterally all of them changed their minds, and were eager to learn more about the role that haptics might play in our design solution. When you introduce the actual experience, not only do you learn new things about your users, but you also open up the conversation around possibilities that weren’t there when based solely on preconceived, self-reported preferences.
2. Keep it low-fi.
Using low fidelity prototypes, that aren’t super polished and detailed, helps to get at the essence of a design idea quickly, and allows you to iterate and shape the interaction cues and feedback in ways that aren’t possible with a full-polished solution. The rough edges in a prototype make it feel less precious, and help everyone to fill in the gaps as to how a solution might work best for them. This leads to more open-ended conversations about how to improve on an idea. For example, to prototype the status displayed on a hypothetical wrist monitor, we used index cards to write out the types of information available to the soldier, and when he looked to his wrist, and vocalized the information he was looking for from his monitor, we were able to quickly iterate on the display based on the ways he phrased his requests. This led to design details that better matched his expectations and provided more utility in context. For example, the difference between “what is my gas level?” and “how much fuel do I have left?” is the difference between a display that provides indirect information such as a fuel gauge, and direct information such as a display that reads “23% left – xx km until empty”. Our low-fi approach allowed us to change the information on the fly and try several ways of providing it, whereas a hi-fidelity display, while good for measuring readability, would have resulted in a “yay” or “nay”, rather than a “well how about this?” or “how might this work better for you?” And it’s those conversations, and the subsequent experiences, that make for better design.
3. The importance of magic.
While we certainly advocate low-fidelity prototypes, it is essential to imbue a bit of magic into the experience. Prototypes should strike a balance between a real and artificial experience. While too much polish can shut down opportunities for improving on ideas, you also want your users to believe in the basic elements of the prototype, and suspend belief long enough to immerse themselves in the experience. Ideal prototypes let the user focus on the specific task being tested, not on the cobbled together technology and wiring required to make the prototype work. The more distracting the prototype object or setup is, the less accurate the results. At the same time, it is important to be aware of what is made specific in the prototype. It is helpful for users to fill in some of the gaps so that the prototype can iterate in the next round. The more specific the prototype, the more likely it is that users see that specific element as integral to the way it works. If that is what you are testing, great. If not, that can be detrimental to the outcome.
Arduino certainly comes in handy in building low-fi prototypes, as it allows designers to easily hook up different sensors and actuators to bring a variety of interactions to life. We were able to distill the most basic element in the experience we wanted to convey, and we found ways for our users to experience that as naturally as possible, with as little interruption or distraction as possible. The soldiers who were resistant to the idea of haptic feedback in a wristband would certainly have balked had we hooked their wrists directly to a computer and asked them to pretend they were completing maneuvers in the field. It would have felt too artificial, too prototype-y. Our solution to imbuing magic in this case was as simple as operating a prototype wirelessly instead of dangling cables and wires from it. A “man behind a curtain” can ensure the cues and feedback that you’re prototyping are delivered in the way your users would expect. For example, when we tested audio feedback with our soldiers, one of our researchers triggered the audio response manually based on how a robot might understand the soldier’s commands. By not automating the feedback we allowed for occasional variations and surprises in the experience that more closely matched the scenario for which we designed.
It is surprising and enlightening what we can learn from actual experience with actual prototypes. Not that we shouldn’t trust our users or solicit their opinions based on imagined scenarios. But the real insight for designers comes somewhere in the crossroads of opinion and experience. Watching our users’ behavior – how they “do” and “react” allows us to hone the cues and feedback we provide, and create experiences that meet (and exceed) expectations.