The internal consultancy model for strategic UXD relevance

Jim Nieters, Manager of Cisco's "central" User eXperience Design (UXD) Group, Subbarao Ivaturi, Technical Lead in that group, and Garett Dworman, a Senior Design Architect for Tec-Ed consulting to Cisco, will be presenting an "experience report" entitled, "The Internal Consultancy Model for Strategic UXD Relevance" at CHI 2007.

I interviewed the three of them about the topic of the report last month.

Richard: Why did you choose to write this report for the CHI conference?

Jim: We had seen a lot of discussions about different organizational models at CHI. What we hadn't seen was anybody talking about the internal consultancy model. For example, there was a tutorial done at CHI that talked about different organizational structures. They talked about forming a team around a centralized funding model -- a cost-center model. They talked about structuring a team around a client-funding model where you get money from business units to pay for your team. And they talked about a distributed model where teams sit in the business units. But they didn't talk about an internal consultancy model. And we've found at Cisco that this model has been very effective. So, we decided that it would be worth sharing information about it with the larger community.

Subbarao: We also wanted to educate the CHI community about what experiences we were having at Cisco in using different models -- what successes we've had, what issues we face, and how we are addressing those.

Richard: Describe the internal consultancy model.

Subbarao: We function as a consulting firm within Cisco. We provide services to product teams that request them, but when we work on projects, we go in as a team rather than an individual, emulating portions of what design firms often do.

Jim: A design firm would come into the company, they would bid on a project, and they would assemble a cross-functional team of visual designers, interaction designers, maybe developers, user researchers, usability engineers, ... and they would deliver great value. In our case, we saw that when we had one designer focused on many projects, it was difficult for that person to dig deep, and it really diluted their value. Because Cisco is a technology-led company without full understanding of user experience, we could not afford to continue to dilute our value by delivering incremental improvements. So, we decided to focus on only a few projects very intensively and provide great impact. So, for example, Subbarao has led many teams within the organization that have delivered tremendous value, and he has been allowed to own the user interface, which is a part of our price of entry. Those are projects where we've made millions of dollars for the company. In the previous model, we may have made only incremental improvements which were difficult to measure.

Richard: The title of your report includes the word "strategic" -- it states that this model is for "strategic" UXD relevance. Is that what you are beginning to talk about? Is that why you say the model is important strategically?

Jim: That is exactly it. The typical structure is where one person works on many design projects, and you can afford that in companies where the UXD function is embedded and is a standard part of the process, because teams expect that. Cisco has been a technology-led company rather than experience-led, and we found that we can only make incremental improvement (using that model), and when you only make incremental improvement, the product team can then say a year later, "Well, gosh, it is not a great product; UXD only did a good job, not a great job." We decided that to make sure we had a presence at the table with executives making strategic decisions and to gain the visibility necessary to grow the function within the company, we needed to create a big name for ourselves. And that big name is achieved by working on projects where we can deliver, for example, $100 million dollars worth of impact. At Cisco, we have a huge scale, so $100 million worth of impact is possible, because we go after the projects where there is a lot of revenue opportunity. What that has done has given us a voice at the table from a strategic standpoint.

Garett: I'll interject from an outsider's perspective that at Cisco, there is a need for the UXD team to prove themselves. Many of us have experienced usability as being difficult to bring into design process, since lots of people don't quite understand what user experience means. But some companies are more receptive to that than others. Over the past 3 or 4 years, Cisco has been readily accepting the terminology, and happy to say, "yes, we want user experience." But when it comes to doing it, a lot of the personnel I meet don't really know what it is and don't always understand why it is valuable. They've been told they've got to do it, but they think it gets in their way. They have timelines which are often agressive; they have a lot of other teams they need to get work done with. Why should they bother talkiing with user experience professionals who appear to be slowing down the process by wanting to talk with users, when the product team already knows what users want (or so they think)? So there has to be palpable evidence that this is really worth doing. I think this has forced Jim's hand. Incremental changes are good and important, but people don't notice them.

Richard: It sounds as if there might be times when the UXD group turns down requests for services?

Jim: Many times, in fact. We've changed the dialogue so that we don't have to sell our services. Because of the impact we've been having, we are able to turn people away and choose the projects that are the most valuable -- projects where the people really want to work with us and will partner with us, where there is a big business opportunity so we can show a big financial return, and where executives will be willing to give us some of the credit so that we can articulate that they made a big return on investment in UXD.

Richard: Is there a danger in saying "no" to some requests. Might that not hurt you strategically?

Subbarao: There could be that danger, but with the previous model, we were accepting all requests, and we couldn't achieve the kind of excellence we wanted to on each project because we were spread too thin.

Richard: The internal consultancy model is actually only a part of the overall Cisco model with respect to user experience. Talk a bit about where UXD is positioned elsewhere in the company.

Subbarao: At Cisco, we have three main user experience groups -- one for the Cisco intranet, one for the external-facing cisco.com, and our central UXD consultancy that works on revenue-generating products that ship to customers. There also are smaller user experience groups within business units that are starting to build their own programs.

Jim: Our goal really is to help those product organizations understand the need to build a user experience competency. So we augment those smaller teams. When an organization's UX team can't handle all of their projects, they call on us on a project basis.

Richard: Where is your consultancy positioned within Cisco?

Jim: We're in the Customer Advocacy organization -- an organization outside of Engineering. We've been positioned within Engineering in the past. We've also followed the centralized model and the distributed model -- we've had teams in the business units as dedicated teams. At this point, Customer Advocacy is the voice of the customer to a great extent within the company. So, from our perspective, it made the most sense to locate there. Maybe in the future that should change.

Richard: Say some more about the history that ultimately led you to implement this internal consultancy model.

Jim: When Subbarao joined the company around six years ago, we had a client funding model where business units provided us with some of their headcount. Cisco was growing so fast as a company, that we actually had promises from executives that we were going to be able to hire 60 people in our central organization. It was as if everybody was throwing requisitions at us. Then we had the downturn in 2001. At that point, executives said they had to pull back their funding for UXD headcount. During that transition, we were successful at converting those people to be centrally funded resources. But the challenge with that was that we grew to almost 60 people, and when you grow to almost 60 people, you become a cost center. And when you are a cost center, people target you; even if you are delivering value, it can become a political challenge no matter what company you are in. Hence, we decided that being a cost center wasn't going to be successful. So, we moved out of Engineering and into the Customer Advocacy organization, and decided that we were going to have a smaller group that we would expand and shrink as needed via access to a pool of outside consultants. When a project requires resources beyond what we have in the UXD group, the business unit pays for those resources.

An example of how we do that is the case of a product that Garett, an employee of an outside consulting firm, is working on now with some members of our UXD group. The product team is paying us about $200,000, but we're supplying money as well. Hence, it is a shared model, with the goal of partnering very strongly with the business unit. Neither organization is paying the whole cost. The business unit is trying to start earning $20 million per year more than they are today, and they feel that our help, costing them $200,000, will help them do that. From their perspective, the return on that investment is pretty significant. So, you can see that the business units are providing us with the dollars that enable us to expand our staff as we need to by hiring consultants.

Richard: How well has that worked for you, Garett?

Garett: It has worked very well. In some ways, it has made it much easier for Tec-Ed, my employer, to move from one project within Cisco to the next. We don't have to go through a complete sales cycle each time. Now, when I am working on a project that is coming to a close, we can approach Jim to discuss projects that are coming up for the UXD group that I might move right on to.

There is a slight issue with identity, in that the UXD group wants to expand their ability by hiring outside consultants, but they still want to be seen by the rest of Cisco as just the UXD group. They don't want to be seen as the UXD group and other consultancies. We've been working that out, as Tec-Ed does want it to be known that it is involved in the work.

Jim: The issue of branding -- Cisco-branded, partner-branded, or co-branded -- is something that has to evolve more, because leveraging partnership has to be sustainable for everybody. That is one area of challenge that we have to solve going forward.

Garett: But it hasn't been that much of an issue. And it has been easier for us to consult to Cisco, because I can look to the rest of the UXD group as partners. So, for example, if we needed a report creation module on the project I'm working on now here, I can find out whether someone in the UXD group has worked on such a module on another project, and then leverage that work, which is truly helpful. Before, when I was working on a project for Cisco that lasted a year and a half, I was very removed from the UXD group and was working from a more isolated position; that made it easy for me to clearly say I'm from Tec-Ed, but I couldn't use all the resources of the UXD group.

Subbarao: Another challenge is that the consultants have to be able to quickly learn both the technology and the UXD practices at Cisco. We've tried to address that challenge by developing a pool of consultants that we use a lot, so most of the consultants we bring in already know a lot about the technology and our processes.

Richard: Talk a bit more about the culture of Cisco, and about any other characteristics of Cisco, which make the internal consultancy model advisable here.

Subbarao: The key thing, as Jim and Garett said earlier, is the need to show significant impact to product teams and other decision makers.

Jim: That is right. In the HCI industry, we talk a lot about return on investment and whether you can measure it. As part of the engagement model for the consultancy, we measure the "before" and the "after," and we make sure we will get testimonials from the executives to support our ROI claims. Over the years, the team has had over $2 billion of impact, which is tangible, and we can get testimonials from executives saying that that has been the case. This has made it possible for us to say, "Look at the value; it is a clear return on your investment." With prior organizational models, it was more difficult for us.

Also important is the partnership we establish with the product teams up front. It is a matter of ensuring that we are integrated with the teams and considered relevant by the teams' executives at the very beginning. We get those agreements up front, and that makes a big difference.

Subbarao: And coming out of all this is better user experience. We show tangible value not just in terms of dollars but also in how the user experience has evolved.

Richard: In what (other) types of companies should this kind of model be considered?

Jim: Companies where you don't have company-wide, executive level buy-in but where at least some product teams know they need an improved user experience and are willing to work with your UXD team and allow the team some ownership over the user experience.

Complex systems companies. You can contrast that type of a company with volume operations companies like Yahoo! and Intuit, where user experience is a requirement from the beginning. Cisco is technology-led and was successful as a technology company. We're trying to show -- and I think we are doing that -- that user experience itself can be that next advanced technology, that it is that next thing that can get you a billion dollars.

Garett: Of relevance to that point is the Cisco product I'm working on now. We've learned from customers that they think that the product does what Cisco says it does, and they are happy with that. However, they have had to go to extra machinations to find out whether it was doing what Cisco says it does, because the user interface is not very good. And what Cisco is finding is that competitors are making tremendous headway against Cisco in this product field. There is no evidence that competitors' products work better, but there is evidence that these other products have a user interface that provides users with the information they want about what is going on. With the Cisco product, users are not sure what is going on. It has become pretty clear that Cisco's product would really take off if it had as good or better of a user interface.

Richard: Will the internal consultancy model be best for Cisco long-term?

Subbarao: I think all models have to evolve, but I think we have shown tangible results for this model. When we see significant change in the Cisco landscape around others' expectations or behavior, or regarding how well we can scale our own efforts by staffing more people in-house, at that point we should look at how we should change the model.

Jim: I agree. For example, if Cisco were to hire a Director of User Experience for every major technology group that we have in the Engineering organization, we may be able to become largely a central infrastructure team providing tools, processes, labs, education, career progression, etc. Presently, we don't have the governance across the company that supports user experience actively enough. We only have local governance -- that is, governance at the product team level. Garret is right that the executives are saying the right things about user experience, but until we see it more globally accepted across the company, I think this model works. Once user experience gets accepted across the company, it makes sense to consider a different model.

Garett: I agree. There are two factors. One is resources. The UXD group doesn't have enough resources to cover all of Cisco's needs for UXD, even if it keeps hiring out to firms like Tec-Ed. The second is moving beyond jumping on the bandwagon and using the cool terms that are alive today. Once people understand what those terms really mean and imply -- once user experience has a good hold in the culture, and once there are enough resources, then the UXD group can move on to the next model.

Richard: Thank you.

Steven Pemberton

I was delighted when I received email from Steven Permberton a couple of weeks ago saying that he'd be visiting the San Francisco Bay Area and asking whether I'd be available to get together.

I was fortunate to have worked with Steven when we were both on the SIGCHI Executive Committee several years ago. Steven was Editor-In-Chief of SIGCHI Bulletin for several years when SIGCHI Bulletin was actually a substantive publication; he was subsequently Editor-In-Chief of interactions magazine (1998-2004). Steven also helped found SIGCHI.NL, SIGCHI's chapter in the Netherlands; hence, Steven also participated in workshops I gave when I was SIGCHI's Local Chapters Chair.

Steven was visiting the area for a meeting of one of the two W3C Working Groups he chairs. This work and some of his other "Projects Past and Present" are described on his home page, where he states:

"If there is one thread that runs through these projects, it is about people. In particular, what are the changes that need to be made to the system architecture to make the resulting system more human oriented."

Steven shared the following elaboration with me:

"One of the main problems with current systems is that they are not built to support usability. Designers are forced to add usability as a layer over the underlying system. And then time and again, for each program anew. Imagine if systems didn't support filestores but only the ability to write bytes to the disk. Then for each program you would have to write the code to deal with files, and you can be sure that each program would have its own filestore bugs, programs wouldn't be interoperable at the filestore level, and there would be acres of guidelines on designing filestores. Well, that's what we have with usability today but on a far grander scale. System architecture is designed by technicians who don't realise the far-reaching effects their design decisions are having. And as a result, usability is a band-aid over the top of bad system architecture."

I asked Steven about the challenges he encounters in his work for W3C in addressing this problem:

"W3C is, of course, essentially technological, though there are areas that are people-oriented, in particular accessibility and internationalisation. I think the problem is two-fold: firstly, W3C is balkanised along the major design axes. There are people thinking about accessibility, device independence, internationalization, and so on, but they are not in general embedded in the groups doing the actual designs, so that often the non-design groups end up writing guidelines - band-aids. Secondly, W3C is member-driven. This is a good thing in general, but it creates a vicious circle: if W3C doesn't do usability, no one from usability will join, and if no one from usability joins, there is no one to demand that it be done. As a result, there is no group responsible for usability within W3C and therefore not enough attention is paid to it."

Steven travels a lot giving keynotes and other invited talks about his perspectives and his work for W3C. Slides from many of his presentations are accessible via his home page, along with audio of various interviews (most in Dutch).

Are you familiar with the concept and experience of a Dutch auction? Over a drink, Steven told me about his first-hand experience. Wikipedia includes a description, but that description fails to mention the second stage that is included for auctions of residences, a process via which Steven and his partner Astrid purchased the residence next to theirs enabling them to expand their residence to accomodate their growing family (those are their two sons riding on the front of Steven's bicycle).

Perhaps Steven and Astrid should expand their award-winning guide to Amsterdam to address Dutch auctions in full. Be sure to access that guide should you be planning a trip to their wonderful city.

---
Top photo of Steven by Barbara Mensink.

Calculating return on investment

Much has been reported about the importance of analyzing return on investment (ROI) for user experience to gain influence in a corporate context.

For example, Tobias Herrmann, Head of Team User Experience at mobilkom austria, wrote in "Corporate UX -- Bringing value to the mobile industry" that "a tailored ROI model was the key to success":

"Our ROI model contained, among other things, the monitoring of user experience-specific key performance indicators (KPI), internal performance measurements, standardized product evaluations from a customer's perspective, and, of course, exemplary case studies with high customer and revenue impacts. Further, we included some major user experience KPIs in the Corporate Balanced Scorecard, and even in variable bonus systems for employees. As you might imagine, all these activities strongly supported organizational sustainability, but even more built up a common mindset on user experience and its relevance."

And my conversations with Justin Miller, now Senior Director of Product in Europe at eBay, confirm that estimating ROI has played a major role in moving user experience into a position of influence at eBay. Indeed, at CHI 2004, Jeff Herman described "A process for creating the business case for user experience projects" that enabled eBay's User Experience & Design group to achieve "significant success sponsoring successful user experience projects."

Yet, when he was VP of User Experience at Oracle, Dan Rosenberg wrote:

"…in my 20 plus years of experience, I have never been asked to produce an ROI analysis. Why has this never been necessary? Have I just been lucky in my choice of employers? Did these companies all have CEOs so enlightened about usability that no such analysis was necessary? I suspect not."

And just last month, David Siegel argued the following:

"Our field has been overly preoccupied with ROI as the basis for making the business case for user centered design (UCD). However, experience has shown that the most brilliant ROI analysis may often not win the day in the real world of business. Cost justification and ROI is often not persuasive, especially when we are talking to strategic level decision makers. At a certain point in the evolution of UCD, ROI arguments may have helped us gain credibility and get 'a foot in the door.' However, excessive dependence on ROI arguments can have some destructive effects. To be convincing, ROI analysis has to focus on easily measured variables that impact near-term outcomes. This can distort the way the value of our contribution is conceptualized and recognized, and artificially isolates UCD from other factors that affect the product’s ultimate success. Even more important, it can lock us into a peripheral tactical role where we address only modest incremental improvements. It can work against our field’s efforts to get involved earlier in the product planning process where we can have a more decisive impact and potentially contribute to strategic risk reduction."

Should you attend to calculating ROI where you work? Cannot such calculations contribute to strategic business planning?

This issue is among several that will be addressed by a group of people in senior management roles from a mix of companies during a session I'll be leading at CHI 2007 -- a session entitled, "Moving User Experience into a Position of Corporate Influence: Whose Advice Really Works?". Tobias Herrman (represented by Manfred Tscheligi) and Justin Miller -- both referenced above -- and Jeremy Ashley, Oracle's current VP of User Experience, will be among the session participants.

As I reported in earlier postings, "ownership of user-customer experience," "organizational positioning," and "documenting and evangelizing user experience work" are among other issues that will also be addressed during that session. And I'll address all these issues further as well as the CHI conference session itself in upcoming blog entries.

"Check your disciplines at the door" when beneficial

A version of this posting was published in UX Magazine.

During a user experience leadership seminar that I gave last summer, I asked about the extent to which the company's user experience personnel collaborated with each other as well as with others. I had just argued that such collaboration is important and can have a huge impact on the success of a multidisciplinary user experience group or organization.

For the only time during the seminar, the group of user experience practitioners responded with near silence.

I was surprised by this, since discussions about collaboration are often quite animated and can yield lengthy lists of frustrating obstacles encountered in the workplace. However, in this particular workplace, collaboration was seemingly not viewed as an important goal.

To some, collaboration means that nasty "designing by committee" or being forced to defend one's expertise.

To others, a process which facilitates contributions across discipline boundaries is often beneficial.

Consider what Dave Malouf wrote about his new work environment this past December:

"While most design projects seem to have a single designer at the helm, there are projects where different players (industrial designer, researcher, ux designer [read interaction designer]) are all engaged on a single project (Industrial Designer is usually the lead), no one really cares where ideas come from. 'Credit' seems to be shared across the team, thus encouraging more ideas to be generated because people have less fear about grasping ownership and care more about creating great things."

In a recent interview by Lisa Reichelt, Bill Moggridge calls this "checking your disciplines at the door," which he recommends for teams which also -- and which often should -- include personnel from additional disciplines, such as engineering and marketing.

Don Norman concurs, as quoted in "Ownership of the user-customer experience":

"Out of necessity, we divide ourselves up into discipline groups. But the goal when you are actually doing the work is to somehow forget what discipline group you are in and come together."

More from Bill:

"where the complexity is high enough, you're much better with a shared mind, and if you put people together from different disciplines, if they work successfully together rather than having some form of a conflct, then the result with the shared mind will be much greater than any individual mind could be"

Bill advocates "complete submersion in togetherness (particularly) in the main design creative innovation phase," which is reflected pretty well in the diagram to the right which comes from a paper I and two former colleagues wrote about some of the work we did at Viant. Among the many activities in which multiple personnel of the design, strategy, and technology disciplines were submersed in that work: rapid ethnographic research and its interpretation, and subsequent business and design brainstorming.

Yet, guidance and structure for the activities in which everyone was submersed were provided by those with the greatest expertise in the activities and in facilitating them. This was true as well for the "intensive, rapid, cross-disciplinary collaboration" I referenced a couple of years ago in this blog and which resulted in user experience personnel becoming partners in the development of business and product strategy in a particular business unit within Yahoo!.

And, as reflected in the center of the diagram, at other points in the process, the disciplines "spread out," as Bill puts it -- "people bring their individual expertise to the picture" when appropriate [e.g., when you've identified "an interaction design problem, the best person to (address) that would be someone who has a lot of experience with user conceptual models and screen design"].

However, as also stated by Bill:

"it is easy to sit around the table and argue the different case from the different discipline point of view; the big challenge is to work across disciplines fluently"

That might be the most important thing teams need to learn how to do.

Lifetime Award

When Peter O'Toole was informed that the Academy of Motion Picture Arts and Sciences was to present him with an honorary lifetime award in 2003, "he originally intended to turn it down feeling that the lifetime award signaled the end of his career. He wrote the Academy a letter stating that he was 'still in the game'."

Peter's recent, wonderful Oscar-nominated performance in Venus and his upcoming appearances in several other movies shows how right he was.

At CHI 2007 this spring, SIGCHI will be giving me its Lifetime Service Award, even though I, too, am "still in the game." Peter O'Toole was decades older when he wrote that letter than I am now, but I greatly appreciate the award and am happy to have been able to contribute to the field worldwide via SIGCHI.

Here is what SIGCHI has published about me in its award announcement:

"Richard I. Anderson is a user experience practice, management, and organizational development consultant with more than 20 years of experience. He was on the founding committee and served as program chair (1990-2002) and chair (first elected chair) of BayCHI, the largest chapter of SIGCHI, but has also traveled around the world growing and facilitating SIGCHI chapters internationally. Richard was the SIGCHI Local Chapters Chair for 5 years, from 1996-2001. He authored numerous SIGCHI Bulletin articles, wherein he offered case studies, advice and support for local SIG leadership. He organized and led popular annual workshops for chapter leaders at the CHI conference. Richard also served as a member of 4 CHI conference committees (including the upcoming CHI '08) and served as the CHI 2005 Development Consortium Chair, in addition to serving on the committee for 3 DUX conferences. Finally, Richard has authored multiple articles for interactions magazine. Through his leadership, he has facilitated and spread the word about human-computer interaction literally around the world."

I've written about some of the above-referenced work in various places. For example, in "Offshoring user experience work," I wrote:

"As SIGCHI's Local Chapters Chair for 5 years, I somewhat unknowingly helped make offshoring of user experience work a fact of life, working with people around the world to help them set up and successfully lead and manage regional and national HCI communities. Countries in which I helped establish and grow SIGCHI chapters included India, Russia, Romania, Brazil, Korea, South Africa, Poland, Mexico, Czech Republic, Israel, Chile, New Zealand, and Bulgaria, many of which are identified in a January 2006 issue of BusinessWeek as countries competing for offshore outsourcing by U.S. and Western European companies."

In "1996-2001 CHI Local SIGs Column Sampler," I review the many articles I wrote and edited about forming, leading, and promoting professional organizations around the world. Many of them are still relevant and of value to (potential) chapter leaders of any professional association, not just SIGCHI, and to some extent even to (potential) leaders of user experience organizations in for-profit companies, though that was not my intent.

A list of the dozens of BayCHI programs I put together is still accessible on my website, though it and additional information about each program can now be found on BayCHI's website.

I still get called "Mr. BayCHI" every so often, even though I ended my 12-year stint as BayCHI Program Chair and emcee a few years ago. And, delightfully, I still communicate with and run into people from around the world that I worked with as SIGCHI's Local Chapters Chair.

I miss all that work sometimes. I still lend SIGCHI a bit of a hand, but my professional association attention has shifted more towards the cross-disciplinary focus of UXnet, for which I am a member of the Board of Directors. (UXnet is still in its early stages of development, but it recently launched an Organizations network to facilitate communication and collaboration among major non-profit, user experience related organizations; SIGCHI is among the network's initial members. Additionally, BayCHI has helped sponsor the UXnet ambassadors in the San Francisco Bay Area.)

I most miss my work for SIGCHI in and for other countries. I have done other work in other countries, but I am interested in working and having an impact on work in other countries much more. So, if you are, for example, looking for someone to oversee and coordinate development of your international user experience research and design practice and organization...

---
No, of course I'm not comparing myself to Peter O'Toole, and, unfortunately, I never did make it to the Arabian desert, as he did as T.E. Lawrence.

The quote about Peter O'Toole comes from the Internet Movie Database.

Special thanks to Marilyn Tremaine.

Documenting and evangelizing user experience work

Many have argued that explaining and advocating for user experience work is a critical part of every user experience professional's job.

And many have provided guidance for doing so better. Examples include:

• Evangelizing User Experience Design on Ten Dollars a Day, a 2002 list of (and discussion about) "effective, low-cost techniques"
• How Can Rhetoric & Argumentation Help Us Make the Case for UCD?, a CHI 2006 Special Interest Group session and CHI-Atlanta May 2006 presentation
• Promoting Usability Within Your Organization, a May 2006 NYC UPA presentation

Our Managing User Experience Groups course also addresses this topic, providing guidance from a number of sources.

Yet, others have argued that user experience professionals excessively discuss the nature of their work -- that others don't really care nor should care or will just become concerned, and that process documents end up not getting followed anyway. As Bloomer and Wolfe state in Building and Managing a Successful User Experience Team:

"Teams need to avoid the role of evangelist for user-centered design."

Is it truly never advisable to document and evangelize user experience work?

This issue is among several that will be addressed by a group of people in senior management roles from a mix of companies during a session I'll be leading at CHI 2007 -- a session entitled, "Moving User Experience into a Position of Corporate Influence: Whose Advice Really Works?". Participants will describe the roles, large and small, that documenting and evangelizing user experience work have played in their workplaces, and will discuss the extent to which such efforts were important to achieving corporate influence.

As I reported in earlier postings, "ownership of user-customer experience" and "organizational positioning" are among the other issues that will also be addressed during that session. And I'll address all these issues further as well as the CHI conference session itself in upcoming blog entries.

DUX 2007

DUX (Designing for User eXperiences) 2007 :: Chicago
November 5 - 7, 2007

Theme: Social media and networks are producing a new set of expectations regarding people's ability to contribute, create, personalize, and share information.

These new expectations are changing the roles, methods and responsibilities of Designers and Researchers. The effects are being realized through:

• Ease of access to new types of information
• Explosion and redefining of online communities
• Emergence of new tools and capabilities
• Significant shifts to the worlds of product development, advertising, marketing, and customer service

DUX2007 will surface issues and strive to define the role of designers in this time of shifting spaces.
Location: Intercontinental Hotel (on Magnificent Mile)
505 North Michigan Ave.
Chicago, IL 60611 USA

The conference website should be launching later this week.

Conference Chairs (chairs at dux2007.org):
Parrish Hanna, SIGCHI
Joseph O'Sullivan, AIGA
John Finnegan, SIGGRAPH

Mobile persuasion in short, high-speed bursts

The design of the "conference experience" is an interest of mine, as one who has played various roles in designing different portions of conference experiences and, of course, as one who prefers to have a good experience at conferences I attend.

I was particularly interested in the design of the experience of the one-day, single-track Mobile Persuasion conference held at Stanford University last Friday.

The conference content was itself of great interest. The diverse collection of topics addressed included augmenting reality with mobile technology, using cell phones as performance coaches, using cell phones to facilitate social change, mobile advertising, mobile dating, using mobile technology for health and wellness, and the relationships people have with their mobile phones. Of particular interest to me, as one who has engaged in, managed, and advocated "ethnographic" research in business (see, for example, "Designing for emerging, non-western markets"), was the session on the different roles mobile phones play in different cultures.

Thirty-one speakers, not counting session moderators, were spread across 8 sessions, limiting each presentation to just a few minutes. "I thought the communicated limit of 9 minutes for my presentation was just a typo," proclaimed one speaker in the men's room. Some speakers were permitted even less time. And in the final "lessons learned" wrap-up session, each of the 4 speakers who were asked to share their interpretations of what they heard and saw during the previous 7 sessions were permitted to speak no more than 30 seconds at a time (each could speak several times, but for no longer than 30 seconds each time). And everyone was carefully timed.

Such limits can prompt experiences and expressions of frustration from speakers and attendees alike, unless each session and each piece thereof is appropriately designed. As suggested earlier, not quite all of the speakers were fully prepared to be constrained by such time limits; as Jeremy Lind blogged, some presenters were "skipping and flipping their slides (note to self: always prepare your slides for the right time limit)." And most presentations appeared to be independently prepared, without much knowledge of or reference to the contributions of other participants in the same session.

Yet, most speakers were ready for and, thankfully, didn't fight the time limit. And, in my view, the final session of the day in which the participants could speak in only 30-second bursts was greatly enhanced by that constraint, making the session more conversational -- more interactive, prompting more contrasts and comparisons of perspectives and resulting in comments that leveraged and built off of the comments of others.

I applaud the jam-packed sessions and the associated time constraints imposed by Conference Chair BJ Fogg, who had previously participated as a presenter in a conference program with similarly jam-packed sessions and for which I was a Program Chair -- DUX 2003.

Since so much mobile persuasion itself occurs in short, high-speed bursts, ...

---
Note that the above posting is not a comprehensive review of the conference experience. Among conference features not mentioned were the many small, tall tables intended to attract attendees during breaks for discussions about the different mobile persuasion topics displayed on signs above the tables. And there were the fun giveaways that could be received only if an attendee returned from a break on time (that BJ is a stickler for time, no?). And...

Does it matter where User Experience is positioned in your corporate structure?

Last May, I posted a lengthy blog entry entitled, "Where should 'User Experience' be positioned in your company?" that received a great deal of attention. In it, I referenced several factors to consider when determining organizational positioning. Among them:

• what "user experience" means in the company
• the nature of and effect on working relationships
• organizational goals
• who has the power
• the corporate culture

I also referenced how organizational positioning is considered to be very important to a lot of people, including a lot of User Experience Managers, Directors, and VPs, and including everyone who had taken our Managing User Experience Groups course (many of whom were in user experience management positions). Indeed, figuring out where User Experience should be positioned is one of the many things students of the course work on, as reflected in the nearby photo.

And since last May, I've learned about additional situations in which organizational positioning appeared to be impactful. For example, Peter Merholz wrote about "the frozen middle" in August of 2006:

“The people we worked with were deep within ‘interactive marketing.’ Their lives were the website. They didn’t really know the people who worked on the monthly statements or at the call center. And even if they did, they didn’t have the time to collaborate with them -- they had too much on their plates already. …our contacts understood the need for addressing the customer’s experience across multiple channels and media. But they couldn’t move on it.”

However, in March of last year, Forrester Research published a report entitled, "Culture and Process Drive Better Customer Experiences" that challenged the importance of organizational positioning:

"Companies place a high priority on improving customer experience — and they cite a lack of organizational alignment as their top obstacle to making improvements. But our interviews with experts show that there is no single organizational structure that paves the way for delivering better customer experiences. Cultural factors and internal processes matter far more than organization."

While I agree that cultural factors and internal processes are very important, does the fact "that there is no single organizational structure that paves the way for delivering better customer experiences" mean that organizational structure has little impact? I don't think so.

Can't organizational positioning impact culture and internal process? Aren't culture and internal process among the factors to consider when determining organizational positioning?

Can culture and process trump any organizational positioning?

This issue is among several that will be addressed by a group of people in senior management roles from a mix of companies during a session I'll be leading at CHI 2007 -- a session entitled, "Moving User Experience into a Position of Corporate Influence: Whose Advice Really Works?"

As I reported last month, "ownership of the user-customer experience" is another of the issues that will be addressed during that session. And, of course, I'll address all those issues as well as the CHI conference session itself further in upcoming blog entries.

S.M.A.R.T. versus I.T.O.C.A. goals

Our course entitled (though apparently not just about) "Managing User Experience Groups," does address a few basic management topics, including setting individual and group goals.

During the first offering of the course early last year, we included a short section on SMART goals -- types of goals to which I believe I was first introduced when I was a Director at Studio Archetype. Indeed, one of my responsibilities at Studio Archetype was to help those who reported to me set goals that were Specific, Measurable, Actionable, Realistic, and Time-dimensioned (aka SMART).

However, when we addressed this topic during the course, we learned that most everyone was familiar with SMART goals. But perhaps more interestingly, many groaned as the topic was introduced. So, during the second offering of the course late last year, we didn't address such goals in class, though we provided students with a relevant, optional reading.

Some of those who groan on encountering the topic of SMART goals might be particularly interested in what Robert Middleton has to say about them:

"You've probably read a lot about goal setting. Perhaps you've heard of the famous "S.M.A.R.T." formula - Specific, Measurable, Achievable, Relevant and Time Specific. Well that's OK, but it's not really the best way to set goals.

To set and achieve goals you need to be unreasonable.

We tend to completely undermine ourselves by being reasonable. And unfortunately, the S.M.A.R.T. formula is totally reasonable. It keeps you inside a very rigid box of what's possible.

But why do you want to set goals that are possible? You want to set goals that are impossible. (At least from your current point of view.) You want to set goals that set you on fire.

Goals that take passion, sweat, blood and tears to achieve.

... I give you my not-so-famous I.T.O.C.A. Formula:

1. IMAGINE you're on your death bed looking back. And you say to your loved ones gathered around, "You know I've had a pretty good life, but I really wish I'd done X." What is X? That's your unreasonable goal.

2. THINK about it all the time. Don't push it out of your mind. Obsess about it; brainstorm and draw mind maps. Get the idea out of the abstract and into the concrete. Form a mastermind group and kick around ideas. Make it real.

3. Be aware of OPPORTUNITIES and coincidences that present themselves. You couldn't see them before, but now, with increased focus on your goal, you'll start seeing, reading, hearing about things that are connected to your goal. Explore these things. They're there to help you.

4. When the time is right, make a COMMITMENT. On the TV poker shows they talk about going "ALL IN." Don't hold back. Make a promise, not based on knowing how to achieve your goal, but on your desire to make it real. If you have to know how ahead of time, you'll never take the leap.

5. ACTION. Now it's time for the real work, and that consists of putting one foot in front of the other every single day. Keep things alive by creating action plans, researching, asking for assistance, and networking with like-minded people. In other words, create an environment in which the goal can be realized.

Imagine, Think, Opportunities, Commitment, Action: I.T.O.C.A.Now that's a pretty bad acronym compared to S.M.A.R.T., but I promise you it's a better formula for getting what you truly desire."

---
Robert's full article is entitled "Setting Unreasonable Goals" and is dated January 30, 2007.

Yes, the S.M.A.R.T. formula Robert references is slightly different than the one I referenced. And there are additional variations; see "SMART Goals" for a list of many of these.

Frank N. Stein

The delightful poster to the right was created to advertise a recent presentation of mine.

What might that green monster represent? The user experience created by your company? The user experience personnel in your company who complain that they want to play a bigger role in your company than you created for them to play? Other personnel in your company who won't let you, the user experience practitioner, play the role that you want to play in your company? ???

---
The painting actually, in theory, depicts me in a past life -- Frank N. Stein, the creation of Maddy the Mad Scientist, the wonderful 9-year-old artist in a past life. But I like the metaphorical interpretations, such as those referenced above.

(The "N" stands for Nigel.)

Ownership of the user-customer experience

Last month, I referenced a lament for "the many 'folks in the trenches' who are still fighting 'a constant battle, where they are forced to defend their position as user experience experts'." In the specific case that prompted the lament, the culprit was identified as Marketing. However, I've heard many similar complaints about Product Management, Engineering, assorted executives, and others from user experience practitioners in a wide variety of companies.

Frequently, these frustrated user experience folks proclaim that they are the ones who should own the user experience.

The editors of interactions magazine are among those who agree, as I quoted in "Walls":

"...product management doesn't build or design products: their job is to own product vision and strategy (naturally with the other stakeholders' input). Engineers own code development and code quality, with a wide range of specialties (architecture, code design, QA, and release management, to name a few). Product marketers take clear ownership of marketing communications and product campaigns, keeping the pulse of the marketplace, and trying to detect what it will buy. Therefore, it's only logical that human-computer interaction professionals take ownership of the user experience. We are, after all, user experience experts, despite the fact that we depend on other development participants to meet user and business needs."

Another who appears to agree is Cisco's Jim Nieters, who, in a paper to be presented at CHI 2007, describes the role his user experience design focus team must be permitted to play before it is willing to get involved in a project:

“The UXD Focus Team functions as the architect who provides the blueprint for the elements of the product that defines the user experience, and the developers function as the carpenters who deliver to the specifications. If the product team does not agree in advance to these roles, the UCD group does not accept the project.”

However, contrast those perspectives on ownership with the perspective of Jeremy Ashley, VP of Applications User Experience at Oracle:

"A culture of UI entitlement creates an atmosphere where the UI designer will not perform until he or she is given a driving role in the process. ... The valued participant often finds a way to compromise..."

And consider the broader view of Don Norman, which I referenced in my first blog entry ever ("In a business, which organization should own the user experience?") as well as again in "Where should 'User Experience' be positioned in your company?". The latter includes the following words from Don:

"Why should any particular organization own it? The company should own it. ... Who owns user experience at Apple? In part it is Steve Jobs, but in many ways it is the company. Yes, it was Steve Jobs who put in the focus and said 'do it this way, or go away.' But I think a successful company is one where everybody owns the same mission. Out of necessity, we divide ourselves up into discipline groups. But the goal when you are actually doing the work is to somehow forget what discipline group you are in and come together. So in that sense, nobody should own user experience; everybody should own it."

Don's perspective is extended somewhat by Forrester Research, which in a report published just this month states:

“Treat customer experience as a competence, not a function. Delivering great customer experiences isn’t something that a small group of people can do on their own -- everyone in the company needs to be fully engaged in the effort.”

However, consider the following related perspective that implicitly references an important role which perhaps should be owned by "user experience personnel":

"We want to make customer experience everyone's business by making the process of creating experience intuitive and repeatable."

The above words are from Secil Watson, Wells Fargo's SVP of Internet Channel Strategy, and the "we" she refers to is her Customer Experience Research and Design group. As I described earlier this month, her group goes about doing this at Wells Fargo by embedding ethnographic research insights in user-centered design tools for strategic business planning. And this is changing the Wells Fargo culture. As stated by Wells Fargo's Robin Beers and Pamela Whitney:

“The UCD tools enable designers, researchers, and business people to make meaning together and this meaning is co-constructed such that no one functional area holds all, or even most, of the knowledge on a project. The willingness to invite full participation in the research and then release the findings so they can evolve within the organization are key factors that continue to push the Wells Fargo culture to become increasingly customer-centric."

So, are the user experience practitioners who think they should own the user experience wrong? Or are there at least some aspects of the user experience that "user experience personnel" should own? Is ownership advisable in some situations but not in others? What exactly does "ownership" mean?

This important issue of the ownership of user-customer experience is among several issues that will be addressed by a group of senior management personnel from a mix of companies during a session I'll be leading at CHI 2007 -- a session entitled, "Moving User Experience into a Position of Corporate Influence: Whose Advice Really Works?" Secil Watson, Jeremy Ashley, and Jim Nieters -- all three of whom are quoted above -- will be among the session participants.

---
Papers quoted include:

• Arnowitz, J. & Dykstra-Erickson, E. It's mine... interactions, May+June 2005, 7-9.
• Beers, R. & Whitney, P. From ethnographic insight to user-centered design tools. EPIC'06 Proceedings, 139-149.
• Kowalski, L., Ashley, J., & Vaughan, M. When design is not the problem -- Better usability through non-design means. CHI'06 Extended Abstracts, 165-170.
• Nieters, J. E., Ivaturi, S., & Dworman, G. The internal consultancy model for strategic UXD relevance. CHI 2007.
• Tempkin, B., Manning, H., & Hult, P. Experience-Based Differentiation: How To Build Loyalty With Every Interaction, Forrester Research, January 2, 2007.

Developing user-centered tools for strategic business planning

User experience professionals continue to attempt to move their work and impact "upstream" -- to play an earlier and more strategic role in their workplaces' business. But exactly what does that mean? What is it that user experience practitioners or groups thereof should be doing differently or working towards doing (more)?

I've addressed aspects of this in previous blog entries, as have other bloggers. Among the others are Jess McMullin, whose design maturity continuum describes design activity as evolving in companies from the role of styling to making things work better, to problem solving, and ultimately to problem framing to shape strategy. Another is Luke Wroblewski, who recommends that designers use their design skills "for business visualization":

"The same communication skills that help designers create effective visual and interaction designs for products can also play a significant role elsewhere in the product development process especially during early strategic work. ...

... Especially early on in the product development process, design artifacts are able to create buy-in for a product vision, provide market context, or illuminate data, processes, goals, and the impact of decisions."

Some of what I did as Director of User Research at Studio Archetype during the late 90s was work with Jeff Bauhs and others to design and develop models of user behavior, thinking, and experience that reflected research findings. And we did this to provide user-centered tools to guide decision making about what clients should offer to consumers via the web.

We continued work of this nature following the absorption of Studio Archetype by Sapient, where it was extended further via the acquisition of E-Lab, a consultancy which had specialized in developing models of user experience from ethnographic research findings in order to help clients identify strategic business and design opportunities.

During 2001, Arnie Lund co-authored an article describing the experience modeling process at Sapient back then, work which he more recently -- November 2006 -- referred to as an example of the type of work practitioners must move towards to "take the user experience to a new and better place" and "deliver the impact we believe we should have."

Similar modeling is done in some form in various places. For example, see Jay Joichi's DUX 2005 case study entitled, "Improving Color Exploration and Visualization on the ColorSmart by BEHR application" in which he describes the creation and use of a behavioral model of the experience of conducting painting projects -- a model used repeatedly to help identify areas of unmet need.

One business that has gone and is going even further with such work is Wells Fargo, as partly described by Robin Beers and Pamela Whitney in a September 2006 EPIC conference paper entitled, "From Ethnographic Insight to User-centered Design Tools." At Wells Fargo, ethnographic and related research findings are summarized in experience models, mental models, and user task models, with the latter representing the details and complexities of everyday financial life. User profiles, also developed from research findings, are then connected to the task model via "scenario starter" worksheets that enable all sorts of Wells Fargo personnel, including business strategists, to walk through the experience of different users in different situations in order to develop an extensive understanding of where, when, how, and why the user experience breaks down.

The result:

"...a transition from a product- to a more customer-centric culture. This shift was becoming crucial as disconnects in customer experience increasingly arose not within the boundaries of the product and service platforms but in the transition and integration points between different areas..."

By extending the task model with metrics derived from surveys and other sources, Wells Fargo has developed an impressive user-centered strategic toolkit that guides project identification, project prioritization, business case definition, and much more.

I'll say more about the work at Wells Fargo in an upcoming blog entry.

---
Note that I'm not sure that Sapient does experience modeling anymore, since much has changed at Sapient in recent years.

Note also that you might still be able to download the EPIC 2006 Proceedings, in which you will find the Beers and Whitney paper referenced above. Rumor has it that this download capability will be short-lived, so...

2006

2006, the year of people; creativity; connection; consumer participation, interaction, and influence; 2.0; business+design; ... -- significant aspects of 2006 in regards to marketing, advertising, and user experience, according to David Armano's 2006 In Your Words.

As I've reflected on 2006, the above prompted me to ponder whether it described significant aspects of 2006 in regards to my "user experience."

So, let's see... My 2006 included:

- multiple visits to San Francisco's Ferry Plaza Farmers Market. Yum -- what a special place this farmers market is on Saturday mornings. Wonderful produce; wonderful setting (on San Francisco Bay); wonderful farmers and sales people, all of whom really know their stuff and many of whom we know on a first-name basis, including Louis of Iacopi Farm, John of Far West Fungi, David of the Star Route Farms booth, ... We sample their offerings, share in their business and personal updates, and enrich our food preparation knowledge as well as our lives. Always an eggceptional eggsperience!

- multiple visits with multiple kids. So many friends and relatives have the most wonderful children, and they are a delight to be with. There is Simi (a.k.a. Maddy, the mad scientist who created me, Frank N. Stein), Sierra, Fiona, Anisha, Tyler, Elana, Meliza, Mason, ... Yum again and again.

- an independent and foreign film discussion group. A high school teacher, two film professors, a psychotherapist, a resident of Portland Oregon, an artist, a middle school teacher, someone who has a vote in the British equivalent of the Oscars, a couple of high-tech folks, and several others comprise this wonderful group of people who are passionate about movies. At least once a month, the group meets in a group member's home to discuss at least two movies selected the previous month to be seen in theaters. Volver, Army of Shadows, Half Nelson, Little Children, Look Both Ways, The Science of Sleep, Water, and Cache were among the movies we discussed in 2006. Wanna listen in?

- unconferences. I attended two of these, leading a session in one of them -- DCamp, an unconference focused on design and user experience. Often no less flawed than the conferences they try to better, such events increase attendee participation in ways I hope to see integrated with conventional conference elements in future events. (The photo shows one view of a promising technology used during the Interactive City Summit to enable attendees to reveal their presence and their opinions via use of their cell phones.)

- co-developing and co-teaching a university extension course. It had been several years since I last taught a university extension course -- a successful, full-semester User-Centered Design / Usability Engineering course. The focus this time: the first ever substantive Managing User Experience Groups course -- a course spanning far more than "managing" user experience groups. We taught it twice during 2006 to people in various management and practitioner roles from a wide range of companies. And because of the course, I've been able to connect with many others in similar roles around the world, learning how much they would value access to such a course, and also learning -- and teaching -- how many have increasingly moved user experience into a position of significant influence in the businesses in which they work.

- a Holiday Cookie Baking, Decorating, and Eating Party. Of the many parties I attended during 2006, this was, I think, the most fun, as the many attendees got involved in a highly creative way. Now, I might be a bit biased, since this is a party that Claudia and I put on, but...

- blogging. I guess that one goes without saying, though I haven't quite caught my stride in this blogging game...

- Burning Man. Wow -- what an amazing and unique festival of art, creative expression, and community! Held on the playa of the Black Rock Desert in Nevada, Burning Man brings together an eclectic mix of people from around the world "to be part of an experimental community, which challenges its members to express themselves and rely on themselves to a degree that is not normally encountered in one's day-to-day life." Via theme camps (Fear No Martini was one of my favorites), art installations, and numerous activities, Burning Man enables participation like no other event. And as a nearby photo reveals, Burning Man 2006 even included the long tail!

So, were people; creativity; connection; consumer participation, interaction, and influence; 2.0; and business+design significant aspects of my 2006?

---
OK, the above review of my 2006 might not have been exactly comprehensive, but... ;-) "Should auld acquaintance be forgot..."

Also, yes, I excluded "video" from Armano's list, thinking it not all that applicable to my 2006. However, while writing this blog entry, I watched a Happy New Year animation, ABBA singing Happy New Year, and fireworks greeting 2007 in Taipei on YouTube. So...

Happy New Year.

"The three-legged stool of collaboration"

Effective multidisciplinary and/or cross-organizational collaboration remains a challenge for many. And it is an important challenge to meet. As nicely stated by the authors of the recently published "Innovation: The Five Disciplines for Creating What Customers Want" (see "The way we work has enormous power"):

"Collaboration is powerful. Only through collaboration can one gather the skills and knowledge needed to solve most important problems and make an impact. Most of us enjoy working on collaborative projects with supportive colleagues. We want to make a difference and have our contributions valued. These are strong human needs."

And since user experience is inherently multidisciplinary and often impacted by multiple organizations within or across companies and cultures (see, for example, "Co-design, China, and the commercialization of the mobile user interface")...

In past postings, I've addressed some of the elements that successful collaboration sessions have in common, including effective facilitation, walls, and fun.

The authors of the above-referenced "Innovation..." book describe what they consider to be the essential elements:

"Imagine a three-legged stool where written on the seat is 'collaboration' and on each leg is one of these three elements:

• shared strategic vision
• unique, complementary skills
• shared rewards

...if one leg is missing the stool will fall over and collaboration will stop."

Regarding the first of these three elements:

"First, you must be able to understand and agree with the vision, goals, and objectives of the project. ... A clear, compelling vision is a force for change -- it pulls us forward."

Clement Mok, when he was Chief Creative Officer at Sapient, put it this way when I interviewed him on stage at CHI '99:

"Collaboration, I think, requires engaging the individual or the group to take on a change. The minute that the metalevel of understanding within the group that the group is about to do this one thing is not there, collaboration is not going to work. When people are in disagreement, they don’t have vying at the metalevel that they are about to alter something fundamentally. You have to operate at a concept level so that people are engaged and ready to accept a change."

Regarding the second element (back to quoting the "Innovation..." book):

"Second, you must be able to see clearly how your contribution is unique and essential to the success of the project. If your skills are redundant with those of others, then you are constantly worried about your role in the endeavor. ... Afterall, you can't dance when someone is stepping on your toes."

User experience professionals "forced to defend their position as user experience experts" will be happy if fewer others would step on their toes, but overlapping responsibilities can facilitate collaboration in lots of cases (see, for example, "pair design pays dividends").

And lastly:

"And third, you must be able to articulate clearly how you will be rewarded fairly as a member of the team. ... Rewards, like good meals, should be shared."

But there is more:

"...these three ingredients are not satisfied automatically. Constant, respectful communication is needed to keep the Three-Legged Stool of Collaboration intact. Respectul communication is the glue that holds the three legs together. Without it, the stool falls over."

As Clement Mok also said in the above-quoted CHI '99 interview:

"Another piece of the equation is about communication and really listening, and about creating a forum in which disagreement can happen. Agree to disagree, and create a respectful environment to facilitate that. You can agree to disagree without having the respectful environment; that will destroy collaboration."

The "Tips for Working Successfully in a Group" presented by Randy Pausch during his opening plenary address at CHI 2005 provide some guidance for achieving such respectful communication. Among those tips:

• Meet people properly.
• Find things you have in common.
• Let everyone talk.
• Check your egos at the door.
• Praise each other.
• Avoid conflict at all costs.
• Phrase alternatives as questions

---
The quotations from the "Innovation..." book all come from Chapter 12 "forming the innovation team: how we won an emmy for hdtv."

Borrowing from the field of child development...

At last week's BayCHI meeting, an audience member asked speaker Dan Russell for advice on how to go about countering the great resistance she experiences in her workplace to doing any of the types of user research (e.g., field and usability studies) Dan had advocated in his presentation.

In a blog posting of a bit earlier in the week last week, Chiara Fox lamented the many "folks in the trenches" who are still fighting "a constant battle, where they are forced to defend their position as user experience experts" just as she and others did not long ago in a former place of work where they were "always putting out fires, being reactive instead of proactive, and constantly fighting against being treated as order takers" by others.

In a London pub three weeks ago, a London-based user experience research manager told me how so few people in his place of work and and in others' workplaces throughout the UK understand user experience and, hence, greatly limit what user experience personnel contribute to the companies.

These are recent examples of the kinds of situations I read or hear about on an ongoing basis. And they remind me of a comp.human-factors newsgroup posting of November 1995 entitled, "Why Don't They See the Need?" in which Deborah Wagner complained about the difficulty she was having finding a place to work "that truly believes in user-centered design methodologies." (I remember this posting, because I quoted it in an article several years ago.)

Have things not changed in eleven years?

At last week's BayCHI meeting, Dan Russell told the questioner that instead of struggling to convince people in her workplace to do user research, she should consider finding a place to work where they already value and do these kinds of things.

Indeed, there are now multiple companies that do value and do those kinds of things. But, there are more companies that don't, and many companies that do do so only somewhat and do not yet do the work in such a way that would be of greatest benefit.

Various models of aspects of corporate "user experience" maturity -- see "Changing the course or pace of a large ship" for a reference to one of the models proposed earlier this year -- describe stages of maturity that attempt to capture these differences between companies and sometimes even between different parts of the same company. And moving a company or a part of a company up such corporate maturity scales is something many need to attend to, even in Dan's place of work.

A User Research Lead who took our most recent Managing User Experience Groups course described one maturity stage worth targeting in the following clever way:

"My mental model is that the product teams think of me as 'that fun friend who drops in to occasional meetings, provides valuable input, and is often out-in-the field or other parts of the company advocating for our users.' … Isn’t there that stage in child development where the child realizes that an object still exists even when you can’t see it (object permanence). That’s the stage I think we need to get to with the product teams. And on the flip side, to flip the metaphor, we need to believe that mom and dad still love us even when we are out of the house!"

Easy7

Lots is going on in the world of User Experience in India these days:

• World Usability Day 2006 featured events in Hyderabad, Chennai, and Bangalore;
• a Doors of Perception conference will be held in India for the third time during 2007;
• a Design for All Institute is getting started in Delhi;
• more U.S.-based companies are building user experience groups in India (see, for example, "Usability professionals: You've come a long way baby!"), and more Western companies are learning the importance of involving India-based user experience professionals in designing for the multi-dimensional India market (see "Designing for emerging, non-Western markets");
• an active yahoogroup of HCI professionals in India now has almost 1100 members;
• etc.

As I referenced in a previous posting, I played a role in getting things going in India (as well as in many other countries), and I've continued to provide a bit of help over the years, in part by finding keynote speakers for CHI South India's annual conference in Bangalore. This year was no exception, though a new conference format features no single keynote speaker.

If you are in India or plan to be in India early next month, look into swinging by the Leela Palace in Bangalore for Easy7 on Friday, January 5. It promises to be an excellent event.

---
My humble thanks to Pradeep Henry and CHI-SI for including an interview of me on their website.

What is holding User Experience back or propelling User Experience forward where you work?

A version of this posting was published in UX Magazine.

A couple of months ago, I referenced variations of a boat metaphor (see "Changing the course or pace of a large ship") that I have found is often used by User Experience management personnel to describe what it feels or felt like to build and establish a corporate User Experience function, get it understood and valued, enable it to contribute to a business to the extent that it can, etc. As I stated in that blog entry, one director described the pace of change he has been able to achieve as akin to the pace of an oil tanker rather than a speed boat.

During our recently completed Managing User Experience Groups course, I used a part of that variation of the metaphor to learn about some of what is holding User Experience back or propelling User Experience forward in the rather wide range of companies represented by the students. More specifically, I used two forms of the Speed Boat exercise described in the recently published "Innovation Games: Creating Breakthrough Products Through Collaborative Play" (see "The way we work has enormous power").

For one exercise, I drew a speed boat and several anchors hanging from it on the whiteboard, and asked everyone to write onto post-its whatever has been holding User Experience back where they work and then place those post-its on the several anchors.

Some of the "anchors" holding their User Experience "boats" back:

• lack of an executive user experience role
• lack of leadership
• an unclear business direction
• inconsistent impact of User Experience on the business
• lack of senior management and other key stakeholder understanding of the importance of user experience to success
• lack of understanding of user experience roles
• lack of understanding of user experience process
• user experience process is considered to be overhead
• different processes for different projects
• last-minute changes made by executives to user experience strategies
• an inability to develop innovative ideas
• too many people need to be OK with an idea or a solution
• a splintered user experience group
• excessive workloads
• shortage of user experience personnel/resources
• inadequate support
• resources applied to addressing features rather than wholistic design
• no continued evaluation of products (i.e., there is never a phase 2)
• fear of change; fear of users (who don't like change)
• no explicit budget for user experience activities
• inappropriate balance between strategic work and implementation work
• nature of the physical work environment
• inadequate measurement or sharing of user experience success

Are any of those akin to "anchors" holding User Experience back where you work?

To learn what the students believe has been key to propelling User Experience forward where they work (to the extent that it has been propelled or is being propelled forward), I shifted the focus of the Speed Boat exercise from the anchors to -- you guessed it -- the engine propellers (see nearby photo). Interestingly, in several cases, "propelling forward" encompassed "moving upstream," to use yet another metaphor which, at least on the surface, is moving in the opposite direction! ;-)

Some of what has been key to propelling their User Experience "boats" forward:

• adding team members & expertise
• an executive champion
• situations in which user experience team input saved the company money
• executive support (which has enabled bypassing bureaucracy)
• exaggerations of the successes of the user experience organization
• hard work
• a dedicated prototype team that helps "show" what user experience personnel mean
• active participation by user experience personnel in meetings (e.g., product reviews)
• building relationships
• a better understanding & evangelizing of the design process
• client satisfaction; repeat business
• collaboration with developers
• success at customer demos of new concepts
• asking questions in meetings where you're not expected to
• good customer feedback from UI reskinning
• outside validation of the user experience process
• talking about use cases and users to folks who typically only think about features
• the overall positioning of the company (which now focuses on user experience)
• PM & developer champions, who tell others to "go ask (the User Experience Lead)"
• early prototypes
• familiarity with the benefits of user experience process
• evangelizing bottom-up
• increased sales (because of user experience work)
• improved metrics for flows after redesigns
• combining UI, user research, visual design, & content/copy into a single department
• socializing personas to the rest of the company via large posters and information booklets
• good client feedback to design
• flexibility: a willingness to do "a little" (rather than a full-blown research-design process) so to prove value

What a diverse collection of "propellers"!

In the course, we examine all sorts of "anchors" and "propellers" -- including many not appearing in the above lists -- to help students figure out how to move user experience further forward where they work.

What is holding User Experience back where you work? Why is that the case? What is needed to disengage those anchors and to propel User Experience further forward?

===
For more on what can hold User Experience back or propel it forward, see "Organizational obstacles" and "What to do about those organizational obstacles."

Why bother with the speed boats and the anchors and the propellers? There are several reasons, but one of the most interesting, in my view, is how they appear to help tap what participants actually "experience" in their workplace.

Note that at least one student plans to use a speed boat game akin to that described above to help in his process of working with others in his workplace to figure out how to move User Experience further forward. Perhaps you would find it of value to facilitate such a collaborative effort where you work.

Words (and definitions) matter; however...

In a blog entry I posted a bit more than a year ago, I asked, "Is 'user' the best word?", referring to a personal experience where use of that word led to confusion, and referring to multiple recommendations for alternatives to it.

One of those recommendations was a compelling 2002 appeal for use of the word "people," a recommendation echoed by Don Norman both when I interviewed him on stage two years ago and in an essay in the September+October 2006 issue of interactions magazine. The title of Don's essay: "Words matter. Talk about people -- not customers, not consumers, not users."

Other recent advocates for dropping the word "user" have included IDEO's Fred Dust on stage during DUX 2005 and Dan Saffer in his new book, "Designing for Interaction."

However, people have advocated for replacing the word "user" for a very long time. For example, in the April 1993 issue of Communications of the ACM, Jonathan Grudin argued that:

"the word 'user,' which was helpful in early engineering environments, is problematic in today's broader context. ... Computer users do not consider themselves 'users.' ... The term 'user' retains and reinforces an engineering perspective. (And) the term 'user' suggests that there exists a typical user or range of users."

I suspect the word "user" is here to stay. Indeed, Fred Dust used the word repeatedly in his remarks and Dan Saffer uses the term throughout his book.

Dan Saffer also presents an interesting definition of "user-centered design," as reflected in the following words:

"The philosophy behind user-centered design is simply this: users know best. The people who will be using a product or service know what their needs, goals, and preferences are, and it is up to the designer to find out those things and design for them. One shouldn’t design a service for selling coffee without first talking to coffee drinkers."

Compare those words with the following words of Richard Blitz in an announcement of a September 2006 presentation in Vancouver, British Columbia entitled, "User-centric Design Practices":

"User-centric design is all about observation. It's not what you think customers need or what they say they need; it's about closely watching real human beings solve problems, and understanding what will help them."

Interestingly, neither definition concurs with mine. Does either concur with yours?

"User experience" is also plagued by multiple definitions (see, for example, the three very different definitions I present in "Where should 'user experience' be positioned in your company?"). Recently, attempts have been made to once-and-for-all distinguish the meaning of this and related terms (see, for example, "What is User Experience Design?"), but keepers of the definitions in Wikipedia continue to struggle with attempts at editing those definitions, and lots of these terms continue to be used interchangeably (see, for example, Brandon Schauer's "What term do you use for 'user experience'?").

Words (and definitions) matter; however...

Brandon states that "What term we use seems to depend on what sells — within an organization, you use the terms that connect with the values and the understanding of the people you’re working with." I'm not convinced that even that is always the case.

Apparently not just about "Managing User Experience Groups"

Recently, one of those who took our "Managing User Experience Groups" course early this year wrote to others in her company:

"I highly recommend this UCSC Extension course. ... I found it extremely helpful in exploring User Experience from various angles. The course was not focused on just management topics but also on defining UE's role in a company, building the value case for UE, and overcoming the common obstacles we face as UE professionals. ...this also provides an opportunity to network with some great people in the design industry." (italics added by me)

Also recently, a friend working on a short article wrote to me about the distinction he was thinking of making between "managing UX professionals" and "managing the UX teams' place in the organization."

To me, the work of "managing user experience groups" encompasses both of those things, everything referenced in the earlier quote, and much more. But apparently, "Managing User Experience Groups" implies much less. And I wonder how much this makes the work of user experience managers (or directors or VPs or...) that much more challenging.

As stated in the course description, course topics include:

• building a user experience group
• defining the work of a user experience group
• defining the composition of the team
• managing the employee
• making the case for user-centered design
• working together and with others in the company
• roles that can be played by user experience personnel
• positioning user experience within a company
• extending the reach of a user experience group
• involving user experience groups throughout the development life cycle
• the impact of "culture" on user experience group success
• overcoming common obstacles

We've discussed changing the name of the course to something which more clearly encompasses all of these types of topics. But for our upcoming offering -- which starts in less than two weeks (October 11), "Managing User Experience Groups" will have to suffice.

Note that there is still time to register for the course which starts October 11. You can access the site via which to register for the course from the previously referenced course description.