Sign up to get our featured articles delivered straight to your inbox every month or two.
RSS feed of all articles
Kim Goodwin
Kim Goodwin As VP Design, Kim has played a major role in developing our Goal-Directed methods and turning them into the Cooper U curriculum, and she continues to work with the leaders of each design discipline to evolve and improve our practice. Her design expertise and teaching skill have made her popular as a speaker at conferences around the world. Kim has led a wide range of design projects, from e-commerce sites to information appliances, IP telephony systems, and complex healthcare applications. Before joining Cooper, Kim was a creative director and an educator.
Conversations with machines
Every time I get on the phone with some corporation or other, I find myself reflecting on why voice interfaces are so uniquely infuriating. Clearly, I’m not the only one who thinks so, or sites like dialahuman.com and gethuman.com wouldn’t exist. I suspect the problem lies not only in wretched usability, but also in the fact that voice interaction sets higher expectations for reasonable, human-like behavior. If humans interact with computers as if they were also human, as discussed by Byron Reeves and Clifford Nass in The Media Equation, this seems even more true for computers other software-powered devices that accept voice input in addition to using voice output; after all, if it can understand what you’re saying, it must be able to think, right? In their very readable 2005 book, Wired for Speech, Nass and another colleague, Scott Brave, assert that this is indeed true. Hearing a human say, “I’m sorry, I didn’t understand that” three or four times in a row would be enough to inspire violent impulses in the most dedicated pacifist, and many people have similar reactions to voice interfaces. So is a more “human” interface necessarily better?
Even though we know we’re talking to a machine, we humans respond to perceived emotion even in recorded voices. For several days after we installed a new phone system in our offices, people continually commented on the doleful female voice that responded to deleted phone messages by saying “duuh-leted,” dragging out the first syllable and drooping at the end, kind of like a mopey teenager asked to take out the garbage. Discontented machines are especially noticeable, though excessive perkiness is irritating in some circumstances: “I’m sorry, you’ve been on hold for 20 minutes, so your session has expired.”
Where does design belong in your organization?
These days, more and more companies are recognizing that design and innovation are essential to their strategy and bottom line: effective design sells products and services, improves your position in the marketplace, and turns customers into loyal advocates for your brand. If you've gotten your organization to this point, take a moment to enjoy your success! Creating demand for design is no small achievement. Unfortunately, to reap the full benefits of design, you probably still have a lot of work to do on your organization's structure, processes, and culture.
One of the first things you need to do is determine where in your organization design belongs. There are a variety of models, from outsourced design to an in-house consultancy to designers permanently embedded in individual product teams. No single structure is the right answer for every situation; you have to assess what's the best fit for the number and type of design needs you have, as well as for your organization's culture.
Taking Personas Too Far
I don't have to tell you that at Cooper, we love personas—how could we not?—and we're glad to see continued excitement about them. That said, although personas are essential design tools, we think some people may be losing sight of the fact that they're just tools, and tools with a specific purpose, at that. Lately, we've been seeing a lot of gold-plated hammers—unnecessarily elaborate communication about personas—and some fundamental misunderstandings about the relationships among research, personas, and scenarios.
Ten Ways to Kill Good Design
It's a given that we at Cooper—and most of you reading this article—believe design is the right tool for translating market needs into tangible product specifications. The people who hire us to design their products or who attend our Cooper U courses think the same thing. Unfortunately, the best designs and the best intentions won't always lead you to success, because the problem goes beyond your product and beyond your design or development process. Building better, more innovative, and more profitable products requires organizational change on a deep and difficult level.
When design pilot projects fail, it endangers everyone's willingness to adopt design methods. Over the course of doing hundreds of design projects and teaching our methods to more than a thousand people, we've seen that several reasons for failure keep showing up. A discussion of these reasons follows, along with some solutions to consider. Let's start with the easiest ones and work our way up.
Can Programmers Do Interaction Design?
In most of the organizations we encounter during our consulting work, programmers tend to think they’re the best-qualified people to design the form and behavior of a product. In the absence of trained interaction designers, they may be right. They know from experience that no one else is going to think through all the implications of serving up that snippet of data in just the right way, and no one else questions the idea of programmers doing the interaction design because they assume it’s a technology problem. As a result, executives who lead technology initiatives believe that they already get interaction design for free from their programmers. In their opinion, having interaction designers is unnecessary; if the product happens to be hard to use, they assume the programmers just need some sensitivity training. Having programmers design the product is anything but free, though; it’s ineffective, inefficient, and risky.
5 Ways to Get the Most from In-House Designers
Over the last two years, we've heard from increasing numbers of executives who want to bring interaction design in-house because they've realized how critical it is to product success. There are plenty of challenges involved in doing this, including hiring and training the right people. One of the challenges companies may not expect, though, is in deciding how to use those resources once they've been found.
Getting from Research to Personas: Harnessing the Power of Data
The usefulness of personas in defining and designing interactive products has become more widely accepted in the last few years, but a lack of published information has, unfortunately, left room for a lot of misconceptions about how personas are created, and about what information actually comprises a persona. Although space does not permit a full treatment of persona creation in this article, I hope to highlight a few essential points.
Perfecting Your Personas
A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design.
Email it to us and we may answer it in an upcoming article.