“That’s not to say you don’t go for the talent if you can; of course you go for the talent. But the work only begins there. The solution to this too-many-cooks problem is leadership.” – Matt Drance

At HIVE 2011, Hillel Cooperman, Co-Founder of Jackson Fish Market, emphasized this idea in his keynote: most organizations don’t have design leadership. They’re using metrics they learned from B-school to apply to something they don’t get, and designers are rarely in decision-making positions.

At the most recent Seattle Info Camp, while Ario Jafarzadeh talked through 10 Observations from 10+ years in the Corporate UX Trenches, I noticed a theme: it’s not just the software and user experiences we work on that are broken, the corporate environment in which we’re working in is also broken.

Today, Marco Arment penned four steps on how to bring good design to a platform, and step one starts with the top, again.

“Demonstrate from the top that high quality and attention to detail are prioritized and appreciated above everything else, including being the first to market, having the most features, or having the most aggressive prices. If you can get those as well, that’s great, but quality will not be sacrificed to do so.” – Marco Arment

Are you seeing this pattern too? Is it too hokey to chant leadership, leadership, leadership? If there are people trying to improve the experience of the users, who’ll improve the experience of the corporations?

UX is kind of a big deal these days (and not just in Japan), but it has gone a long way since the early days, like… five years ago. It’s a Good Thing, and along with that comes some responsibility.

But first let me give you the backstory for context.

The UX in Me: A Long Time Ago

I became interested in doing User Experience Design during my sophomore year in college. Only, it wasn’t called User Experience Design then. It was Usability Engineering, and User Centered Design, and Value-Sensitive Design, and Library Science.

I majored in Informatics at the UW iSchool, and I totally digged (pronounced /dig gid/) it. I was one of those _really_  annoying and overly enthusiastic kids that would sit in front of the class and go to the professor’s office after class to talk about things like “models of information search behaviors in antiquity”, or something similar reeking of fancy academic speak.

I knew that the other kids talked about me with their eyes rolled in the back of their heads, but I didn’t care (a lot). I drank the Kool-Aid big time, and I was also protected by the bliss of already being an outsider in high school, realizing early on that being popular and cool was not my game to win.

When I finished college, I wanted more than anything to do two things: 1) run off to Thailand to bartend at a dive resort and rock climb, and 2) do User Research for social technologies. 1) wasn’t really an option, at least not while my parents were still paying for my expenses, and 2) was due to an internship I had at Microsoft Research doing participatory design and studying mobile and social patterns.

Getting Jaded

I ended up at Boeing where I worked in the Usability Engineering group and got a taste of, among other things, how inconsequential doing UE was, at least in that context. Don’t get me wrong, there was a ton of good work going on, and I learned how to fit Usability in a larger corporate software development methodology and cycle. But boy, I lost faith fast in how much good I could do in the world with my choice of profession. In other words, I got jaded.

I thought long and hard, and longer and harder, about what I wanted to do in life. I started doing Business Analysis, because BAs get to gather and write requirements and create functional specs, and those specs get read by software developers and they build the code, which become the software, which gets used by the user.

I liked the idea that that’s how I’d make a difference in the world. I was all over it. I read books, I went to seminars. I wanted to be the best requirements gatherer I could be. I wanted to be the T.S. Eliot of functional specs. But, I gradually discovered how requirements gathering was awkward for me. It went against a lot of the things that I had learned and personally believe in when it comes to making software. As the guys from 37 Signals say, there’s nothing “functional” about a functional spec.

Once again, I lost steam. Once again, I dreamt about bartending and rock climbing and teaching yoga on the coasts of Thailand.

ZOMG, UX is Back!

Five years have passed since I graduated with an Informatics degree, thinking I could improve the usability of software for the average user out there and wouldn’t it be great. During those years, I gave up and rediscovered that notion, just to give it up again.

And now, UX is en vogue. I have a theory that this is partly thanks to Steve Jobs, who’s proven that good and thoughtful design actually makes money! I remember doing Usability Engineering and being told, “Thanks for the lovely report, but it’s too late, and we have no time or money”. I remember being told “the user is a four-letter word”, and that “that touchy feely stuff doesn’t pay the bills.”

How time has changed.

The other day, I was reading this article about User Experience in Forbes, (yes, Forbes!!!): Why Apple Will Hold Its Tablet Hegemony With iPad

What is Apple’s “secret” to success? What Apple has delivered in the iPad and has consistently delivered in all of their products is a “user experience.” Somewhere around 1967, our culture began to focus on experiences, not attributes, and ever since then marketers have made millions selling books on branding, emotional branding, rethinking design, conventions of experience, et cetera. Yet, technology companies fall into the same old trap of touting attributes (GB, RAM, 4G, et cetera) instead of theexperience.

If the competition just tries to compete with Apple on functions, they will not be well served. The tablet category is just beginning. Apple has emerged as the clear mind-share leader and the only way to compete is to focus on user experience (usefulness, simplicity, elegance, consistency) not the product attributes.

Where was this article when I was a 24-year-old trying to justify my existence in the professional world?

Consider another article from MondayNote by Jean-Louis Gassée: The OS Doesn’t Matter

Windows will live on — in a PC industry now at a plateau. But otherwise, in the high-growth Cloud and smartphone segments, it’s a Unix/Linux world. We need to look elsewhere to find the differences that matter.

The technical challenges have migrated to two areas: UI (User Interface, or the more poetic—and more accurate—UX, for User Experience) and programming tools.

Now that all “system functions” are similar, the game for hardware and software makers is to convince the user that his/her experience will be smooth and intuitive. Your device will walk on water (with the programmer right under the surface), catch you as you fall, make sure you don’t get your feet wet.

Great, so now the bar is “your device will walk on water”? Can I just have a minute to put some hot air in my head and get some “I told you so” vindication first?

No, really, in all honesty, I’m glad it has worked out this way for the UX profession. Actually, I’m grateful. Grateful that I am in a field that’s getting recognition, which means I get to have a job, which means I get to go to work tomorrow doing something I believe in. I’m grateful that I get to get worked up over first-world-problems, such as, “look at how this form assaults your senses.”

And Now the Dirty Word: Responsibility

So now that I’ve boasted about UX as some kind of Double Rainbow, allow me to bring up the sticks: what I’ve learned about the responsibility of being a UX Designer.

Play Nice

Though I didn’t always enjoy doing other types of work: Business Analysis, Project Management, Product Management, etc., the one thing that I got was experiencing first-hand the challenges of those roles, and I’ve come to sympathize with them. UX Designers can occasionally (and understandably) run into conflict with other roles on their project, and I’m glad I have some perspectives on what they do.

As someone who’s classically trained (uh, whatever that means… to me it means I followed a structured curriculum from people with lots of acronyms after their names) in methods of User Research and Interaction Design, there have been times when I was ready to hurt something, even a cute fluffy animal, when I attended user interviews or acceptance testing.

“Oh my god, for the sakes of everything that’s holy, don’t … do… it!” I would silently think when I hear one leading question after another.

I’ve realized, though, that my findings from user research mean nothing, my wireframes and brilliant UX Guidelines are totally useless if there are no developers coding and breathing life into them. I wouldn’t get to put my headphones on and obsess over the taxonomy of a system if I didn’t have a PM worrying about allocating time and money for the project. I wouldn’t even have a job if I didn’t have someone out there courting clients, selling work for me to do. In other words, I can do no good without all these people. So what if their universe doesn’t include the difference between Utility Navigation and Content Navigation?

UX is not more better than any other roles on a project, and I’ve learned to not get too smug. Or, to get smug, and get over it.

Clarify and Eduhmuhcate

I don’t know what the right word to use here is: Educate sounds heavy, Evangelize sounds corporatey (not to mention… uh… churchy?). But, I hope you’ll know what I mean when I’m done.

UX is still new for a lot of people and organization. You can’t just show up and say, “Who wants some UX?” To make things worse, there’s a bunch of *stuff* that goes into what we call UX. In fact, I’m willing to bet you right now that what’s in my mind is not exactly the same as what’s in your mind about UX. It is this fact that makes things so fascinating and frustrating.

UX could mean Information Architecture, Interaction Design, Usability Engineering, Content Management. UX could mean for some people styling CSS, creating viral videos, and configuring a content management system (it’s not). UX could mean Personas, Wireframes, Scenarios, User Research, Interviewing, Contextual Inquiry, Participatory Design, Prototyping, Dreaming About Unicorns and Rainbows, etc. Are you getting dizzy yet?

(Also, UX for some people is bullshit. Please say a prayer for them.)

My point is, I’ve learned to ask first, “What do you mean by UX?”, and “What is your expectation of how I can help?” If someone wants me to create a Flash or Silverlight spinning ad, I know I’m the wrong tree for them to bark up.

My second point is, I’ve found it really useful to keep educating myself, and then others, especially with being as clear as possible the difference between the techniques, which is different from the goal, and why/when/how to do what for what purposes. The more people that I explain UX to, the more people who can 1) explain UX to other people and generate more work, and 2) the more we can play nice with one another.

Congregate

Before I started doing my Yoga teacher training, before I started taking up meditation seriously, before I ventured into learning Buddhist philosophy, I didn’t know what a sangha was. I didn’t pay much attention to other people doing the same thing I was. Don’t get me wrong, I went to UPA and CHI meetings. I went to InfoCamp and MindCamp and I signed up for all the UX user groups listservs. But I didn’t really think to have… for lack of better words, UX homies.

I mean, I recognized the importance of being part of professional groups, but it was for … you know, resume-building purposes. I didn’t think of people in the field as my support group, or cheap therapy, or, just anyone fun to have a drink with. (And while I’m airing my dirty laundry, when I came into the field, I had a feeling that everyone was older and boring. Who else would get together to knit and talk about indexing? Not me! )

Back to sangha. Sangha is a Pali word roughly meaning “community”, specifically a community of people working towards the same vision. In the Buddhist context, that vision is liberation. Once I realized that I could not meditate on my own without a teacher, I went for help. Then I discovered the benefit of talking to people going through the same experience, having the same struggle, and discovering similar insights.

I took what I learned from that into the UX world. I’d go to workshops not just to learn about the topic at hand, but get to know the participants. I’d seek out prominent people in the field and see what they’re up to. As I get older, I’ve come to see that obsessing over taxonomy and classification is not *that* insane to do on a Saturday night. Either I’m getting more boring, or those things are getting more exciting. Or both.

Regardless, I’m working on building my own UX sangha. Whether we’re rigorously debating the merits of tabs as navigation, or just letting our hair down and wondering what the heck Design Thinking is, we’re bonding, and hopefully supporting each other in this still-nascent field.

To the Future

I’ve noticed that there are two broad strategies companies use for hiring, and I have given myself the liberty to use them as predictors of how those companies or organizations view Growth and Innovation–yes, that I word that we all vie for. (I recognize I’m generalizing here, but humor me just for this post.)

Method I: Hire Someone Who’s Done the Job Before

This is the easiest way for a company to hire. Does your resume show that you’ve done this? Check. A lot? Check. And successfully? Check. And you’re not wanted by the FBI or the the State Psycho Ward? Check? Great. Chances of you being hired? Pretty high at this point.

I’d say this method is ideal for employers who has limited resources, in both time and person, and just needs things done, fast. The employer knows exactly what needs to be done, now. This is ideal for the job seeker who’s perhaps a contractor, someone that knows exactly how to do the job in their sleep. Someone to just press Go, basically.

Pros: Minimal training, in and out, execute and run.

Cons: Eventually the employee is bored of doing the same thing and wants to learn something new.

In chapter 7 of the book 97 Things Every Project Manager Should Know: Collective Wisdom from the Experts, Richard Sheridan advised, “Add Talents, Not Skills, to Your Team.”

I realized we had stopped investing in our employees’ growth. We weren’t looking for fresh, new talent. We were looking for very specific, already refined, skills. Now, I tell people that if they see an employer hiring for an exact skill match, what that employer is really saying is, “We don’t plan to invest in you.”

My advice to anyone seeking to build a strong team is to hire for talents, not for skills. What talents do I look for when hiring technologists for my agile development teams? Good kindergarten skills.

Method II: Hire Someone Who Can Grow Into the Job

There’s another method of hiring, which may seem riskier at first, but with risk may come rewards, and that is to hire someone who has what it takes to grow into the job and take your company, or project, further.

So how do you know if someone has what it takes?

Randy Nelson, the Dean of Pixar University said, the problem with resume-based hiring is a lot of the jobs out there fall in the category of Doing Innovating Things for Innovating Companies, which means doing things you’ve never done before. So, what does Pixar do?

Depth-Based Search

Everyone is looking for someone who’s really good at something. We often see this advertised as, “HOT_SKILL Rock Star needed!” (Never mind the fact that rock stars come with some other issues, but we’ll ignore that for now.) However, what if that Something To Be Good at has never been done? What if that Something calls for a lot of creativity and innovation?

According to Mr. Nelson, Pixar looks for someone who has truly mastered something in their lives. Why? Mastery of anything requires a level of commitment and self-determination. It’s proof that this person has a certain amount of ability to recover from errors and succeed, because to master anything means that you necessarily failed in that arena at some point. And, if someone has learned to master something, chances are they know what it takes to learn to master something else.

Breadth-Based Search

Another thing to look for in a candidate? Someone who is interested, someone who’s interested in a wide range of things, and who’s interested in learning to communicate in the languages of those things. Because communication is the root of collaboration. As Randy Nelson said, “We certainly don’t want any one-trick pony.”

I remember reading something about ninjas once (don’t laugh), and that they were always encouraged, well on top of staying in shape and all that, to study a wide variety of things, like poetry and the arts. Makes sense, if you’re gonna be a ninja, you might as well know how to write a haiku, right?

Collaboration

Having done Improv, Mr. Nelson’s messages hit home for me. Two core principles from Improv:

1) Accept the offer: if someone says, “Wow, you changed your hair!”, you should say, “Yes, I thought I’d go green like everyone else.”, not, “No I didn’t.”

2) Make your partner look good: If you’ve ever been on stage with bright light shining in your face and you know out there in the dark are 20, or 200 people wanting you to make them laugh, wanting you to make their Saturday night date go well, you know the anxiety can be high. The last thing you want to have is a partner, a team member, basically, who isn’t helping your game.

So, Depth, Breadth, and Collaboration, that’s how Pixar does it. And it seems to be working out well for them.

The core skills of innovator is error-recovery, not error avoidance.

The video below goes into more details of The Pixar Way, and it’s a good watch.