In May 2008, Kristina Halvorson from Brain Traffic spoke at Adaptive Path's Queens of Content event. Her presentation "Content Strategy: The Mania, the Myth, the Method" shed light on current perceptions of content strategy in user experience, and provided great fodder for further exploration. I was particularly intrigued by what Kristina had to say, because while I agreed with the overarching message, I felt compelled to debate some of the finer points.

Kristina agreed to push the thinking further with a discussion about content, UX teams, and how the relationships can be strengthened to create experiences and projects that really sing. The resulting conversation start with content basics and closes with a bold challenge.

Kate Rutter [KR]: Hi, Kristina. Let's start with what you ended with in your talk at Adaptive Path. This was my takeaway: user experience teams hold the charter to deliver great experiences, but bringing in "content" at the end-game undercuts the positive experiences that are delivered. It's as if the movie poster is great, the trailer is thrilling, but when it comes to opening night, everyone is looking around asking "where's the film?" How can we work together to change this?

Kristina Halvorson [KH]: To begin, let's reframe this a bit. I think the point here is that, by waiting until the UX process is essentially finished to start really talking about the content, we're not allocating appropriate time and resources for what can ultimately make or break the planned/designed "positive experience."

KR: How do you define or describe "content"?

KH: Content includes the text, graphics, video, and audio that make up an interactive experience. Now, I'll say right off that bat that the majority of content we're asked to gather, write, and edit at Brain Traffic is text. This sounds simple enough, until you stop to consider that the required content for nearly every interactive experience includes not just headlines and articles but also help and support text, interface copy, product or service descriptions, menu nomenclature, text links, metadata, image captions, error messages, alt tags -- you get the idea. Once you start to add up all the writing requirements for any interactive project, it can get really overwhelming, really fast.

KR: Yeah, that's a lot of stuff. I've heard you say that content is everyone's concern. But as we all know, when everyone is responsible, it often turns out that no one is responsible. And it sounds like many UE initiatives suffer from this problem.

So what roles are appropriate for being the standard-bearers for content? Who are these people and what skills do they need?

KH: First and foremost, all parties focused specifically on delivering the content -- content strategists, Web editors, Web writers, and content QA folks -- absolutely, positively must share the end goal of a superior user experience. This is a huge paradigm shift for most writers, who are used to writing about what WE do, how WE can help you, what WE have to offer. Yeah, well, nobody cares. All the user cares about is, of course, "What's in it for ME? What can you do for ME? How can you help ME? What do you have to offer ME?"

So, at the highest level, these "standard-bearers" must understand the importance of UXD and be well-versed in the language, methodology, and documentation that accompanies the process.

At a more tactical level, here's who these people are:

Content strategist: Responsible for helping to define the content -- what it is, what it says, where it will come from, and how it will sound/read. I think another critically important role, here, is that the content strategist is responsible for monitoring what's being suggested or requested -- it's not as though the content is just sitting in a drawer somewhere, waiting to be pulled out at the last minute. Do we have the necessary time and resources to produce what's being proposed?

Web editor: For larger projects, this person is responsible for providing editorial oversight to the Web writing team. Ideally, this role is held by the client. However, I don't know many companies who have figured out exactly how to define (and empower) the Web editor role.

Web writer: Responsible for creating clear, concise, compelling text that helps readers gather information or complete a task. The best Web writers write like they talk, not like a brochure. Must also never, ever complain about writing metadata, reviewing error messages, or updating content inventories. (That last bit disqualifies most ad copywriters.)

KR: How do these roles scale across big teams in mega-corps, and small UX teams of one?

KH: For mega-corp teams, I like to see teams of Web editors and their armies of Web writers working to preserve the quality and relevance of their online content around the clock.

For UX teams of one, a Web writer with killer organizational skills and a healthy appreciation of Excel would be a great partner.

KR: So here's the $100,000 question: what do teams that don't have any writers do? Who makes the words?

KH: Does. Not. Compute. Okay, well, my first suggestion is that these teams GET a writer. They need to be crystal clear with the client up front that the words are a critically important driver in the success of the end user experience, and therefore a writer is a critically important player in the beginning. Period.

(This is also a fabulous opportunity to vet clients who insist they're going to do all the writing themselves. Early involvement might help them figure out sooner rather than later that they don't in fact have the time or expertise to deliver. And this will save the typical crash-and-burn projects run into when it actually comes time to get the content into production.)

If for whatever reason there is no possible way to get a writer involved early on, then I'd propose that the person doing the UXD takes a good ol' fashioned stab at the writing required for wireframes and design. At the very least, I think folks might be shocked to find out how often content isn't even required where they're "making space" for it.

Let's go back to the role of the content strategist. What value do these folks provide to the team and to the resulting product?

KH: First, they ask real questions about the real content. What do we have? What will we need? Where is it? Can we do it with the time, budget, and people we have? This simple contribution can save entire projects from derailing in the "creative" phase.

Second, they help the client (or business units, or subject matter experts (SMEs), or any key stakeholder who's involved with the project) begin to process thoughts and feelings about content. For some reason, discussions around content often quickly turn into group therapy sessions. Everyone has opinions. Everyone has ideas. Everyone thinks they're a writer (don't get me started on this). A content strategist can help set expectations around everything from why old content is getting killed to how long people will have to review and revise the new content once it starts coming in from the Web writers.

Third, they own the words. From day one, they're thinking about how the words will support the UX strategy, how much or how little text is required, how it should sound, who's going to care about it (or not). I'm not sure how to place a value on this, except to say that a beautifully crafted user experience can come crashing down if the text is overwritten, unclear, off-brand, navel-gazing -- you get my point.

KR: Ouch. Let's shift focus a bit. Everybody in design is talking about "getting a seat" at the glorious strategy table. But in your talk, you talk about just getting content strategy included at the start of new projects. That seems totally reasonable, yet I know it doesn't always happen. Why doesn't this happen?

KH: From a UX perspective, I think we're often driven by our clients to deliver designs -- or, at least, structure -- as quickly as possible. Dealing with copy slows that down.

Also: I've heard the argument that "lorem ipsum" is effective in wireframing or design because it helps people focus on the actual layout, or color scheme, or whatever. What kills me here is that we're talking about creating a user experience that will (whether we like it or not) be DRIVEN by words. The entire structure of the page or app flow is FOR THE WORDS.

Frankly, I also think most strategists see writers as part of the creative process. This made sense in the traditional advertising or marketing communications model. However, now words are key building blocks in every interactive experience, no matter how few or how many are required. Not having someone at the table who's willing to own that responsibility from day one simply doesn't make sense.

KR: So what does this early inclusion look like?

KH: Seriously, just invite the content strategist -- or, in smaller teams, the Web writer -- to the early meetings. That's it. It's an easy, no-brainer first step. That person will immediately start to identify what's required to get the writing done right, and won't be left staring down the barrel of the Project Manager's gun in eight to 12 weeks.

As a side note: I think it's interesting that you call it the "glorious strategy table." It implies that content people have been longingly wishing for "a seat" for the past 10 years. I don't think that's the case at all. In fact, I think we've been wishing that someone else would come up with the tools we need to get our jobs done effectively and on time. And that's clearly not going to happen.

Nor do I think it should happen. I think that's our job. What I'm proposing, here, is that content strategists, editors, and writers need to be responsible for creating and refining those tools. The days of being the dude who sits around with an art director, cooking up The Next Big Idea are over. Web writers need to understand IA documentation, sit through usability labs, revere user research, demand site metrics and analysis -- you get the point.

KR: What are the business implications of not including content-reps up front? The costs, the obstacles, the issues?

KH: Oh, where do I begin. Delayed start to the writing process, since Web content documentation needs to be agreed-upon, standardized, and built out. More delays, because suddenly gathering up the content becomes a messy, time-consuming, overwhelming task. Dozens of unplanned revisions as more and more content keeps being requested or remembered. Incredible, unavoidable scope creep. Tensions and frustrations because no one has the time (or the power) to slow down and make sure everything is consistent, relevant, clear. And, of course, the end result of crappy content that none of your customers care about.

KR: Okay, so is there a checklist of items that every project leader needs to think about to ensure that content is included at the start of a project?

KH: Yep.

1. Assign a content audit. Even if it's a brand-new interactive experience, there's relevant content somewhere that's being (or has been) developed. Find out what it is, where it lives, and who owns it. And document it.

2. Figure out who will create and own the content inventory. This is the master list (or lists) of all content requirements for the project. Sometimes separate inventories are created for text, video, audio, and images. It's a working document that can be sketched out early in the process and refined as you go.

3. Figure out who will be included in the content review process. These folks should likely be included in early discussions, whether or not their input and feedback will be incorporated. At the very least, they don't feel ignored or sidelined.

KR: I think that UX designers and content strategists have responsibilities to each other to make the resulting experiences really sing.

How can teams work more effectively together? Is there distrust of each other? If so, where does this come from and how can it be addressed?

KH: On one side of the coin, sure, I think that UE practitioners don't think writers GET IT. In response, I would gently propose that you might be working with the wrong writers.

To illustrate: someone recently said to me, "I just think it takes a really special person to manage writers." I was totally offended, but then I realized that he was talking about writers-as-creatives. And, for better or worse, that's not how I think of myself. I'm a creative problem-solver. In fact, when I'm interviewing potential writers at Brain Traffic, I usually tell them pretty straight-up that, if you're serious about being a Web writer, please, leave your "art" at home. We have a job to do: help people get in, get out, and get on with their lives.

On the other side, I will say that when I first described Brain Traffic's business model to a renowned UX guru, he squinted at me and said, "Really? Just a bunch of people typing words on keyboards?" Then he did this imitation of a typing monkey. So, clearly there's some education that needs to happen about what's actually, really involved in creating smart, useful content.

KR: In addition to being open-minded, not imitating monkeys and becoming educated about the process, what are three bold steps that UE practitioners can take to ensure the success of the content in UX initiatives?

KH: 1. Demand the early and ongoing involvement of a content strategist or Web writer.

2. Don't dismiss the tactical questions regarding content -- "how, who, where, when" -- during the strategic process.

3. Renounce "lorem ipsum," now and always.

KR: Dang. Life without lorem ipsum. It's a bold challenge, but I'll take you up on that! Let's wrap up with the "What's In It For Me" question: what are the benefits that come from thinking strategically about content matters?

KH: I'll answer with another dead-white-man quote: Winston Churchill said, "However beautiful the strategy, you should occasionally look at the results." I wonder how often, after a super fabulous UX strategy is delivered, three to six months down the road we can't bear to look at what actually ended up launching, due in large part to the terrible writing that ended up getting published.

By thinking strategically about the content from the start -- the actual building blocks of your user experience -- you're far more likely to identify and remove obstacles to success.

Find the content. Find the right writers. Set and manage reviewer expectations. Provide editorial oversight. And then kick some content ASS.

KR: I'm all for that! Kristina, thanks for taking the time for this conversation, and for sharing your fantastic content strategy insights. It's been a pleasure!

Kristina Halvorson has been writing for the Web since 1997. As president of Brain Traffic, Kristina leads teams of expert IAs, content strategists, and Web writers to create smart, relevant content for real people with real needs. She is a passionate advocate for content strategy, the "hidden discipline" that lives between information architecture, web writing, and the build process. She so totally does not type like a monkey. Follow Kristina on Twitter @halvorson.

Raphael Grignani [RG]: I'm currently leading the Nokia Design Service and UI Design team in the San Francisco Bay Area. Prior to that I was a designer in Nokia's advance design team in Los Angeles where Homegrown emerged.

RH: Why don't you talk to us a little bit about the genesis of Homegrown? How did it begin?

RG: Homegrown started about four years ago. Alastair Curtis, who's now the Design Chief, asked Nokia's advance design team to create a vision for phones where you can remove the covers and change the appearance of the device.

The team realized quickly that the category was a disruption for Nokia and for the consumer. We were looking at how people could personalize their phone very cheaply and very easily. It was a disruption for Nokia in the way we were making things; we had to design both the engine and the covers differently to allow people to replace the cover safely and easily.

The team at the time realized the real challenge was identifying the next disruption. What would be the next disruption? They gave it some thought and came up with a number of proposals; one of them was sustainability. They engaged in a project that eventually inspired Nokia Evolve. But it was not enough, they wanted explore other aspects of sustainability. Eighteen months ago or so, they got that opportunity and Homegrown started. This is when I joined the project.

RH: It sounds like though it was a grass roots project then within Nokia.

RG: Well, actually the name says it all. Homegrown. It really started from ten people in Los Angeles looking at the topic of sustainability and doing what they felt was right for them and for Nokia.

RH: So can you tell us a little bit about the scope and scale of the project? How did you begin?

RG: We started to collect numbers and statistics both internally and externally to capture tangibly the current state. These numbers became the foundation of the project. For example, Nokia manufactures now sixteen phones a second, which translate into 1,000,000 phones a day. There's nearly 3 billions phones out there and in the US only 400,000 phones are discarded everyday. We know that half of the population or half of the globe will be connected in the next five to ten years (The UN has established a goal that 1/2 the world have access to telecommunications by 2015) and that 75 percent of the globe is within network coverage. We also know that one in five people is illiterate and that 3 billion people live under $2.00 a day.

All these numbers helped us to frame the project and prioritize what needed to be done immediately. Later on it also helped us to communicate the concepts and design principles to the rest of the organization.

RH: Can you talk a little bit about how you used statistical data to inspire and drive the design process?

RG: Well, I think the numbers were so big and so powerful that it was quite easy to translate them into products, UI, or services concepts. We focused on the implication of the numbers.

Our first concept is a remade phone that utilizes materials that already exist above the earth's crust. Another case study looks at how we can design for digital life. Another direction was to explore concepts that use less energy. Another was about interfaces that are designed specifically for illiterate people.

How do we encourage people to keep their products longer? The "Wears in not Out" is a device concept designed to encourage people to keep their mobile devices longer while reducing Nokia's environmental dust-to-dust footprint.

RH: Can you talk in more detail about some of the key concepts that came out of this project?

RG: The first one that was presented in Barcelona by our CEO was Remade. A lot of the talk on sustainability is around materials and Remade shows how we can utilize materials that already exist above the earth's crust.

With Remade, Andrew Gartrell (Homegrown project lead and Remade father) pushed design beyond skin deep aesthetics. He considered covers, key mats, and displays but also engine, connectors, and other components. We discovered that a typical mobile phone contains around 44 of the 117 elements currently known to science. Andrew's approach was to de-construct everything and rebuild it from scratch using recycled materials and sustainable technologies -- from the inside out.

Another aspect of Homegrown that is really interesting is the work we did around prototyping. Andrew designed in CAD over 100 versions of Remade and prototyped 36 -- which could be considered obsessive -- but it was through that constant consideration and iteration that we were able to arrive at something that was great. Prototyping allowed us to confront our designs -- asking ourselves, "Is this the best we can do? What can we reduce? Have we found the essence? What can we make better or what can we make differently?" We questioned every bit of the concepts throughout the prototyping process. Now we can explain every bit of the design; we can rationalize every aspect of it.

For example, the final design of remade has a fluted aluminum casing because it uses less material. An earlier version had a printed key mat, but the printing fades with time and requires post processing. Perforated numbers on an aluminum sheet will last longer and can be made all at once.

If you want to make something that is pure and true, you need to pay attention to every detail. You need to be ruthless in the way you make decisions and that is hard to do unless you prototype.

RH: Another thing that you mentioned Homegrown addressed was the idea of challenging the disposable culture around mobile phones and creating ones that were designed to keep longer.

RG: As people's lives become more and more digital with social networks, emails, digital photos and music, we wanted to explore how people could potentially upgrade their devices digitally rather than physically. The physical part can then be approached differently. Essentially it is a reflection on where the value is… Is it the object or the content?

With a focus on human universals, the "People-first" interface concept strips away the complexity of applications, folders, and unpredictable navigation with simpler universally understood organizing principles: time, lists and faces.

RH: What aspects of Homegrown were about interface design? What are some of the specific interface or interaction design parts of the project that you think are important to speak to?

RG: Each of the concepts has a unique interface based on the design principles and what we were aiming to demonstrate. We tried to find the essence for each of them and design a beautiful solution. If you look at them, they're actually quite similar.

With all the interfaces, we focused on the idea of mobile essentials, which basically is allowing people to connect whether through voice or through text. We tried to think about how we could narrow down what was on the phone based on what was essential and using the natural features inherent in a phone.

For example: a camera. Cameras are good for capturing memories. Most of the mobile phones now have a camera and there are numerous benefits to that feature. It allows users to capture moments, but also to capture faces. So instead of adding Rachel in my phonebook by typing your name and your number, I can use an image of you which might be more efficient and much more friendly to use -- especially for people who can't read. We know that people recognize faces much faster than text or numbers.

Another essential feature was a calculator, which was something we kept in mind when thinking about a phone that will help connecting the next 3 billion people. We knew from research that calculators are essential in negotiating price. In China, when somebody is at the market, they pass around a calculator. That is the way it works -- so a calculator on a phone is essential.

RH: You mentioned that your CEO announced Homegrown in Barcelona at the Mobile World Congress. How did a grassroots design project like Homegrown make it all the way up to the CEO of Nokia?

RG: Alastair Curtis, our Design Chief, was really instrumental in this. He just pushed really hard for us.

It's also, I think, much bigger than Homegrown. It shows how the position of design within Nokia has changed dramatically in the past two years. Nokia design is now involved in strategic decisions.

It also shows that Nokia is seriously acting on sustainability. We're already doing a lot in terms of corporate responsibility, factories, products, but now it shows that we are also taking action right from design.

RH: Since Homegrown has been released within Nokia, what has happened?

RG: We've been talking to people inside and outside Nokia about the project. We've been trying to share our experience, principles, motivation, and the story behind the project. The biggest impact we have had is showing people that it's actually simpler than it appears to be. A small change, a tiny change, with Nokia scale will have a big impact.

RH: There are a lot of people in the design field interested in sustainability, but I sense there is also a feeling not knowing of how to even begin or to start. What's been very inspiring about your project was the fact that you were motivated and passionate about something and decided to do it yourself. I'm curious if you have any advice for people out there in the design world who want to make a difference like this? How do you advise they start?

RG: I think you need to start with the things you care about and are personal to you. Start simple. Like one step at a time. None of the ideas from Homegrown are especially radical. We're not leapfrogging anything. Start simple. Just change a small thing and see what happens.

What we've really learned here is that a small thing by big numbers is probably the right way to go. And that's maybe a unique context for Nokia because we're so big. But even in your industry if you change something small, and do it immediately and simply, then you'll probably see results pretty quickly. If you're waiting to revolutionize your product or create something that is incredibly different it's very unlikely that it's going to happen. Start simple and build upon it.

Rooted in Research

How do we draw up Design Criteria, and how can they help our clients? Let's look at the case of a small company I've been working with. The company knew that users had difficulty dealing with its website, wanted to help them, and could explain some of the problems they were experiencing. It also knew that because its business is complex, one key problem couldn't be solved: users need to devote a fair amount of time to setting up an account. But it didn't think this problem explained its failure to turn so many prospects into customers.

We suspected that in dealing with account setup, people were having problems that hadn't been revealed by the company's site metrics or usability tests. So we launched an extensive in-context research study, mental model, and persona development exercise. We found that users rarely knew what to expect from the process, which constantly surprised them, particular with requests for new information. Often, they had to stop work to get this info. Users also consistently underestimated how long the process would take. Even two to three hours into setup, many said the whole process should take "about an hour." A number either quit before they'd finished, or grew increasingly frustrated, sticking with it only because they felt they had no choice.

The client can't do much to solve certain problems inherent in the setup process. Users have to retrieve information from their personal files and badly designed government web sites, and make decisions based on confusing tax laws. And users vary widely in their ability to deal with these obstacles, as well as with the site itself. We had to minimize the effect of all these factors, to make setup easier and quicker for everyone.

Enter Design Criteria

Project goals, success metrics, brand and mission statements, and universal design principles are all useful in their own way. But in improving specific experiences, Design Criteria can play the critical role, because they're research-based, and tailored to each project.

There's an art to drawing them up. They should give a design team clear direction, while leaving it room to explore different approaches to each problem. And they have to be clear and concise, but neither so reductive that they're open to broad interpretation, or so abstract that they don't suggest concrete solutions.

Let's look at a key pain point for my client's customers: information gathering. We knew that no matter what, they'd need to rely on a number of sources, and some information would need to come from other people. We could help them store and organize it once they had it, but couldn't help them collect it.

What Design Criterion would help us make this process less difficult? We could have gone with something abstract and general -- say, "Make information gathering easy." But what's "easy" in this context? And could we really make this process "easy?" We needed something more specific, pointing the way toward a viable solution.

We might have chosen "Tell customers upfront exactly what they'll need." But checklists didn't seem like they'd be much help.

So we settled on "Find Efficiencies." Working with this directive, the team looked at various stages of setup, and asked, "In this context, what does it mean to be efficient?" The next step was drawing up "dimensions of efficiency," such as streamlining data entry, asking at the same time for information that's taken from the same source, or entered in the same place on a form, and presenting tasks in groups, to make them more manageable. Following on this, team members asked more questions, such as: "How do we make data entry efficient?" "Can we provide access to electronic versions of necessary government forms, for example, and batch-upload entered data, rather than asking users to transfer it manually from forms to the system?" As we asked these questions, we built a base of ideas for creating workable, powerful solutions to the problems plaguing setup.

Generating Design Criteria

For most projects, I like to use five to seven Design Criteria. Too many, and the team can't remember them all; too few, and they won't cover all the problems at hand.

Rather than draw them all up at once, at the beginning of the design process, I tend to keep a running list of ideas as I work, making particular note of anything that jumps out at me as I look at the results of user research. At the end of the research phase, I put together the final Criteria, drawing some from my notes, and supplementing them as need be. Often our design team plays a key role in fleshing out the list.

A starter list might look like this:

• Ask customers for what they have, rather than asking them for what the company needs.
• Allow customers to say they "don't know."
• Provide a consistent experience, from interaction and visual design to copy.
• Be clear about what the system can do, and what the client is responsible for.
• Be friendly and reassuring.
• Show customers where they've been, and where they're going.
• Allow graceful recovery from unexpected interruptions.
• Make it easy for customers who need to gather critical information to pick up where they left off.
• Set clear expectations.

Here's where the art comes in. I'll sort the list, identifying items that can be combined or are thematically related. Once I have five to seven that are both unique and specific to the project, I refine the wording. I look for statements that are short and memorable. The statements should both help team members focus, and inspire them to generate ideas. Then I test each draft Criterion by asking myself:

• Am I inspired by this? Can I think of ways to translate it into real-life solutions?
• Does this challenge me to ask useful questions?
• When I show this to someone else, can they understand it easily?

When sharing Design Criteria with clients or those outside the team, I like to support each one with a powerful quote from user research, as well as examples from the Web and elsewhere, showing solutions that embody it. These supporting materials serve as a source of inspiration, and a starting point for further discussion.

Using Design Criteria Throughout the Design Process

I've talked about Design Criteria mostly as a source for generating ideas early in the design process. But they can be used throughout that process, to support communication, evaluate concepts, and quickly bring new team members up to speed. Keeping them short, memorable, and directive will give your team a great foundation on which to build elegant, powerful designs, then help them do so, from start to finish.

I constructed a robust evaluative checklist, listing every bit of potentially-interesting data I could think of, from layout grid choices to number of clicks. I wallpapered a room with printed screenshots representing every possible screen and state of every social networking site out there. As I was standing in this room, the magnitude of the task I'd created for myself caught up with me. At last, I asked what I should have asked in the first place: "What on earth am I doing?"

In Adaptive Path's collaborative fashion, I turned to my colleagues for help. Reminding me that, "the exhaustive is the enemy of the good," a wise colleague asked some vital questions to clarify my purpose. Answering the following questions ensured that every bit of data collected was useful and that the final deliverable was actionable.

1) What is the point?

Competitive analyses come in many flavors. Possible goals of competitive analysis include:

• Keeping up with best practices
• Identifying differentiation opportunities
• Evaluating performance against design principles
• Collecting patterns for inspiration
• Comparing features (ideally with respect to user needs)

Beneath goals lurk motivations, and where there are multiple stakeholders, there are usually multiple motivations. An executive's motivation for comparing features (e.g., to validate an existing design) may differ from a consultant's motivation (e.g., to prove the existing design needs work). Unearthing these motivations and making them explicit ensures that everyone is aware of and honest about any "hidden agendas."

Keep in mind that there's a difference between an agenda and a hypothesis. Say you take a cursory look at competitive sites and draw the conclusion, "Wow, all these banking sites look the same." If you set out to prove that this is the case, your agenda can skew the study and undermine its credibility. If you instead treat this as a hypothesis, you'll be open to proving or disproving it through the research process.

My client didn't need to know how their site ranked against competitors' sites. We all agreed that the current site needed work, particularly in helping users register and get established. Thus, I clarified the goal of the study: To identify an array of interesting solutions for sign-up and ramp-up that will inform the project team in redesign efforts.

2) What will the final deliverable look like?

Before you even start gathering data, get out some paper and a pencil and start sketching. Keeping your goals and motivations in mind, envision the final report or presentation. Picture how it will be used. Is it a reference resource that will sit on a designer's desk? Will it be passed around in workshops to guide strategy decisions? Who is the audience?

Understanding your goals, motivations and audience will drive the rest of the decisions. Should it be organized by competitor, theme, or both? What type of content will be on each page? What purpose will screenshots/illustrations serve? Will you want to reduce certain elements to simplified schematics, for ease of comparison? Do you plan to use a model or chart for comparing competitors (A matrix? A value curve? A positioning map? An alignment diagram or mental model? What will the points of comparison be?

Populating the sample deliverable with sample data is also helpful. Create a rough template showing the page types and fields you plan to have in your final report, and take a stab at writing sample content. Don't worry about accuracy, just use your intuition to focus on writing the right type of content. Sharing this sample deliverable with stakeholders ensures that you are all on the same page before moving forward.

By understanding and getting buy-in on how the final deliverable would be structured, I was able to ask the right questions about each competitor. I formalized my questions in a spreadsheet that I populated as I analyzed each site.

3) What are your criteria for selecting competitors?

Defining who the competitors are is a complex art that can merit a thorough study of its own. Chances are, your company already has a list, but don't take this list at face value. You must understand how and why these are considered competitors, which begins with understanding the characteristics of the product or service itself.

Try listing your product or service's characteristics, including industry, audience, channel, business model, brand tone, values, role in the user's workflow, and components. Brainstorm other products or services that share one or more of these characteristics. You'll quickly find that "competitors" includes more than direct competitors -- those who are competing in the same industry, for the same audience.

Partial Competitors' offerings overlap with yours, but only in part. Flickr competes with Facebook's photo sharing feature, even though Facebook offers a broader array of social networking features.

Comparators may not be competing for your customers at all, but share similar business models, branding, values, roles or components. AllRecipes.com and Wikipedia are both about sharing useful knowledge, but they are not direct competitors.

Substitutes are potential replacements for your product or service that may exist in an entirely different industry or channel. A classic example is Lexus. They realized they were actually competing with expensive jewelry and major travel: When people got a windfall, they'd either spend it on a Lexus, jewelry, or a big trip. Understanding what makes the alternative experience compelling can inform your experience designs.

Idols are those companies or products that one aspires to be like. Perhaps your company wants to be "The W Hotel" of day care centers. Investigate what that means, and how these idols' offerings might inform your study.

Once you've free-listed or otherwise gathered a broad list of competitors, comparators, substitutes and idols, you'll want to narrow the list down to a justifiable, representative selection, always keeping your goals and motivations in mind. One way to do this is to rate the degree to which each competitor shares the characteristics you listed. Competitors that are highly similar in one characteristic or share many characteristics are likely to be of interest. You can also map the competitive landscape using models like those described in question #2. Select one or two exemplary companies from each segment of the landscape and focus on those.

Since my goal was to discover patterns for sign-up and ramp-up, I determined that I was interested in sites that thrive on user engagement (and wouldn't have much value without it) and exemplify at least one novel user interface pattern.

The Results

While it represents a massive data-collection undertaking, The Feltron Annual Report is essentially a book of trivia. Competitive analysis reports should be useful and actionable.

Although data collection always takes time, answering these questions up front ensures that it doesn't waste time. By clarifying goals, envisioning the final deliverable, and carefully selecting competitors, I was equipped to produce a valuable deliverable that not only served the project team's needs, but became a valuable resource to other project teams at Adaptive Path.

Henning Fischer [HF]: What is IDEO's Transformation by Design practice?

Peter Coughlan [PC]: IDEO's transformation practice helps clients become more innovative, customer- or employee-centered, sustainable. We do this using some core principles of design and design thinking -- building empathy with stakeholders, envisioning a future, prototyping -- the stuff that good human-centered design is made of, this time applied to organizations.

[HF]: What lessons has IDEO learned from working with clients in this manner? How has the practice changed over the years?

[PC]: We've learned a lot about the difficulty of getting people to change behavior in organizations. So, we've really ratcheted up certain aspects of the process -- for instance, getting stakeholders to reveal what they really care about, making sure that visioning sessions are as inclusive as possible, and making change as tangible as possible inside the organization, so that people have constant reminders and prompts for behavior change.

[HF]: How do you get visioning sessions to be inclusive as possible without the too many cooks in the kitchen problem?

[PC]: You use visioning sessions as divergent activities -- you're trying to get as many ideas, from as many different perspectives, as possible. So, to extend your metaphor, during a visioning session you're not yet started cooking -- you're just getting people to contribute ingredients. They of course can have an opinion about what ingredients they like (which is important feedback, and you should gather that feedback in order to help you decide what you're going to make).

[HF]: In terms of creating tangible changes that serve as reminders and prompts of behavior change, can you give some examples? In the past Adaptive Path has created artifacts like booklets, t-shirts and posters to help refocus client teams. We have found them effective for shorter periods, but they occasionally become part of the furniture. How do you avoid that?

[PC]: What you're describing is more along the lines of promotional items. What I was talking about is artifacts that give you an excuse to behave differently. One of my favorite examples comes from a hospital that wanted to help reduce their patients' worry levels while they were waiting for (chemo) treatment. A very simple idea they had was to just go up to patients and ask them if they had any worries, any questions that they could address. It turned out that doing that -- going up to patients and asking them questions -- was very awkward and difficult to do. So they created an artifact to help them get over that awkwardness -- a set of question cards that they shared with patients to help break the ice and provide something to talk about. It turned out to be a wonderful way to prompt new behavior on the part of patients and providers. Even if the question cards do become a part of the furniture, that's okay -- they helped the care providers overcome a fear and scaffold a new behavior.

[HF]: How do you get clients to trust what in the surface is a seemingly simple process?

[PC]: Clients almost never trust the process until they've experienced it directly! So we try to build in experiential sessions very early in our relationship so that clients have the confidence to trust us and the process we lead them through.

[HF]: Can you describe some of the experiential sessions that you use to build that trust?

[PC]: We create experiences that last anywhere from half an hour to a few days. In a short session, we might present some evidence of people's existing behavior (workarounds are a favorite of mine), and ask people to tell us what the behavior reveals about a need. Then, we'll convert that need into a brainstorm topic and ask participants to help us come up with ideas. Seeing the link between an observation and an idea that helps meet a need (revealed through the observation) is powerful -- knowing that it's not black magic is comforting to clients, who understand why we're asking to go out and just hang out with people to inspire our thinking (which can seem pretty fuzzy and risky).

[PC]: If we have more time, we'll have clients work through the whole process. It's fun to see how different people "get it" at different points in the process. They're usually amazed with what they've been able to accomplish, and I think they then know that if they (as beginners) were able to come up with breakthrough solutions to tough challenges in a short time, then doing the same process with more experts and over a longer period of time can only be better.

[HF]: How common is it to find that decoupling between the vision functionality of strategy groups and the actual means to execute on that vision? What are the most common points of failure you see that create that disconnect?

[PC]: It's very common to find a decoupling between vision and execution. What I see often is that the organization needs to now build a business case for why they should execute on the vision (in its entirety). Then, they have to apply for funding; which, depending on when the visioning happened with respect to budgeting, can be up to a couple years. By the time funding comes through, the economic conditions have changed, a competitor has done something to make your strategy irrelevant, or you've actually forgotten why this direction was the right one in the first place!

[PC]: That's why we push clients to start down the implementation path immediately -- get some prototypes or experiments out into the system and see what you can learn, what evidence you can collect that will help you secure your next bit of funding, your next bit of support from leadership. You still keep a big picture view of where you're headed, but you break that view down into some bite-sized steps that reduce the risk and the feelings of overwhelm that come from trying to implement a strategy at scale in a single stroke.

[HF]: More and more designers are using similar methods to yours, which represents a significant step forward for us as a profession, but there still seems a long way to go. What can designers and managers do better or differently to advance the cause?

[PC]: I would say that the most important shift in the design profession will be for designers to get comfortable with the notion that it's more important for a client to have a great idea than for the designer to have the idea. If the client organization has played a role in coming up with the idea, it's way more likely to see the light of day.

[HF]: Adaptive Path believes the exact same thing, and we work extremely collaboratively with our clients to make that happen. The challenge we are most often faced with happens when the engagement ends and the client team struggles. How do we avoid situations like that?

[PC]: Well, the obvious answer to that is to anticipate the client team struggles, and design the program in anticipation of that. We started down this path by offering clients some "telephone consulting" or follow-up visits to hold their feet to the fire -- that's evolved into a more formal process in which we help them prototype the infrastructure they'll need to implement while we're still actively engaged. We're also exploring new models including "externships" (where an IDEO person goes to live with a client to keep things moving along), as well IDEO alumni who can embed themselves in our client organizations after we've completed our programs.

[HF]: Peter, thank you for your time and I look forward to hearing you present at MX San Francisco.

Cordell was behind the Mac OS X at Apple and is now leading organizational change at Cisco through product design for Cisco's voice, video, and web collaboration products. Cordell will be speaking on at our upcoming MX San Francisco conference on April 20-22.

Andrew Crow [AC]: Your accomplishments at Apple are well known. But with your new position at Cisco, you seem to have made a transition from interface design to user experience. What caused that shift in focus and do you see that as being a trend for other designers?

Cordell Ratzlaff
 [CR]: I've always just wanted to design products that people fall in love with. And that requires considering every possible way a person interacts with a product, from branding and packaging through installation, use, upgrade, and disposal. One of my pet peeves is with the specialized labels that have evolved within our profession. We have user interface designers, usability engineers, user experience specialists, visual designers, interaction designers, etc. The distinction between these many roles is fuzzy and confusing to those both inside and outside the design profession. Personally, I blame the information architects for this -- they think they need to classify everything.

I encourage designers to get as broad a range of experience as possible. Design products for as many markets, demographics, product types, and technology platforms as you can. Don't be afraid to take on tasks outside your traditional role. The best designers I know are good at many facets of design. It certainly doesn't hurt to know about branding, marketing, business models, and technology as well.

AC: Director of User Experience is a pretty high position. Are companies like Cisco starting to embrace design in ways that they traditionally have not?

CR: This is definitely a trend, and a good one at that! More and more companies appreciate the strategic value of design and see design as a way to solve business problems. This is a great direction for designers, but it means we all have to get more business savvy. There are a few things driving this trend. First, technology is a commodity. The cost of technology and the time to bring it to market are both decreasing. Technology leads are fleeting. Google launches a new feature. A few weeks later, you'll see it on Yahoo. When technology and time-to-market are no longer competitive advantages, design -- and the experience it provides to customers -- can be a strong differentiator.

Second, companies such as Apple and Nintendo provide great case studies of how a design-focused culture can have a direct affect on the bottom line. They've raised people's expectations for all product design, even beyond the consumer market. People who work in large corporations go home and enjoy the experience with their iPods and Wiis. Why should they expect anything less from the tools they use at work?

Finally, never before have competitive landscapes shifted so quickly and unexpectedly. The telecommunications industry is a great example. A year ago the industry was made up of lumbering giants competing to see who could suck less. Today they're going up against Microsoft, Apple, and Google.

AC: What about the opportunity at Cisco was so interesting?

CR: It was all about the opportunity to have an impact. It's relatively easy to do good work at companies like Apple or frog design, which have cultures that are tuned to turn out great design. Cisco offered a challenge to do the same level of work in a setting where design has not been part of the equation. The opportunity to impact Cisco's product design and create a culture that values and fosters great design was very appealing. I wouldn't have taken the job, though, if I hadn't seen a strong commitment from senior executives at the company: That they were serious about making design a core competency and willing to invest the necessary resources.

AC: How are you using your experience at Apple and frog design to help transform Cisco from a technology infrastructure company to one that delivers compelling consumer experiences?

CR: Much like the way things are done at Apple and frog design, we first defined the experience we wanted people to have with our products and then assembled or built the technology to deliver it. This was a big change for Cisco, which had previously been very driven by the technology itself. We revamped our product development process to include user research, design, prototyping and usability testing very early on, and used these activities to drive feature requirements and development.

After we established a user experience vision that was aligned with Cisco's business goals and technology, we built prototypes to show how the vision would be realized across our product portfolio. People got excited about where we were going and everyone focused in the same direction.

Since a big part of the vision is to provide a consistent user experience across our products, the prototypes showed what our products' user interface would look like and how the interactions would work on different platforms. A side effect of this approach was increased collaboration among product development teams, who were dependent on each other to accomplish this goal.

Along the way we've worked to dispel the myth of the distinction between "enterprise" users and consumers. We're all people, and our expectations and values don't change when we walk through the office door in the morning. We may do different things at work than what we do at home, but why should people settle for a lesser experience with the tools they use at work than they do with their iPods, and Wiis?

AC: How much of that transformation is winning the hearts and minds of people there? What have you found to be successful tactics?

CR: Ninety percent of the effort is about affecting culture change. The design work is actually the easy part. Transformation tactics that have worked well include:

• Inspiring people with a clear vision. A shared vision that people are excited about will take on its own momentum
• Setting high standards and sticking to them. We've sought out opportunities to point out that the old way of doing things is not acceptable
• Persistence. Change is hard and corporate inertia can be difficult to overcome. It's much easier to manage the status quo than to enforce change. Senior leadership communicates and reinforces the benefits of making this transformation every chance we get

Delivering and celebrating successes along the way has helped everyone see that all the hard work associated with the change is worth it.

AC: Is there one thing that you are passionate about? How does this help drive you?

CR: Making things simple. We have more options and choices than ever before, but attending to them all squeezes the time out of our lives. Great product design is achieved through what we leave out, not what we put in.

AC: Cordell, thank you for your time, I look forward to hearing you speak at MX.

What's Different About Managing Creative Projects?

Unlike projects where the approach and methodologies are the same from one project to the next, design projects evolve and change from project to project. They can also switch directions significantly mid-project. As with any member of the team, the Project Manager (PM) has to be flexible while representing the process and structure and tracking budgets and hours. The PM needs to be ready and willing to push back on the often enthusiastic and strong-willed Creative Project Lead and other team members.

The Project Manager is also responsible for fostering a healthy team dynamic. Creative teams often encounter conflict while refining ideas and making decisions. This is an anticipated part of the creative process. However, Project Managers are in the unique position to help cool things off when situations get too heated: Time, money, and the desire for closure are powerful arguments for resolving conflict and moving forward.

Communication: The Key Part of Every Team

At Adaptive Path, we think of Project Managers as "language weavers." One of the PM's roles is to help difficult words fall softly on the ears of the client and the project team. The Project Manager is also a broker who makes sure each party's interest is represented at the table. Often project management is a practice of diplomacy and sometimes a practice of "good cop/bad cop." In the case of the latter, it is best if both the Project Lead and the Project Manager deliver difficult messages. This provides a balance of delivering a constraint (i.e., limited hours) with an opportunity (i.e., ability to refine the design by focusing on high-level changes).

Setting Scope and Introducing Constraints

Creativity always requires constraints. Project Managers are in an excellent position to help frame constraints and lay the groundwork for successful projects. Setting hours and budgets help create the initial boundaries for projects that could otherwise continue on -- well, forever. Before any project starts, the Project Manager has to help balance the project's scope and get buy-in from team members. The practice of setting the scope becomes easier the more the PM works with a team. With greater familiarity, the Project Manager learns how long certain processes take, as well as the nuances of how each project member works best. Being realistic, even when putting on the pessimist's hat, while developing the scope of a project will ultimately make managing the project easier.

During each project, PMs must continuously manage constraints by setting expectations. This can happen by ensuring both team and client meetings are defined before they start. It's often just as important to clarify what a meeting is not about, as what it is about. Plus ensuring expectations for deliverables are established and agreed upon by the project team and communicated to the client. Again, defining each deliverable's value or purpose -- what it is and what it isn't.

PMs also need to actively manage the project's scope. With creative projects, there are lots of brainstorming and ideation sessions. There's no debate that this is crucial to the creative process. However, inevitably, PMs are in a critical position, as we call it, to "kill the darlings." They must be ready to assist their teams in figuring out what they can realistically accomplish given the time and scope of the project, and consequently, help them let go of many great ideas.

Know Your Tools

Just as designers depend on PhotoShop, Illustrator, and Flash, it's crucial that Project Managers know how to utilize their tools. At Adaptive Path, we use a mix of custom Excel spreadsheets to manage hours and budgets, a Web app for each individual's time tracking, and Basecamp for sharing deliverables and communicating with internal and client teams. Avoiding large applications, such as Microsoft Project, in favor of lightweight tools allows us more agility.

Measuring the Health of Your Project

During our weekly practice meetings, the project team updates the rest of the staff on client satisfaction, margin, timeline (week X of Y), and a topic of interest. This sharing facilitates learning; if two projects are encountering similar challenges, the teams can help each other or take lessons on how to successfully navigate similar issues. The Project Managers at Adaptive Path also meet regularly to leverage each other's experience, and identify how to improve our PM practice.

Where Project Management Can Fail with Creative Teams

Project Managers, like their practitioner counterparts, will often take on too many projects. Knowing that, PMs have to be keenly aware and actively communicate their workload to others. Two to four projects -- depending on their size -- may be reaching maximum. If PMs manage too many projects they risk becoming a task manager instead of a member of the team. (Clearly, no one likes to be told what to do by someone who has no empathy for the mood, challenges and/or successes of a team's project.)

PMs need to remember that the Project Lead and the other team members are knee deep in the trenches. And whether they're creating wireframes, visual designs, or conducting research, they've likely developed a relationship and connection to the work that's critical for project success. If the Project Managers have too many projects, they might lose their connection to the work and hinder the momentum of their teams.

Project Management Success

In the end, successful Project Managers know that each project is a living, growing organism and it cannot be rigidly contained. Designers create real value for people through beautiful, effective design. Project Managers create value through effective integration of people's skills. It's part art: Guiding the creativity and communication; and part science: Managing the hours and budgets.

We spoke about the new CCA MBA program, how design and management are intersecting in business and academia, and how integrated learning and a new emphasis on design in business is impacting the field of user experience.

Kate Rutter [KR]: So Nathan, let's start with the basics...what's the short and sweet description of the new CCA MBA program in Design Strategy?

Nathan Shedroff [NS]: The Design MBA (for short) is intended to prepare a new generation of business leaders knowledgeable of and comfortable with design-led innovation processes that create truly successful, sustainable, and meaningfully innovative products, services, and experiences. We are equipping change agents from the for-profit and non-profit worlds, whether they have a design background or not, to make change in the future.

[KR]: That's heady stuff. Can you give me an example of some of these things? For example, what does a design-led innovation process look like?

[NS]: Most attempts at innovation in companies haven't been terribly successful for a variety of reasons. They may not involve the right people in the organization, have a culture of creating new things from scratch, or they may not value ideas when they are presented. Sometimes, it's all about courage to do something different. Design processes, specifically, approach the challenge to imagine and devise new solutions, in any context, by looking at customers in meaningful ways, integrating data from a variety of sources, and using it as a starting point instead of an ending point. Design respects different kinds of prototyping and iteration, which is an important part of the process. Expectations in design processes are different from how most organizations expect every idea to be incredible, try to control the process from the top down, or inject corporate assumptions that are often not validated or reflect the market.

Different organizations have different innovation cultures but, no matter the approach taken, it is organic and dynamic and most forms of management tend to kill the process rather than nurture it. This is why organizations often have to rely on acquisitions or consultants from the outside to innovate or find the need to comfortably insulate their designers in a different area, under different management and expectations, just like they often do with R&D. This isn't always the best approach, however, since it tends to isolate as much as insulate.

You don't have to be a designer to learn to innovate like one, but it helps if you've been through the process a few times to understand what to expect and how the process needs to be supported.

[KR]: Why are programs like this developing? What's the compelling need that they fill?

[NS]: The business world is starting to wake-up to the powerful influence design-led strategy can have within an organization. In the past, design has been seen mostly as an appearance value to add at the end. Even today, you see articles every day in the business press talking about companies needing to pay attention to design to make their products "cooler." This fundamentally misses the value design can bring to innovative offerings -- especially the kind from organizations like Nike, Target, Method, and Apple, which are the examples often touted in these very same articles.

At the same time, the design world needs to wake up to the fact that the influence they seek in their organizations and client's organizations can only occur if they bother to truly understand the strategic issues at stake, the challenges within their organizations that fall outside the usual "design" function, and the language that the rest of their peers speak about these issues. It's starting to happen on both sides, but we have a long way to go and graduates from programs like ours will be the first influential ambassadors that can bridge these two worlds.

[KR]: In the past, it was Technology that became a strategic partner in the business, and we saw the rise of the CTO. Then Marketing seemed to be the big thing, and the role of CMO was created. What's the strategic role or future title for these design ambassadors? What change does this level of influence make in an organization?

[NS]: Well, I think Marketing was the big thing long before IT departments rose to the prominence they have. Most IT departments have a grip on senior management that is not healthy, simply because most senior managers don't understand enough of the details of IT to disagree, haggle, and know when they're being snowed. However, EVERYONE is a designer, so everyone thinks that they know enough to override design decisions, budgets, and processes. Organizations, however, are discovering that they aren't managing the design development process well enough and are listening more and judging a little less.

Designers need to be more than ambassadors, they need to be fully functioning and fully aware members of strategic decision-making teams in a company, though most aren't yet prepared to do so. Titles will be meaningless except within the culture of a company. In some companies, if someone doesn't have a Senior VP title, they just aren't listened to. In others, even though they have a title, if they don't have authority to start and stop work, they don't really have any mechanism to create change. One of our aims is to create business leaders who understand design-led innovation, not just designers who can enter these conversations or lead the design function.

[KR]: Before integrated academic programs like this, how and where did people gain these skills? What were the critical gaps in knowledge? What change is at play in the business world to create a need for the approach that you teach?

[NS]: Mostly, these leaders have taken it upon themselves to learn what they didn't get in school: either the appreciation for Design (that's with a capital "D") -- if they had a more traditional business degree -- or the language, tools, and issues of operations, marketing, finances, etc. if they had a design background. Much of these new understandings have been created on-the-job, through experience but, in some cases, people like me went and got formal MBAs or "traditional" business people went to get MFAs. The problem is that none of these programs integrate the perspectives very well. It's not enough to take a design course or two in your business degree (or vice versa) just like you won't come away with a very deep understanding of sustainability by taking a course during your MBA or other degree.

To truly understand these domains -- and to gain the experience and comfort necessary to lead through these perspectives, you need all of your courses to integrate and to work with them holistically. This is our approach. All of our courses, including Accounting, Business Models and Stakeholders, Finance, Operations, etc. integrate both a design/innovation and sustainability perspective. They aren't treated as foreign or related but crucially integrated.

[KR]: I have to ask this...what's the difference between Design with a big "D" and design with a little "d"?

[NS]: Well, different people define this differently but, to me, Design is about how people approach a challenge and develop a solution and, as such, these processes are extendable into almost any domain: interaction design, organizational design, etc. However, most of the time that the word design is used, it is often referring to a particular type of design or domain: graphic, industrial, web, interaction, fashion, interior, etc. and it invokes all of the baggage associated with that domain in both the speaker and the listener. How many designers have replied to the question "And, what do you do?" with "designer" only for the questioner to assume they design home interiors or clothes?

We also place a big emphasis on making solutions, not just plans. Each semester, there is at least one "studio" course where the emphasis is on putting theory into practice, building prototypes, and engaging customers. For example, our "Marketing" class is taught as a studio. It's not enough to run through all of the topics in a Marketing textbook, read some case studies, and build a marketing plan to show you learned the material. We want our students to learn by engaging customers with a variety of market and customer research techniques and use what they find to fashion new solutions as well as implementation plans.

[KR]: You've been a leader in experience design for over a decade. What's your long–term view of the impact of the program? What do you want it to look like in ten years?

[NS]: Well, one thing about the Experience Design field is that I didn't get into it with any view of what it would be like in the future. I just knew it was the right thing for the industry and me and it was grounded in observations and evidence that went back millennia. I have some of the same feeling with this program. Design and business aren't new, though the way they relate to each other at this point in time are. But, they reflect how they should have always been interacting from the beginning.

If I had to make predictions for this program in ten years, I'd simply say that it would be influencing a lot more people, both students and professionals, in a variety of ways. We will be publishing our experiences and perspectives in several media, we will be interacting with people and organizations in many more ways and media than we are at the beginning, and we will be constantly looking at new ways to help organizations better understand customers, markets, and the world.

[KR]: Design thinking gets a lot of buzz in the business press. What makes design thinking distinct from plain old regular thinking, and how do you go about teaching it?

[NS]: Designers are optimistic people who are trained to be courageous about the future -- and making the future happen. They aren't always aware of the intricacies of operations and the impacts of the solutions they propose, just like entrepreneurs, but they aren't afraid of confronting a blank piece of paper (or screen or board) and getting to work making something new. Engineers are much the same way, though they're often more regimented in how they approach a challenge. For the most part, designers aren't afraid of engaging people about their needs and they don't shy away from squishy issues like desire and emotions just because they aren't easily quantified. For sure, these aren't the only traits necessary for success, but they're crucial for innovators. In addition, designers aren't just shooting from the hip with pure intuition. Great designers have processes they rely on to investigate, ideate, prototype, iterate, validate, and communicate that they can employ to validate what their intuition may be leading them to. You don't find these processes, or such an approach to intuition, in the traditional business world. I think it's clear looking at how seldom true innovation is unleashed.

[KR]: It seems that a common attribute of similar programs is to blur the boundaries between fields, and to foster the ability to synthesize...to cross-pollinate concepts and ideas across different functional areas. With this trend towards generalization, how do you avoid teaching people to be, for lack of a better phrase, Jack-or-Jane-of-all-trades but master of none?

[NS]: This is a great question. There's no way we can teach students everything they need to know. We're specifically looking for passionate individuals who will take what we learn together and apply it to the passions, interests, and experience they already possess. Their learning is life-long so the best we can do is frame some of these perspectives and skills for them, give them some experience, and inspire them to continue the process. We've prioritized, in the curriculum, the skills, knowledge, and experiences we think they will need the most, but it's just a start. Besides, there's only so much you can learn in school. At some point, you need to learn "on-the-job" -- whatever that job may be. So, we're exposing our students to a variety of skills but with unified perspectives (design-led innovation, meaningful experience, sustainability, and visionary leadership) so that their deep skills will follow these lines. They will be expert innovation leaders and will be able to apply these skills to any domain or challenge.

[KR]: I'm all for a unified perspective. And thanks for giving us your perspective, Nathan. It's been a pleasure talking with you.

Don't miss hearing from Nathan and other experts who are defining the future of business at MX: Managing Experience Through Creative Leadership in San Francisco, April 20-22. MX San Francisco is focused on showing you what it takes to get great experiences out into the world. MX goes beyond typical design management discussions that remain focused on traditional concerns of print and brand, toward a new frontier of innovative products and service-oriented experiences.

Jesse James Garrett [JJG]: Hi, I'm Jesse James Garrett. I'm here with Secil Watson, senior vice president of Internet channel strategy at Wells Fargo Bank, and one of the speakers MX San Francisco, a conference focused on managing experiences through creative leadership, April 20-22. Welcome, Secil.

Secil Watson [SW]: Welcome. Hi, how are you?

JJG: Your talk at MX is going to be about the path that you took to your position managing a strategy team at Wells Fargo. Why don't you tell me a little bit about your background and how you found yourself in this position?

SW: Sure. I joined Wells Fargo and their online strategy team about five, almost six years ago. My background was in management consulting, marketing, servicing, customer service, as well as e-learning. I hads worked for consulting companies for a long time and then a leading e-learning company prior to joining Wells Fargo. When I came to Wells Fargo, my initial role was to help the company find a consulting company who would build a sales strategy for our online channel, which had been around for about five years. Wells Fargo Online was the first online bank.

When I joined the company, they were making the transition from being an online servicing group, where people could access their accounts and check their balances, to one where they could start a relationship with their customers, through selling anything from checking accounts to brokerage accounts to services on those accounts. When I joined initially, my role was to be a liaison with other consulting companies and do the strategy. What I realized very quickly was in order to make the website work well, be a selling website, and achieve the business goals that Wells Fargo had, we needed to make it more customer-centric.

Nothing in my background said customer experience specifically -- I don't think the term was even invented when I was going to business school -- so it was interesting for me to find other professionals who were looking at the customer and trying to build a group of user experience professionals who actually cared about the customer experience as much as I did and create it, on the go.

One of the first things we did was design some projects that would prove that we should base our decisions on the customer's point of view. The first project we did at Wells Fargo changed the homepage of WellsFargo.com from a marketing- and push-centric site -- a lot of advertising but not a lot of good ways for people to find what they were looking for -- to one that was more appropriate for customer tasks: the key tasks that the customers wanted to accomplish online.

JJG: Did you find, as you started to take on this challenge, resistance within the organization to taking this experience-focused view to the design of the website?

SW: The resistance came more from not being familiar with the terms and with the methodologies than it was because Wells preferred the other way of doing things.

I think that the Internet was still a new channel. As it had evolved, it had evolved organically and reflected the business organizational divisions of the bank. So our old homepage had tabs on it that said, "Personal Banking," "Personal Finance," "Investing," "Small Business," and "Commercial Services." You would maybe think that investing is actually part of personal finance; it is, of course, but in our case we had different groups organizationally that were managing the banking business versus the investing business, so they each wanted their own tab. This was purely because of the division of labor required to maintain their pages, update their websites, and have control over their domain.

It was not necessarily intended to be an experience for the customer. But when you actually show the teams that from a customer's perspective, investing and personal finance fall within the same realm, it does make sense to them. But in order to prove the point, we had to do a lot of user research, which was a discipline that was pretty new for the bank at the time. We had to teach product managers the principles of user research, the differences between qualitative research versus quantitative research, and how we could use both of them together to make a fact-based decision that would be more customer-centric.

The biggest hesitation we see in product managers, typically, is the time horizon for our decision. A lot of the time, we're trying to make decisions that are viable from business and technical perspectives, don't cost an arm and a leg, and are easy to maintain. That means they have both short- and long-term benefits to the company and that they have a positive business case. But they're also sound from a consumer's perspective, a customer's perspective that they actually are usable for the customer and also, hopefully, good experiences for the customers. To get those three things done, you can't be in an environment where one point of view is making a trade off that will make the other one worse. So we're in an optimization mindset, and in that optimization mindset, you had to do some give and take.

Product management typically wants to maximize the business value of the project, which translates to as cheaply as possible, as quickly as possible, and getting as much upside from the project as possible. What we were trying to inject into that culture was a look at the longer-term customer impact, from a broader perspective, and how to optimize for the customer's interest as well as the business interest.

JJG: It's been about five years since you started this, right? Have you seen a shift in the way the entire organization looks at customer experience?

SW: Yes, there has been a shift both for the Internet business of Wells Fargo and Wells Fargo overall. I think we have definitely created a language and a practice around user-centered design and experience management. We don't necessarily have the title of the chief customer officer or anything of that sort, but there's a lot of senior-level stakeholder interest in being able to manage things in a more holistic, systematic fashion, that actually takes a look at the customer experience across the group.

We still have product groups, of course: A home equity group, consumer finance group, consumer deposits group. They all look at their business from the product perspective, but they've also all incorporated some level of customer experience perspective that goes beyond just their product group or their responsibility area to look at the interplay of what the customer sees as one Wells Fargo.

There has been a change at the executive level. There's also been a change in the way that we do our work in that every single new innovation that we put out there and with every new product development project serves to make the customer experience better. Now, there's also a methodology of how we get the customer's opinion at every instance before we get something out the door. We're utilizing more user research and quantitative research to improve the overall experience. Looking at web logs and customer service center calls to generate quantitative data to support the customer's points of view. These results reflect what we hear in qualitative research and we make decisions based on those data points.

JJG: I think this is really a challenge that a lot of managers are facing right now in terms of building a user experience competency inside an organization as well as really being able to sell that competency and encourage the business to take an experience-focused mindset. What advice would you have for someone who is just starting out on that process?

SW: The first thing is finding a high-visibility project that the team can undertake and then using that project as a stepping stone towards getting broader buy-in from people in the organization. For my team, that was the homepage project and it was followed by other large redesign projects that we did on the site. Once you get an early win, use the methodology, policies, and practices that you're promoting as the crowning jewel of your argument of why this works with before and after statistics. You can get customer perspectives on how the changes impacted them; business data on how it changed the business variables, increased sales and interest in the company, reduced the phone calls to the phone centers or any other benefits.

Getting a high visibility project and being successful is definitely the first step. The second step is not just stopping at that project but really formalizing the methodology and making the methodology accessible to people who are not designers or content managers. To do that, you need to have a simple set of tools that you can brand and use consistently from project to project and introduce to people, like product managers or engineers or marketing managers, within the projects that you do.

For us, it was really important to have a set of user profiles that we could use in every project and similarly, a user task model that defined all the customer's managing financial tasks.

This model was a quantified task model: It told us what tasks people did to manage their finances, how frequently they did it, how important these tasks were, and how important the channels with a bank or financial institution was for people.

These two tools were very central to how we created a user-centered design practice. Having tangible tools plus successful projects allows for an easier transition when introducing people to the same tools and methodology.

JJG: Excellent. Well, thank you very much for your time, Secil, and we look forward to hearing more of your experiences at MX San Francisco.

SW: That's great, looking forward to it.

Edited for clarity.