Finding a robot we need?

Today I listened to another person asking the world what sort of robot they should build. They had just told us the features that it would have and want to know what things people might use it for, so that they could find the money to build it. This is a completely back to front approach to robot building.

This is what Caroline Pantofaru, Leila Takayama, Tully Foote and Bianca Soto refer to as ‘technology push’ in their recent paper. An excerpt is quoted below, but I recommend reading the whole thing.

Exploring the Role of Robots in Home OrganizationPantofaru, Caroline., Takayama, Leila., Foote, Tully., and Soto, Bianca Proc. of Human-Robot Interaction (HRI), Boston, MA, p.327-334, (2012)

2. NEED FINDING
We present need finding as a methodological tool for quickly learning about a user space, inspiring robotics research within that space, and grounding the resulting research. Much (although certainly not all) of robotics research today is inspired by technology push – a technologist deciding to apply a technology to a problem. User-based research often does not start until after a prototype or system speci fication exists. This is a valuable method as researchers have spent years building intuition for their field.

For robotics research, need finding can provide a complementary, user-driven source of inspiration and guidance, as well as refi ning technology push ideas to better to an application space.

Need fi nding is a method that comes from the product design community [2]. The goal is to identify a set of fundamental user needs of the community a product aims to satisfy. The need finding process is summarized in Figure 2.


Figure 2: An overview of the need nding process

Need finding begins with generating empathy for the user group through interviews, and sharing that empathy with other designers and researchers through conversations and media like videos. This is a concrete and analytic process.

The results from the interviews are then abstracted into frameworks, often presented in graphical form such as the 2×2 charts in Figures 2 and 3. The lessons from the frameworks are then converted to design implications, which are meant to be generative, allowing many interesting solutions to evolve. This process can be iterated and interleaved as necessary. The process is expanded upon below, with a description of our own implementation for this paper.

2.1 Interviews and Observations
Need nding begins with identifying a community of potential product users. A very small team goes out to visit a sample of community members in the places where they do the activities that the product supports. Immersion in the
interviewee’s environment is the key to success and a distinguishing feature of need finding. This immersion inspires the participant to discuss details they might have otherwise forgotten, and allows the interviewer to quickly reconcile the interviewee’s words with reality.

It is important to note that relying on self-reported data alone is dangerous due to people’s poor memories, as well as the social desirability bias (an inclination for respondents to say things they think will
be received favorably.) There is even a standardized scale for measuring a person’s inclination toward the social desirability bias [5]. These problems can be so serious that some usability experts suggest completely ignoring what users say, and instead watching what they do [16]