Awww…I need to shut down now.

It seems that language in software is on the mind of interaction designers. A few bright folks over at UX Matters have thought about whether software should speak to users from a first person or second person perspective. I have been thinking about similar issues after a client recently asked me about whether a piece of software should ever refer to itself. “If we already think about computers as other people, why wouldn’t we?”

What’s he talking about? For those unfamiliar with The Media Equation, in 2003 Stanford professors Reeves and Nass published a series of experiments they conducted which show that humans essentially treat computers as if they were other humans. From Publishers Weekly: 

"People are polite to computers, respond to praise from them and view them as teammates. They like computers with personalities similar to their own, find masculine-sounding computers extroverted, driven and intelligent while they judge feminine-sounding computers knowledgeable about love and relationships."

Continue reading...

A good design critique

How do you thoroughly critique a design without crucifying the designer? What are ways of critiquing that result in better designs, rather than defensive justifications?

Scott Berkun explores a model for design critique in a detailed post, but I'm interested in the little stuff that works for your design team in day-to-day practice.

At Cooper, our teams often work together for a year or more. It is important for us to create a dynamic of cooperation, but great design often happens when we push on assumptions and challenge the first iteration. We want to encourage this critique, but make sure that it doesn't derail the meeting.

Why is that good?

It's pretty common to hear a skeptical Cooper designer begin a critique with some variant of the question, "Why is that good?" Many ways to express disagreement have negative effects on the meeting or relationship. "That won’t work because," or "But what about." These tend to bring momentum to a halt. Designers must stop, defend their ideas, or chase objections.

As anyone who has faced a blank whiteboard knows, once the ink gets flowing it is important to run with it and see where the idea goes. Communication strategies of design partners can enhance or detract from this process. By asking to see the goodness, we focus on enlightenment, encouraging our partner to help us see what they see. Also, asking an open-ended question is an acceptably naïve way of pushing your design partner to step up and show you what is going on in their mind.

At the core, we want our teams to feel comfortable in expressing healthy disagreement, and to focus on clarifying rather than justifying.

What are ways that your team has developed to critique design while maintaining harmony on the team?

What do you think? Join the conversation in Comments

Rhetorically speaking

One of the hardest things about being a designer is that we have to spend a lot of time and energy convincing people to believe in our ideas. Not only do we have to come up with a great idea in the first place, but then we almost always have sell that idea to a big group of people that you must work with to turn these great ideas into reality.

Of course, we all love to believe that the elegance of our vision is self-evident upon a simple walk through and that our beautiful renderings will stun our audience into adulation. Unfortunately, even if you're very good, this probably only happens some of the time.

The rest of the time we have to explain ourselves. We have to put words around our pictures in such a way that we get our audience to engage, consider and hopefully support our plans and schemes. And this better not be slight of hand. This is no political campaign—if you trick someone into believing you, they can always change their mind after they vote.

Lucky for us, this isn't a new problem. With its roots in the philosophical pursuits of the ancient Greeks, rhetoric is the study of effective spoken and written communication. It is based upon the idea that form and content may be distinguished from each other, and that certain common forms may be applied to communicate a variety of content. As boring and old fashioned as it might sound (kind of like learning Latin), I've found that returning to these basics can be invaluable in clearly articulating the kind of conceptual thinking that often forms the foundation for our proposed design ideas.

Continue reading...

The parable of The Homer

Even after you’ve sold them on personas, even after you’ve explained that you want to design for a specific persona first, even after you warned them about the perils of the “elastic user,” you can find yourself hearing things like, “Well, I know this guy who would do it this way...”

To help clients who won't be put off by pop-culture references, I reference the parable of The Homer.

For those who aren’t familiar with the Simpsons episode “Oh Brother, Where Art Thou?” (Season 2, Episode 15), it plays out like this: Homer meets his long lost brother Herb, who happens to head an automobile company. Believing Homer to be the perfect “everyman,” Herb instructs his designers to make exactly the car that Homer wants.

Continue reading...

Pull and Push Communication

A friend recently told me that she was challenged by information management in the design process. "I'm looking for anything to facilitate faster communication…[it's hard to] remember all the people I have to contact to update about something. Sometimes I'll send out an email and forget the developer, or forget the QA person - and this happens vice-versa…not intentional for anyone. It's just hard to remember everyone in a fast moving environment. "

Communication is tricky. I have to say that face-to-face has advantages over other methods because you can tailor the communication, but it is time consuming. When face-to-face won't do, consider these questions:

• What are the most essential elements you’re trying to communicate and to whom?
• What are your objectives for the communication?
• What are the most effective methods to achieve that?

I’ve been hearing a lot about “visibility” at the Agile '08 conference. Development teams keep card walls that describe the work they are doing. Anyone can mosey up and see what’s happening. Designers can do a similar thing, by posting a timeline, and work product related to each step. Project wiki’s are also good for the running stream of work done. This is all “pull” communication that people can check in on when they are curious, or need reassurance about what your team is doing.

In my experience, “push” communication should be used sparingly, and should contain summaries and action items. People are busy and don’t have time to process a lot of email. Make your moments with them count.

What do you think? What works for you?

What do you think? Join the conversation in Comments

Why I read my speech at Agile08

Some attendees at the recent Agile08 conference were put off when it appeared that I was reading my speech rather than delivering it offhand. (If you're interested, you can find my slides and speakers notes here.)

It’s true; I was reading my speech.

When I speak to groups of interaction designers or business people I often address them extemporaneously. It’s a style I enjoy very much and feel that I can do well.

However, the Agile08 audience demanded special treatment. Not only was it large, but it consisted primarily of programmers, agile coaches, and product managers. These professionals are bright, knowledgeable, critical, and opinionated. They do not suffer fools lightly. I was coming to them as something of an outsider; not having programmed for a living for years, and never having programmed in a canonically agile shop.

Continue reading...

Faces in the crowd: Early persona history

A few days ago, Liz Bacon and Steve Calde presented their talk "Death to Personas! Long Live Personas!" to the Catalyze community. During the webinar, which addressed some common misconceptions about personas, Liz shared some early persona history from her time at Cooper. This got me thinking about how personas have evolved at Cooper during the time I've been here.

In his article "The Origin of Personas" Alan Cooper reviews his early use of personas back in 1995. By the time I joined Cooper in 1997, personas were in regular use as a design tool, but the way we presented them to our clients continued to evolve.

I recently had an e-mail conversation with Nate Myers, a former Cooperista, about his memory of the Sony Trans Com's P@ssport project. Here are Nate's recollections.

To my knowledge, Sony P@ssport was the first project to use pictures. There were no conversations about using photos; I just made the decision to include them in my draft document for several reasons:

During the first meetings I attended as a new employee, I noticed communication issues between Cooper and its clients, many of which revolved around the 'elastic user' problem. By using pictures of real people, who in some cases were dramatically different from the tech-savvy users imagined by clients, I hoped to curtail (or even eliminate) the frequent raucous arguments about 'the user.' We could all look at the same photo and quickly build up a set of shared assumptions that fit the face looking back at us.

In projects prior to Cooper, I noticed that sample users were often given whimsical names, usually based on Looney Tunes, Star Wars or Star Trek characters. However, I saw real business value in identifying user goals by personas, so why undermine that value with a silly name? This didn't mean some of our names couldn't have subtle humor: Clevis McCloud and Mel "Hoppy" Hopper had a touch of fun built in. But even this humor was by design; both names sounded earthy and pragmatic, helping us keep far away from conceptual power users who could easily negotiate software complexity. Since Cooper was already avoiding the silly name trap, matching a realistic photo with a realistic name would only help to enhance the business value of personas.

In our initial conversations with Sony, we had a lot of discussions about idioms and user expectations. Looking at the process of airline travel as a single experience, I asked myself what would happen if users came to P@ssport after interacting with several different procedures and systems during their total airport and flight time. Wanting to help communicate the idea that simpler is better, I included visual flight maps as part of our design document, showing travelers with direct and connecting flights. On paper it seemed just as important to show the passengers as it did the routes.

From previous freelance work, I had two Photodisc CDs filled with pictures of travel, leisure and industry. The pictures on the CDs lent themselves very well to our needs for Sony P@ssport. The most challenging picture was for a child traveling alone; we had specified a pre-teen boy, but the only picture close to it was of a 3-5 year-old girl with a pony tail. As I Photoshopped the pony tail out of the picture I thought to myself, "Wouldn't it be interesting if this picture ended up in a book someday?"

The project team liked the draft with the photos included, so we went with it. I'm glad. It was a good idea.

If you'd like to read more about the Sony Trans Com P@ssport project, there's a case study in Alan Cooper's Book "The Inmates are Running the Asylum."

What do you think? Join the conversation in Comments

Seeing patterns in research findings

We’re always on the lookout for engaging ways to communicate the patterns we uncover in our research. What factors cluster into significant groups? What are relevant attributes and relationships? What trends do we see?

Shan Carter and Amanda Cox at the New York Times recently produced a fantastic interactive chart highlighting the voting patterns along several demographic factors in the Democratic primaries. (You can read more about this graphic from Shan Carter here.)

I love the idea of starting with this approach and overlaying additional factors to draw out relationships and relative importance. In the Times example, imagine the squares drawn in relative proportion to the number of delegates in play; color and saturation representing the percentage of Democratic votes in the 2004 presidential election. Combining multiple factors does complicate the visual, so care must be taken to preserve the clarity that makes it so effective.

At Cooper, we often do something similar, with behavioral variables of interview subjects plotted along major axes, combined with demographics like age, organization type and role, to paint a picture of the interrelated web that helps us make meaning of a diverse human population. We always try to walk through these visualizations with a story that ascribes meaning to the observations, but providing clients (and ourselves) with an opportunity to interact with the data in a well-curated way really emphasizes the relevant factors and helps everyone understand the patterns we use to drive decisions and take action.

What do you think? Join the conversation in Comments

Communicating Design Concepts Without Getting Skewered

We have a saying around the office: "If you can't explain the design, it must not be right yet." It's a reminder to designers to not get so caught up in idea generation and specifying details that we lose sight of creating a coherent big picture for the design.

We need to exercise the ideas we generate by articulating them coherently; chances are high that if we can't describe our "great idea" with clarity, it's not such a great idea, after all. It's amazing how many design ideas seem just dandy on the whiteboard, then deflate like a punctured balloon when poked at with the sharp pencil of design communication.

Continue reading...

Early and Often: How to Avoid the Design Revision Death Spiral

One lesson we've learned over the past several years here at Cooper is that on the vast majority of our projects, intimate client collaboration is a critical ingredient for success. This is a lesson that we have sometimes learned the hard way; collaboration can be messy, unpredictable and has often forced us to compromise what we thought was a supremely clear and elegant vision. Despite these growing pains, we've learned to embrace the unpredictability and compromise; through well-managed client collaboration, our designs are stronger and are more likely to serve our clients' needs and satisfy the goals of end users.

Continue reading...

Making Your Design Real: The Form & Behavior Specification

This article is one in an occassional series on design documentation. The first article in this series, Bridging the gap with requirements definition, by Ryan Olshavsky, discussed how to document the needs of the user and the domain issues relevant to the design of products. The second article, Turning requirements into product definition, by Jonathan Korman, discussed how you get from an understanding of your users to a vision for an innovative product that appeals to them. The present article discusses how a detailed specification of the form and behavior takes the guesswork out of product development.

Continue reading...