The good news: whether it’s thanks to the economy or to the iPhone, more senior executives understand that they need to get some design love. The bad news: Most expect that it will be easy. Most execs who want to integrate design into their organizations (or expand the role of an existing team) ask us for help with training, establishing some best practices, or perhaps developing some design tools. Sooner or later, though, real success with such efforts requires attention to five different areas.

1. Process
   Figure out how design is going to work in your organization. This can’t be treated as purely a design process problem; you have to consider the product development process overall. How will designers work with product managers, subject matter experts, engineers, and others from early problem definition and concept through shipping product? How will you figure out what users and customers need, and what can differentiate your product or service from others? How will you arrive at one or more good solutions, and how will you ensure that they actually are good? How will you communicate, build consensus, and ensure accountability along the way? And how will this approach differ depending on the scale and type of problem you’re trying to address? While of course I’m a fan of Cooper's own Goal-Directed Design process and think it’s widely applicable, any process has to be adapted to its environment, whether because you need to comply with FDA regulations or because you’re tweaking the product for every customer. Of course, if you’re in a healthy, learning organization, your process will always be something of a work in progress.


2. Structure
   Determine not just how design teams are structured, but what comprises an entire project team. Look beyond the project level, too; where does design live in the org chart? How will you ensure that designers have close working relationships with their product teams, but still have an opportunity for design mentoring as well as sharing ideas and skills across multiple projects? What reporting line gives design the necessary authority to champion desirability alongside technical feasibility and market viability? What work will you do in-house, and what will you outsource? How many designers do you need, and do you need generalists, specialists, or both? Do you need to pair designers with business analysts or subject matter experts?


3. Skills
   Having process and structure without the necessary skills is a bit like sitting down at a table full of dishes without any food. What skills do you need, and how will you obtain them? It’s difficult to start or grow a design team without hiring some talent (especially design leadership) from outside. That said, there are only so many trained designers in the world, so some organizations build part of the team by training product managers or engineers who have the right attitude and aptitude. Even if you hire a group of experienced designers from outside, existing product management and engineering teams will need to learn some new skills to work effectively with them. How will you hire? What training will people need to begin with, and how will you ensure that new hires get the skills they need?


4. Tools
   Although experienced designers can get away with standardized tools, they’re more efficient if they’re not reinventing the wheel for every project. Less experienced staff often benefit from templates that help ensure they’re thinking through the right aspects of a problem, whether that’s a user interview, a description of design behavior, or a usability test plan. Engineers typically appreciate standardized styleguides and document templates so they get predictable output, too. It’s essential, however, that everyone understands the why of their tools; otherwise, documents and forms become part of a rote checklist and cease to be helpful.


5. Culture
   If you’ve ever bought a house, you’ve probably heard this little mantra: “Location, location, location!” When it comes to organizations that really put design in the driver’s seat, the chant should be “Culture, culture, culture!” I’ve seen clients with lousy process and average (or no) designers beat the heck out of the competition because they’re focused on delivering quality customer experience from top to bottom. Cultural change is the to-do item that nearly everyone neglects, and it’s the one that will make or break your success with design. What does your organization value? Consider what your hiring, evaluation, and compensation practices say about that. What do executives and managers talk about not just in big company gatherings, but also in day to day interactions? Where does the company invest its resources, and where does it take shortcuts? Developing process, skills, and tools without changing the culture is going to result in incremental improvements at best.
   
   
   If you try to change an organization without addressing its culture, you may never get where you’re going.

   
   Of course, you also need a plan for tackling all five of these areas in a coherent fashion. John Kotter’s Leading Change is a good place to start learning about what it takes to move an organization. Changing an organization is much harder than the toughest product design problem you’ve ever tackled; pixels, unlike people, generally do as they’re told.

In my closing keynote at Interactions 09, I spoke about some of the challenges facing interaction design as a profession, perhaps the most important of which is a shortage of designers just when the world is starting to demand what we do. Increasing numbers of college and university programs will help, but the fact is that interaction design—or any kind of design, really—is a craft that takes time to master regardless of one’s educational background. If you believe the 10,000 hour rule recently popularized by Malcolm Gladwell, that mastery should take something along the lines of five years doing nothing but design.

In my experience, people get more out of those hours when they’re not working in isolation, but are surrounded by more experienced people who can challenge, support, and advise them. Consultancies and large in-house design organizations often have some kind of coaching built into their structures and processes, and good managers are often good coaches. However, it can be hard to see your manager as approachable because, regardless of his personal qualities, he controls your career track and compensation. Sometimes, a senior person who isn’t responsible for your career is easier to get advice from. This is why everyone at Cooper with “senior” in her job title is explicitly expected to mentor others.

Unfortunately, not all companies have this kind of mentoring built in, and many young designers (or not-so-young PMs and engineers who want to be designers) work in environments without experienced design leaders. This is one reason the Interaction Design Association (IxDA) has decided to create a mentorship program to hook up people who’d like a little career coaching with those experienced practitioners who are willing to coach. As you might expect, so far the program has attracted more people looking for mentors than people willing to mentor.

So here’s my pitch to all of you potential mentors out there. First, mentoring isn’t a one-way transaction. As a friend of mine who recently earned his black belt in Aikido told me, a black belt isn’t a sign that you’re a master; instead, it’s a sign that you’re ready to become a true student. Teaching others will make you far more conscious of your own craft. Also, consider this: you, yourself, can only design so many products and services that make the world better. The people you mentor will go on to design many more. Finally, mentoring doesn’t need to be a huge time commitment; just an hour or two here and there can make a big difference.

So, what are you waiting for? Sign up to get a mentor or become a mentor today!

Just as every author needs an editor and every engineer's code needs QA, every designer's work can benefit from evaluation. Does it surprise you that I'm saying this? As UIE's Christine Perfetti once pointed out to me in an interview, Cooper is better known for advocating up-front research, effective process, and skilled designers than for promoting the value of usability testing and other evaluation techniques. It's true that given a limited budget-which most people have, these days-we think investing in these early-stage activities yields greater value. That said, evaluation is so important that every design project at Cooper has evaluation techniques built in. When, how, and how often we evaluate depends on the nature of the project.

Today is a big day for me. At long last, my book is going to press. It’s a soup-to-nuts how-to with tons of detail on every aspect of the method as it applies to a wide range of design problems and business situations. Visual, industrial, and interaction design are all integrated in the discussion, as are communication and project management. People have been asking for this book for years, so hopefully it will deliver what you’ve been looking for.

The writing is done. The 300 or so examples, exercises, and illustrations are finished. 750 pages of editing and proofreading and layout and color tweaking…all done. Now, whatever typos exist are going to be there for all time. Of course, there’s plenty still to do between now and when the book lands on shelves around the end of February: a Web site to assemble, a launch party to plan, and a sample chapter or two to select and share with all of you who read the Journal. For now, though, I thought I’d share a peek at the table of contents.

[You can pre-order the book on Amazon; they aren't listing a date yet, but it should be coming out in mid-late February.]

There's been a certain amount of buzz in automotive circles about the new SmartGauge dash display in the Ford Fusion hybrid. What's so cool? According to Ford, the car encourages fuel-efficient driving habits by giving users constant feedback. What's not to love about encouraging cleaner driving (if we can't get people out of their cars entirely)? Then there's the customizable LCD, which is what really has the car geeks going (check out this video of how it works).

Unfortunately, Ford missed multiple opportunities by thinking of the LCD as basically a digital translation of an analog dashboard--right down to the secondary km/h display on an "analog" dial--plus the ability to display some pretty pictures. The real benefit of that LCD is that you can show users exactly the information they need--and only the information they need--at any time. The less visual information there is, the more likely a driver (who already has a heavy cognitive load) will be able to make use of it. Unlike a physical dashboard, a digital display doesn't need to show engine temperature, for example, until it's becoming a potential problem. I suspect most people would much prefer to see their dash display driving directions or even the name of the song currently playing on the radio.

The visual display itself could be rendered much more legible. For example, it would help not to have lines running behind the numbers on the mpg display. If the green leaves are supposed to make drivers feel good about their behavior, that's a legitimate aim, but a simple gauge would make the fuel-efficiency of my driving style easier to interpret.

Since there's an onboard computer assessing driving style, Ford could have made better use of the information the car is already gathering. For example, if the car knows the fuel tank and battery are half-full and knows how fuel-efficient I'm being, why can't it save me some mental math and tell me how many miles I can go without refueling? Also, if it knows what makes my driving style less efficient than it could be, why not visually point out behavior (such as shifting to a different gear) that would be more fuel efficient?

Kudos to Ford for thinking green and for incorporating a long-overdue technology in the car dashboard. As is so often the case with technology products, though, I think I'll be waiting for version 2.

Every time I get on the phone with some corporation or other, I find myself reflecting on why voice interfaces are so uniquely infuriating. Clearly, I’m not the only one who thinks so, or sites like dialahuman.com and gethuman.com wouldn’t exist. I suspect the problem lies not only in wretched usability, but also in the fact that voice interaction sets higher expectations for reasonable, human-like behavior. If humans interact with computers as if they were also human, as discussed by Byron Reeves and Clifford Nass in The Media Equation, this seems even more true for computers other software-powered devices that accept voice input in addition to using voice output; after all, if it can understand what you’re saying, it must be able to think, right? In their very readable 2005 book, Wired for Speech, Nass and another colleague, Scott Brave, assert that this is indeed true. Hearing a human say, “I’m sorry, I didn’t understand that” three or four times in a row would be enough to inspire violent impulses in the most dedicated pacifist, and many people have similar reactions to voice interfaces. So is a more “human” interface necessarily better?

Even though we know we’re talking to a machine, we humans respond to perceived emotion even in recorded voices. For several days after we installed a new phone system in our offices, people continually commented on the doleful female voice that responded to deleted phone messages by saying “duuh-leted,” dragging out the first syllable and drooping at the end, kind of like a mopey teenager asked to take out the garbage. Discontented machines are especially noticeable, though excessive perkiness is irritating in some circumstances: “I’m sorry, you’ve been on hold for 20 minutes, so your session has expired.”

These days, more and more companies are recognizing that design and innovation are essential to their strategy and bottom line: effective design sells products and services, improves your position in the marketplace, and turns customers into loyal advocates for your brand. If you've gotten your organization to this point, take a moment to enjoy your success! Creating demand for design is no small achievement. Unfortunately, to reap the full benefits of design, you probably still have a lot of work to do on your organization's structure, processes, and culture.

One of the first things you need to do is determine where in your organization design belongs. There are a variety of models, from outsourced design to an in-house consultancy to designers permanently embedded in individual product teams. No single structure is the right answer for every situation; you have to assess what's the best fit for the number and type of design needs you have, as well as for your organization's culture.

I don't have to tell you that at Cooper, we love personas—how could we not?—and we're glad to see continued excitement about them. That said, although personas are essential design tools, we think some people may be losing sight of the fact that they're just tools, and tools with a specific purpose, at that. Lately, we've been seeing a lot of gold-plated hammers—unnecessarily elaborate communication about personas—and some fundamental misunderstandings about the relationships among research, personas, and scenarios.

It's a given that we at Cooper—and most of you reading this article—believe design is the right tool for translating market needs into tangible product specifications. The people who hire us to design their products or who attend our Cooper U courses think the same thing. Unfortunately, the best designs and the best intentions won't always lead you to success, because the problem goes beyond your product and beyond your design or development process. Building better, more innovative, and more profitable products requires organizational change on a deep and difficult level.

When design pilot projects fail, it endangers everyone's willingness to adopt design methods. Over the course of doing hundreds of design projects and teaching our methods to more than a thousand people, we've seen that several reasons for failure keep showing up. A discussion of these reasons follows, along with some solutions to consider. Let's start with the easiest ones and work our way up.

In most of the organizations we encounter during our consulting work, programmers tend to think they’re the best-qualified people to design the form and behavior of a product. In the absence of trained interaction designers, they may be right. They know from experience that no one else is going to think through all the implications of serving up that snippet of data in just the right way, and no one else questions the idea of programmers doing the interaction design because they assume it’s a technology problem. As a result, executives who lead technology initiatives believe that they already get interaction design for free from their programmers. In their opinion, having interaction designers is unnecessary; if the product happens to be hard to use, they assume the programmers just need some sensitivity training. Having programmers design the product is anything but free, though; it’s ineffective, inefficient, and risky.

Over the last two years, we've heard from increasing numbers of executives who want to bring interaction design in-house because they've realized how critical it is to product success. There are plenty of challenges involved in doing this, including hiring and training the right people. One of the challenges companies may not expect, though, is in deciding how to use those resources once they've been found.

The usefulness of personas in defining and designing interactive products has become more widely accepted in the last few years, but a lack of published information has, unfortunately, left room for a lot of misconceptions about how personas are created, and about what information actually comprises a persona. Although space does not permit a full treatment of persona creation in this article, I hope to highlight a few essential points.

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design.