 |
« | Week of Nov 30 | < | Individual Entries | > | Week of Dec 14 | » |  |
 |
 |
Echo: The Emotional IM Companion
design, personal
December 12, 2003, 03:18 PM
For my fourth and final project for VIID, I worked with Dan Saffer and Jeff Howard on a system to enhance emotional communication over instant messaging (IM) and potentially other text-based mediums. Our target audience was teenagers, since they tend to be technically sophisticated early adopters, and we were interested in developing a novel interaction design. Our solution is a small avatar that sits on top of your computer monitor. The avatar has a camera inside it and monitors your emotional state through your gestures, your facial expressions, and the text you send via IM, then reports that mood back to you as well as to designated friends. We call it "Echo" because it echoes your emotional state back at you. Check out our final presentation for a summary of our research and a scenario of use. Then play around with a demo of Echo's emotional states. And for the truly curious, some specification sheets succinctly describing Echo's properties are available as well as our presentation of initial research and ideation.
During the first phase, we did some user research and developed the following design goals:
- Enhance emotional communication through compelling, fun interactions
- Use lightweight, natural interactions
- Support privacy
- Don’t interfere with the benefits of the chat medium
With these in mind, we went about trying to develop a concept for Echo. We struggled a lot during ideation for this project; surprisingly, we found that teens are actually pretty good at communicating emotions over the impoverished chat medium and most of the ideas we came up with failed to meet one of our design goals in some way or another. We developed the Echo concept after Ian suggested an onscreen tamagotchi that would somehow communicate your emotional state.
If I had more time to refine Echo, I'd probably focus more on discovering what emotions our users want to communicate, and to what extent these emotions can be "guessed" at by technology. There's a delicate balance in this design between producing a system that requires too much user interaction and thus becomes a bother versus producing a system that guesses too much and therefore risks getting the user's emotions wrong and possibly communicating information the users don't want to disclose. Echo is a novel and compelling design, but also a fairly risky one, which is an interesting observation to ponder.
Thanks to Jeff and Dan for working on the project with me. They're both creative guys and clear thinkers, which lead to interesting and stimulating design meetings and brainstorming sessions.
This concludes my series of IID projects (starting with my scheduling snake, continuing with the Keep in Touch app, the followed by the social robotic walker). I may have more reflections to post later, but this particular foray into new territory has officially come to completion.
Communicating Interaction
design, writing & communication
December 10, 2003, 11:10 PM
We just completed the last leg of VIID right now, having worked late into the night finishing up our last assignment (on which more will be forthcoming soon). As part of my final reflections on the class, I'd like to talk a little bit about ways to communicate interaction designs, which has been a major component of the class that we haven't talked enough about.
One of the most important (arguably the most important) parts of an interaction designer's job involves clearly and unambiguously communicating her design solutions. She must communicate to a variety of different audiences for a variety of different reasons, including:
- Other designers for getting helpful feedback in a critique. If she can't communicate clearly to her peers, then their suggestions may be muddled or inappropriate and she'll lose the many benefits of having more eyes scrutinizing her design.
- Decision makers (usually managers) for getting buy-in and go ahead with ideas. Decision makers generally want to understand the design solution she's offering before committing resources to refining, testing, or implementing it.
- Engineers for communicating what must be built. The engineers also need enough knowledge of the design rational to make micro-decisions relating to changes in the design based on development constraints.
- End users for user tests and feedback. The designer must communicate the experience well enough to collect useful data from test users, as well as to accurately gauge their reactions to the product.
The simplest way to communicate a design, and the one novice designers usually favor, is describing the attributes of the design in prose, either through talking or writing about the interactions as a flat list of features. Generally speaking, however, this isn't effective. Experience and interaction designs are inherently nonlinguistic in nature, and thus all parties need to translate back and forth between their understanding of the experience and the words they use to describe it. Even the best rhetoricians would have great difficultly expressing a nontrivial design with sufficient clarity and precision for all these purposes using words alone. So novice designers may try adding other media, such as pictures, videos, and possibly partially functional prototypes. They're on the right track, but an effective design communication can't just be a mishmash of disconnected design fragments. The designer must invest careful thought and effort into deciding the most appropriate way to communicate each piece so that they come together as a whole.
To fully understand an experience design, people must, well, experience the design. This experience needs to be as close to the final, designed experience as possible to ensure no ambiguities creep in. Keep in mind that people are very good at filling in missing details, but that they may not fill in those details in the same way the designer is. Thus, each unspecified detail is a potential point of confusion, a potential branch where the designer and the experiencer may be envisioning completely different designs. So ideally, the design should be communicated with a high-fidelity functional prototype that approximates the final, envisioned interaction experience as closely as possible.
Of course, building high-fidelity functional prototypes is very time consuming and designers need to communicate very frequently, so there's often no time to build such an artifact. What's a designer to do?
She could produce a prototype, but sacrifice the fidelity in various ways in order to make construction more feasible. When stripping away fidelity, however, she must carefully consider what communication she's losing, and whether these are critical to her communication goals. For example, a series of screen mockups done in Photoshop or another graphics tool may succeed in giving a good sense of the visual layout of the interface, but give little to no sense of how the experience of interacting with it will feel. Likewise, hand-constructed paper model prototypes may give a rough sense of the interaction but may not communicate the visual experience. Sometimes, the designer may wish to intentionally not communicate aspects of the design; if she wants to present a rough design idea and receive feedback on the concept and general structure, she may choose to use wireframes or sketches rather than full interface designs to prevent her audience from focusing on aspects of the design like color and typography which must be present, but may not be the current focus of concern.
If producing a prototype of the appropriate fidelity is not feasible, then our designer has an alternative. She may choose to develop a scenario of use (or possibly several) that depicts a typical user (perhaps one of her personas, if she's defined any) interacting with the product. This may be as simple as textual descriptions of the actions combined with the relevant screen sequences or as complex as a product demonstration movie that appears to depict an actor really using the product. Scenarios are the next best thing to experiencing the interaction design directly through prototypes; they don't let the audience really feel the experience themselves but they do allow them to observe someone else's experience. This approach may appear to be no different to the "naive" ones mentioned earlier, but in fact it is generally much more effective than a list of features or a description of disconnected interactions. Scenarios leverage the power of storytelling to effectively communicate designed experiences.
Of course, all of this advice needs to be mediated with a healthy understanding of the designer's audience and their goals. Communications will need to be tailored to the needs of the receivers; engineering will probably want to see detailed product specifications, whereas management will be more interested in projected revenues and cost justifications, for example. But the techniques in this entry can serve as general best practices to build upon for communicating any interaction design to anyone.
Email Rob:
Don't Make Me Flip Out and Design User Interfaces
funny, usability
December 08, 2003, 01:23 PM
You all remember the Official Ninja Webpage, right? That was nothing. HCI students are the Real Ultimate Power!
Read it, or I'll leave you out of my target audience.
Email Rob:
Email Rob: