Adaptive Path: Do you think there's enough emphasis on customer research in the Web design and development industry? Is it growing, or has the emphasis always been there?

Marc: From the beginning there has been a lot of talk about customer research, and this has been both increasing and changing in tone over the last couple of years. At first it was mostly influenced by marketing, so "customer research" meant bringing market research techniques to bear on web projects -- surveys, focus groups, demographic studies, and so on. These help you learn what people say as opposed to what they actually do, and aren't much help when it comes to guiding the design of something new. As an industry, we're just starting to learn how to get out of our office, go where people are doing the activities we are designing for, and really understand what's going on.

Lately the buzz has been increasing about behavioral research, ethnographic methods, contextual design (it has lots of names), and its value is becoming widely appreciated. The business and technology press is even starting to cover it. But there's still a lack of understanding about what it actually takes to do it well, especially on the part of managers, team leaders, and executives. The biggest gap, in my opinion, is what to *do* with research data once you've collected it -- which is the topic of my workshop.

Finally, while the industry has learned a lot about using research to shape the design of products and services, it has been slower to use the same methods to guide decisions about which products to make in the first place. Research-driven user-centered design methods are powerful strategic tools. They can help steer a company as well as the details of a product.

AP: How do you avoid having a big stack of carefully considered research sitting in a filing cabinet somewhere?

Marc: By making the results of research an explicit part of your working documents and team activities throughout the process. This question connects to other project management issues, because it's not just user research that can get lost in a file cabinet (or more often, a file server). Lessons from customer support, technology issues, content opportunities, business realities -- all these things need to be brought together. When different groups are responsible for them, it can be difficult for the product or web team to integrate it all.

I've found that the greatest difference comes from facilitating the team and changing what they are expected to make. For example, an early whole-team activity is to gather *all* the research -- user, market, technology, content, etc. Get it out of notebooks and electronic documents and up on the wall -- make it physical, easy to manipulate. Make it big. When the team surrounds itself with the data, the activities that lead to profound design insights design become concrete. They happen on the wall with the team, rather than in the imaginations of one or two people. You use sticky notes, big pieces of paper, diagrams, white boards, photographs, quotes from users, lists and matrices, concept models, flow diagrams, timelines, relationship maps, and so on.

It's amazing how these tools can work to get research out of the files and into the minds and hearts of the team. And from there, into the minds and hearts of the stakeholders and into every nook and cranny of the design.

(I'm sure this sounds vague, since I tried to fit the spirit of a whole way of working into one paragraph. In the workshop I break it into steps: analysis, synthesis and modeling, concept generation, concept validation through mock-ups, detailed design and validation through prototypes. I'll provide a number of specific tools and facilitation techniques, and show examples from projects.)

AP: What projects have you worked on that best illustrates this point?

Marc: In the late '90's I worked on two intranet projects back-to-back. Both began with the request, "we need an intranet," by which the clients meant, "we need one of those things everybody's talking about, where you store your documents and have discussions." One was a product company with an incredibly fast-paced culture. The other was a consulting firm, where it was important to be really smart in front of your client. In both cases we did a fairly short amount of interviewing and shadowing, involving researchers, designers, technologists, and business analysts. We did cluster analysis of the research on the wall with sticky notes, finding the themes, patterns, and structures in the data. This led to diagrams that represented the relationships and information flows in those two companies.

The results were very different for each. The product company was all about reacting fast to the competition. These people spent a lot of time looking for each other, using personal networks, and reacting to news. The information half-life was about four weeks. So the design for the intranet had dynamic categories, a sort of intranet matchmaking service (to help newcomers build their personal network), and ways that conversations could be attached to any news item. Lots of churn. And since they lived in email, you could actually participate in the intranet by email.

The consulting firm's intranet was about aggregating expertise. Finding the lasting insights and the really smart people -- then organizing all this into points of view on industries, ways of working on different kinds of projects, and tools for research in lots of different areas. We made people and documents look more or less the same as content types. Ease of publishing was a big deal, especially for their internal experts. Categories were semi-permanent, and the information half-life was probably 6-12 months.

These very different solutions came out of the same original "requirement," because the team developing the intranets lived the research, and made sure that the research shaped the product. On those teams, "collaboration" didn't mean that the designers and developers emailed documents to each other, it meant that they and others had long work sessions in the same room together, doing their work on the wall. At each step of the way, the design reflected our best shot at digesting research, forecasting technology and functionality, and supporting the business realities.

I'm living through this right now on a very different project, designing the interface for a medical application. After one week the project room is a melting pot of product functionality, user activity models, questions, and visions. Our Friday status report consisted of a guided tour of the room. Much better communication than handing in a written report.

AP: Do you think our industry is still moving at a break-neck pace? How does that affect research and development?

Marc: The pace was ridiculous for a while, because the deadlines were often artificial. They came from management goals rather than market realities or honest reflection about trade-offs between quality, time, cost, and market opportunity. I can't say for sure, but hopefully some of the new caution will lead people to set more thoughtful deadlines. I'm reading more opinions and business school articles about how important customer experience is for competitive advantage, which is another hopeful sign.

Personally, I've seen enough projects undermined by inappropriate pace that I am learning to hold my ground. Say "no." Defend quality. I used to work tons of hours and whine about it. I'm learning that this is doubly counter-productive, so I'm changing the whining into businesslike conversations about pace that start when the project is conceived. I've learned a lot about how to conduct research quickly and inexpensively. I've learned a lot about how to move quickly through the phases of a project. This is good. But I'm also learning that some things can only be done so fast, and if you try to do them faster it's a lot like not doing them at all. If the team needs the results from research, or from research synthesis, or from the design phase, then it needs them at a certain level of quality and completeness. Less than that raises the risk of failure sky-high. And it makes everybody unhappy.

Which is the long way of saying this: On average our industry was going too fast, which meant we were taking big risks. We were building based on assumptions rather than understanding, for example. These risks caught up with us. In my experience, taking enough time (which doesn't mean a *lot* of time) for the heart of the user-centered process is good business because it is good risk management.

AP: What is the Museum Innovation Project?

Marc: I'm teaching a course at Carnegie Mellon's Graduate School of Design. It's a studio course, the first time the grad students have done a single project for a whole semester. Our client and collaborator is the Carnegie Museum of Art, and they gave us a nice challenge. "We have lots of art, which we put on display. We have lots of stories and information about that art, which is inaccessible to visitors. All they get is a little plaque. How can we use technology to improve visitors' experience, without that technology intruding into the quiet moments that happen between people and art?"

The "museum innovation project" is the name for this overall effort. Learn interaction design, work in teams, understand what's going on between people and art in the museum, and try to make it better. The goal is to deliver three concepts or visions that are grounded in research, technically feasible in two years, and practical for the museum to implement. We spent about a month planning and conducting research, then another few weeks thinking up tons of ideas. Those ideas have finally consolidated into three directions, one for each student team.

One team is working on passive interfaces to audio content -- you control the delivery of audio just by walking around in the museum. They're trying to keep the number of buttons down to one or two. Another team is trying several different "activities." They're giving people things to do in the museum that change the way they look at the art -- collecting, collaging, annotating, trail-making, connection-making, and so on. The third team is exploring how a device can provide access to a rich base of content without distracting people from looking at the art itself.

We have a site, which unfortunately has gotten a little stale because of the pace of the project . But we will definitely update it, and the results of the project will be posted there:

http://www.andrew.cmu.edu/course/51-712

Anyway, it has been a exercise in applying the sorts of things I've just talked about. Translate research into product direction, then into the details of product form and behavior. While having fun.

See Marc in person at the Chicago stop of the Adaptive Path Tour 2002.