Comments on Pioneering a User Experience (UX) Process

Carolina Leslie — Tue, 26 Jun 2007 20:44:15 GMT

Great article. Very timely for me. As some people already commented I also have a problem with the “Go Deep, Not Wide” part. I was hired to start a UX process, and it is implicit that I don´t get to say no to projects. In spite of that, I have one small project in which I´m paying special attention.

Eric Reiss — Mon, 25 Jun 2007 10:51:04 GMT

Amy, you say many important things here. Thanks for an excellent review. However, the first of your two arguments, “A UX process helps build products people want and need,” while true, is not always convincing. This is because the CEO or developer or product manager who dreamed up an idea usually believes that this IS a produce people want and need. Why hire a UX expert just to tell them something they already think they know?

Napoleon put it well when he said, “There are two levers with which one can set a man in motion – fear and self-interest.” Hence, if the CEO or developer is accountable to somebody (or some body) higher up, you can play the fear card quite successfully – “What if people DON’T want or need the product you are promoting? I can help you make sure your product becomes the success you envision.”

Another card you can play is “UX is the key to getting your innovation process moving.” Most companies these days get all starry eyed when they hear the word “innovation.” And true innovation ALWAYS solves a problem. If not, so-called “innovation” will invariably create a problem. And the CEO doesn’t want problems. It’s a back-door kind of approach, but it can be effective.

Sorry to sound so crassly political here, but these are often political decisions. And while money is always an important consideration, contributing to the personal success of the stakeholders is usually more compelling.

Juan Ruiz — Thu, 17 Apr 2008 16:28:39 GMT

Good article, Amy and B&A Staff. It is always important to remember how to evangelize the IA and UX practice. I have found that lately our community (we) have been focusing on Enterprise IA or IA/UX for major projects, but, what about small projects? What about small-to-medium businesses that are just learning what IA/UX means? Or don’t have an idea of what IA/UX is?

In my case, I work for a non-profit organization. I have introduced these new concepts onto their project management methodologies, but it has been a very tough road. A major roadblock was that my clients were used to work with Business Analysis documentation and deliverables, and I had to modify my IA/UX findings to look and read like BA documents. While I found this frustrating, I understood that, I had to speak their language first before they speak mine. Now, my documentation is looking more like IA/UX deliverables, but like I said, it took some time to achieve this.

One of my best days at work was when my supervisor (PM) was training a new employee and she was introducing IA/UX methodologies to the new team member. That’s when I knew I was making a change!

Keep up working on evangelizing our profession. While I feel that large corporations know about it, we still have to educate small-to-medium businesses about IA/UX methodologies and the ROI of implementing them. Like Seth said: “Often times, it’s more about the person than the process.”

Shuan Lo — Sun, 24 Jun 2007 05:54:17 GMT

Excellent read. I got to share this article with my team.

You mentioned about finding out what your company’s goals are and align your UX goals accordingly. I would like to act a little bit more on that. I attended a panel session last year. One of the panelists, a senior user experience specialist from Ciscio, said this:

If you ask a designer in a company what he or she wants to achieve, he probably would say something like “I want to design wonderful and usable products that satisfy the users”. If you ask the top management why he wants to employ the designer, he probably would say something like “I want him to help me make more money for the company”.

It is not uncommon for the user experience professional’s goals to be misaligned with respect to the corporate goals; we should aware and be cautious. Sometimes wonderful and usable products may or may not be enough to help the company to increase its profits. If we keep this in mind, we may become less frustrated, happier, and more readily accepted by our business clients.

Seth Gordon — Mon, 02 Jul 2007 12:03:21 GMT

Many good points, especially the wrap-up about promotion after the success is achieved.

I’ve gone through the evangelism and department building process more than once, with mixed results, but have learned each time. The one thing that really helps moves things forward is establishing yourself as a credible resource that can deliver on the plan. Once your organization believes that you are truly a subject matter expert on the topic, they become more inclined to support you. Some things that I’ve found help on the credibility front include:

having implemented a similar process elsewhere
reading/writing articles and books <!—which you just did!
being well connected to your experienced peers.
etc.

I remember 10 years ago I wanted to start a usability practice at the consultancy where I worked. So, I talked to the bossman and told him my idea. His general reply is ‘what makes you such an expert in this field that I should support you in building out the practice’. Good question, and one that naively, I hadn’t really given much thought outisde of reading Jakob Nielsen’s book.

In the following months, I wrote a few articles, connected with peers in my local community, spoke at a CNet conference, and viola, I had some legitimate traction and street cred, which made people more willing to trust in my expertise.

Often times, it’s more about the person than the process.

Chris Cocca — Fri, 22 Jun 2007 21:20:58 GMT

I found this article particularly timely – so thank you Amy! As someone in this position now, many of the things written ring true.

Chris Collingridge — Wed, 27 Jun 2007 18:31:30 GMT

Excellent article, and good advice. My mantra has been “add value”. Think about what you can do that adds value to developers, marketing folk, technical support, and so on. By asking yourself (honestly) whether you can really make an almost inarguable improvement, don’t do it. By only acting where you know you add value, you build positive memories in people that are a basis for further cooperation in the future.

Basically, this is the “low fruit” you talk about. In a more mature situation it’s harder to make obvious improvements, but in the early stages (and in many companies these “early” stages could be many months, if not years) you can really benefit from being perceived as a problem solver rather than a hassle. Someone who makes less work, not more.

And good luck to everyone taking this on!

Terry Bleizeffer — Fri, 22 Jun 2007 20:22:22 GMT

Giving this a little more thought, I suppose organizational maturity is the deciding factor on which way to go. I completely agree with you that what you want to avoid is UX being seen as a cost center. That’s an unpleasant place to be. We want to (accurately) be seen as a revenue generator and/or cost reducer. In fact, a few years ago I did a presentation about UX ROI where I made both those points – I used “non-defect” (i.e. usability) in-field problem reports to show how much money we spent on usability problems and I used market intelligence data to show that improving UX market drivers would increase revenue by specific amounts. It was very effective… for that particular team. But (like many people) I’ve also worked with teams that think that future service costs are either a) someone else’s problem, or b) something we can worry about after we get the code out the door. Future cost savings arguments went over like a lead balloon with those folks.

Thanks for the interesting article and discussion. Now if I can just figure out a way to remove those strikethroughs from my previous comment….. hmmmm, is that a functional defect or a usability problem? =)

Amy Hillman — Fri, 22 Jun 2007 17:36:22 GMT

Here’s a shorter, hopefully fully active, link to the Bias/Mayhew book: http://tinyurl.com/36836g

Amy Hillman — Wed, 27 Jun 2007 07:24:45 GMT

Terry,

Thanks for your thoughts on this article—it’s great to get some additional perspective from another UX practitioner who’s spent time in the trenches. :)

I can’t say I agree with the argument that presenting time/$$ savings would “do more harm than good” when advocating a UX process. In my experience it’s always been one of the biggest selling points. But you do have to present those claims carefully. A critical component, as I mention later in the article, is managing expectations. Being honest with yourself about the level of acceptance for UX methodologies at your company, and on the team, is important. Take small steps first, on less risky/visible projects if necessary. Clearly communicate throughout the entire process (especially when you’re in the very early stages of introducing these new concepts). And then connect the dots for everyone so that they really see and understand the time/$$ savings.

If you have past experience proving the ROI of UX activities it’s a great way to show exactly how your process has worked before. If you don’t have a case study in your back pocket, find one—there are many examples of how a UX process has saved other companies time and money, online and in many of the great UX books out there.

One to check out is Cost Justifying Usability, by Bias & Mayhew: http://tinyurl.com/36836g

In the end, I think much of it comes down to communication. (As with much of life, I’ve found!)

It’s funny, but often I find myself observing and analyzing the user experience of my own team and company—and applying a similar approach to my teaching/advocating as I use in my research and design of a new product. I talk with my coworkers to find out what the current process is, how they feel about it, what’s working and what isn’t (contextual research, requirements gathering); I test the waters and explore different ways of applying these methodologies (conceptual “design”, user validation); and I document how the process worked before and what the effects are after adopting a UX process (baseline evaluation, comparative results reporting). Sometimes, it almost feels like a process within a process. :)

One great point you make is that UX activities serve as an excellent PR opportunity! In hindsight, I might have added that as another argument to be made in favor of a UX process. Talking with customers serves multiple beneficial purposes. You gain an understanding of your end users and ultimately build a better product, but you also get to start making a positive impression on them before you’ve even built that product. People really take notice when a company cares enough about their experience to ask them what they think. It’s win-win for everyone. Excellent comment, thanks for adding it to the conversation.

Terry Bleizeffer — Fri, 22 Jun 2007 15:55:15 GMT

Very good article, though I disagree with one part of it (more on that in a moment). Very good point about tying to business drivers, and the deep vs wide distinction is critical—at the end of the release, you need to have visible wins, and going wide hurts your chances of that. The point I disagree with is this, “Your team will save valuable time and resources by getting it right, or mostly right, the first time. And they’ll be faster doing it.” I don’t really disagree that this is true, but I disagree that it’s a useful argument. Most companies are worried about THIS quarter, not next year. And the time saving payoff for doing good design isn’t immediate—good design takes more time and effort than bad design. I think telling stakeholders that this will save a lot of time… in two years… can do more harm than good. The other thing that I think is important to emphasis during the evangelism phase is that by including customers in the design process you help to build buy in for the product even before you ship it, which can include customer references that you can market as early as the day you release. This can make a big difference, and it’s something that The Powers That Be can easily get their heads around.

Jim Brennsteiner — Wed, 20 Jun 2007 13:36:45 GMT

Amy, great article. I too have walked this lonely road (with some success0, but it continues to be an uphill climb. Good to know that I am not alone. Thanks.

Dmitry Nekrasovski — Thu, 21 Jun 2007 19:35:14 GMT

This is one of the best articles I have read on B&A in a while. I have recently found myself in a “pioneering” role, and truly appreciate these succinct and actionable pointers from an author who obviously has deep first hand experience with the subject matter. Thanks Amy!

j t — Tue, 19 Jun 2007 19:59:06 GMT

This is an amazing article. Serendipitously I have found myself in a position where I can directly apply many of the lessons of this article. I work for a large company with many large and small projects. We have recently discussed improving our usability process and I have been tasked with the implementation. I will be keeping your article in mind as I do so.

Perfect timing!

Teresa Torres — Thu, 21 Jun 2007 19:35:01 GMT

Amy, great article. I agree with all of it. I personally have the hardest time with “Go Deep, Not Wide”. I’m a perfectionist by nature and it’s hard to say no to something when it clearly needs design help. But I’ve learned the hard way (over and over again, in fact) that less is more. I’d rather work on fewer projects and really dedicate myself to them then try to touch everything and not be satisfied with any of it. It just takes discipline and lots of it.