CHI 09 Panel: Moving UX Into Strategic Importance

At CHI 2009, I took a lot of notes at the panel "Figuring Out the 'One Thing' That Will Move UX Into a Position of Strategic Importance." This is a rather random summary of it; see a similar topic in my post on User Experience Organizations discussed at BostonCHI a couple years ago.

Jim Nieters, Director of UX at Yahoo!, advocated speaking the language of business, and addressing business concerns in our design work and priorities. UX at Yahoo is now in marketing, after another reorganization. They will be providing input on the product funnel, helping to prioritize company efforts.

He reminded us that even at the executive level, it's a life or death battle, and everyone has someone to answer to at the end of the day. Convincing stakeholders of the design profession's value is less important than delivering as individuals; we need to be personally accountable for our work and stay focused on the right projects.

Regarding the standard issue of having too few resources: Invest in projects carefully. A team too diluted on too many projects can't be as visibly effective. Turn things down, and focus on the most important. Work on the revenue generators, and work with the business to understand the right problems and the solutions that can come from design.

During questions, he revealed that for products to move forward at Yahoo, they need "3 in a box": key stakeholders from Product Management, Engineering, and UX have to all be in agreement before work proceeds. Sounds good to me!

Laurie Pattison, Senior Director of UX at Oracle, was up next. Her message was that you get one chance, and have to sell yourself well. You only get one chance to make that first impression. At the management level, you have a calendar quarter to make an impact. Since you can't succeed at everything, you need to pick projects carefully, and provide business value. Businesses are in the business of money, after all.

As part of the sales process, deliver something other peers at the company can't do themselves. Make smarter wireframes, prototypes, or more attractive deliverables. Come up with innovative ideas that they can't think of themselves and the value will be clear.

Her example case study was a project to help reduce tech support calls. The team did simple usability studies and discovered that users couldn't find answers to items that were in the documentation. Their redesign put answers in context and reduced the need for the search functionality; the number of calls reduced as a result, and the bottom line was visible. The CEO was educated about the process and methods and it was a clear win for the team and their methods.

One questioner asked her why not just do this on every project, it's the standard research and design process. But resources limit what you can work on. "Pick projects that matter to the bottom line. You pick mind share or market share."

In a somewhat depressing note, several panelists agreed that your team (or your contributors) are only as good as the most recent success, that failure follows them around forever otherwise. "If you spend only ten minutes working on something because you don't have time, and it fails, people will remember you were associated with it and blame you. Better not to work on it at all." I'm disappointed when I hear this sentiment, given the recent discussions in other places about taking risks and embracing failure during design. I'm afraid failure may be a luxury for very well established teams.

Craig Peters, consulting as Awasu Design, argued that we need to pay more attention to the individual contributors in our organizations and their basic skills and effectiveness. "No matter what the strategy, if we don't think about the individual level interactions, the big picture won't be helped." He described a situation at Wells Fargo in which a UX team had reached a limit on their effectiveness; and he investigated and found that non-UX colleagues had had varying types of interactions with the team and found no consistency in their expertise or work. (I'm reading this in - Craig was pretty vague about the actual details of the findings and recommendations for improvement.)

During the questions, the panel and audience debated some on whether we count as a "young" field after 20 years of CHI conferences. Regardless, it does seem that different skills may be needed to convince different organization types and sizes.

Lauri represented the absent Killian Evers, UX Program Manager at PayPal, who argues for the need for program management skills in larger companies. Program managers can successfully bring metrics and rigor to UX and bridge UX and development. (I myself agree with the need for project management everywhere, but think that UX teams need to be able to work with software culture metrics, processes and tools, and there's no excuse for requiring a third party to manage this. But I may have misunderstood the points here.)

Some comments made during the question period, not all of which I was on board with:

• If your company doesn't value your contributions, move on to another one. Corporate Darwinism works.
• Don't waste too much time on ROI attempts. Testimonials from internal folks can go a long way. If you can find someone who needs something and you make an improvement, communicate it afterward with a story. Could even create internal portfolio of examples to help support your value.
• "If you're in a confrontation or argument, you're already lost." (I find this of some concern; many dev cultures produce lots of argument and confrontations, and if UX people aren't allowed to play in those, the field is not level and we're really handicapped.)
• The impression of many UX teams is "often you come in too late, you don't understand our jobs, our deadlines, our deliverables." My comment: Who's fault is this, actually? Bring us in earlier, etc.
• UX teams without domain knowledge can be seen as liabilities. Response: Get them educated about the domain, it's part of onboarding.

Finally, there was an acknowledged tension between the desirability of being an outsider brought in for point expertise ("like a lawyer") or a team member long term. These are obviously very different models, for staffing, for hiring, for seeking positions of corporate influence.

At this panel and at the one on "Fault Lines of UX," individual contributors asked how they can make change as single UX people alone in non-UCD environments. There were no simple answers for these folks. I particularly feel for the student who said to me after the Fault Lines panel, "I was taught UCD very rigorously in school, and I thought everyone did it. Now I find out most companies don't. How can I proceed, what should I be doing?"

An ongoing exercise for our profession, as mentors, educators, and colleagues... We need to help her.