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?

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."

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.

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

Introduction

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 have now come 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.

It is the aim of this Practice Study to discuss the methods we have adopted to get maximum benefit from our clients' expertise and feedback while maintaining creative momentum and achieving our milestones and deadlines.

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...