Organizational obstacles

Next week, a paper will be presented at CHI 2006 entitled, "When Design is Not the Problem -- Better Usability Through Non-Design Means." In this paper, Luke Kowalski and his two co-authors state:

"When it comes to shipping quality software, design is not the hard part. Methods and techniques to study users, best practices for creating iterative designs, and tools to validate them are all very well documented. Unfortunately, in chaotic and complex ecosystems very few of the designs actually end up making it through the UCD process. Interaction designers’ input is either ignored or interpreted through a development/business lens and considerable fidelity is lost."

I've been paying attention to obstacles to designs making it through -- or even into -- the UCD (i.e., User-Centered Design) process for many years. In addition to obstacles I have encountered directly, I have paid attention to obstacles encountered by others. For example, I used to compile lists of obstacles as experienced in the workplace by participants in my semester-long user-centered design workshop. These many dozens of workshop participants -- I taught the workshop several times -- worked in a wide range of companies, and the number of obstacles was so large that I separated them into groups, labeling each group with a higher-level obstacle which seemed to capture what was going on in the specific cases.

While I was learning about these many obstacles and developing the groupings, I organized a BayCHI panel comprised of Don Norman (then a VP at Hewlett Packard), Janice Rohn (then Manager of Usability Labs and Services at Sun Microsystems), and Dan Rosenberg (then User Interface Architect at Oracle), and I asked this panel to comment on whether the obstacles were genuine (i.e., are they really obstacles to designs making it through the UCD process?), why they existed, and what could be done about them.

Here is that list of obstacle groupings. As you read through them, ask yourself whether the obstacles are genuine, why such obstacles exist, and what can be done about them.

Ignorance, Misunderstanding, or a Different Understanding
Those who need to buy-in to user-centered design (or "ethnographic" research or ...) often don't know about or understand it, or sometimes have a different view of what it is or when it should be applied.

Questioned Credibility of Non-specialist Messengers
Advocates' credentials are often challenged.

Questioned Credibility of User Experience Specialists
User-centered design (or ethnographic research or ...) personnel are often considered too "light-weight" (e.g., not "technical" enough, or not adequately business-minded, or ...), unable to communicate effectively with engineers or marketing personnel or executives, and unable to agree with each other.

Questioned Credibility of a Different Process
User-centered design, ethnographic research, etc. are often described as being "untested," "unproven," too "light-weight" (e.g., not technical enough, not statistically reliable, ...), ...

"I Can Do It Myself"
Collaborating with or involving others is difficult for some people and is sometimes perceived as weakness and/or unnecessary.

Powerful Personal Preferences/Biases
The perspectives of software engineers and others often inhibit acceptance of the perspectives of product or service users. (Users are seen as part of the problem, not a part of the solution.)

Discomfort with: Flexibility, Uncertainty, Imprecision, Not Getting It Right the First Time, ...
The nature of several aspects of a quality design process is strongly discomforting to many.

Competing "Religions"
Key elements of these methodologies are not completely compatible with existing, often entrenched and/or more technical development or marketing methodologies and practices.

No Rewards for Attending to User Needs
Rewards given within organizations often do not promote use or development of better methodologies and sometimes inhibit both.

Fragmentation of the Organization & of Responsibilities
Collaboration and adequate attention to the needs of product or service users are often made difficult by organizational structures and roles.

Frequent Organizational & Personnel Changes
Collaborating and maintaining attention to the needs of product or service users are often made difficult by rapidly changing organizational structures and personnel.

Insulated Developers
Technical development personnel are often separated from product or service users and are often protected from interaction with others to "keep them happy," "to not waste their time," and so they don't reveal things they shouldn't.

Inaccessible Users
Product or service users are often "protected" from interaction with developers; plus, users are sometimes located too far away and are even sometimes unknown.

Marketing Personnel Are Already Responsible for Customer Contact
Management often believes that attention to customer or other user needs is already covered.

"Buyers Are Not Users"
Salability or acceptability sometimes have little to do with usability or usefulness; a focus on features or the needs of the people who make the choice can dominate.

Increasingly Large System Size and Scope
Market or other forces push for added capability, making the task of meeting the needs of different types of users and uses more difficult and time-consuming.

Short Life Cycles & Development Schedules
Market or other forces minimize design time and flexibility, leaving what is often believed to be inadequate amounts of both for ethnographic research, user-centered design, ...

Immediacy Is Most Important
Organizations are often much more reactive and task-oriented than anticipatory & process-oriented. Hence, user needs are often discovered late and addressed via "fire fighting," which must occur quickly and usually has a short-range focus.

Small Staff and/or Budget
Many organizations believe they can't afford (in personnel or money) good user-centered design or ethnographic research or ...

User Experience Is Not Perceived to be an Issue
If there is no serious competition, or if only abit of functionality is being added, or if targeted users are believed to be highly technical, or if there is no direct user interface, or if ..., some organizations believe they don't need good design or research.

It is interesting that the above list is still largely valid though I haven't offered that workshop for several years. Though much has changed over the past few years, many perceptions of obstacles to designs making it into and through the UCD process are still the same.

There are definitely some obstacles not encompassed by the above groupings; indeed, Luke and his CHI 2006 paper co-authors identify a couple. And I wonder what list I'd come up with if I did the grouping process today, even with only the old obstacle stories and lists.

What obstacles do you encounter? Do you encounter any not addressed by the above list? Which items in the above list do you encounter where you work but are not actually obstacles to UCD? Are there any obstacles in your workplace to which you might be contributing?

Don Norman appeared on the BayCHI program a couple of times before he appeared on the BayCHI panel I mentioned above. The title of his talk during his first BayCHI appearance way back in February 1993 was, "Where HCI Design Fails: The Hard Problems are Social and Political, not Technical." During an on-stage interview just a year and a half ago, I asked Don whether the assertion he made in that title was still true. He answered without hesitation: "yes."

User experience work offshore/offshoring

While reading through interactions magazine's March+April 2006 special section entitled, "Offshoring Usability," I'm reminded of Fred Sampson's article entitled, "Taking UX Offshore," in the November+December 2005 issue. In that article, Fred describes abit of the early controversy surrounding offshoring (offshore outsourcing), but then states:

"Today, I think of offshoring as a non-issue. There's no point in lobbying against it, in writing letters to Congress or Parliament, much less to business executives. It's a done deal, a fact of life. Deal with it."

At CHI 2005, I moderated a panel entitled, ("Outsourcing and Offshoring: Impact and Consequences for the User Experience." Panelists discussed issues such as the impact of:

• time, language, and cultural differences;
• the nature and level of process development;
• infrastructure (both electronic and physical);
• location of users relative to offshore teams;
• level of training and expertise offshore; and
  
• characteristics of the work being offshored.

The panel's answer to the controversial question of whether offshoring of user experience work was good or bad pre-echoed Fred's view: don't view offshoring as good or bad; view it as a fact of life you must deal with.

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.

For those 5 years, I worked with (prospective) chapter leaders from long range as well as face-to-face, bringing many of these leaders together for annual workshops. I wrote and edited numerous articles to help (prospective) chapter leaders in all locations; articles included:

• Shaping the Roles to be Played During the 21st Century by Local Chapters of ACM SIGCHI, an article about the workshop for which I brought together leaders of 27 chapters from 18 countries;
• How New Local Chapters Work: The Experience of Czech SIGCHI, an article by Pavel Slavik and Boba Mannova about Czech SIGCHI's first two years and its plans for the future; and
• Diversity Within Unity: The Purpose of a Local SIG, about variations in chapter purpose and approach around the world.

And I represented the interests of local chapters worldwide as a member of an international SIGCHI Executive Committee.

Now, I'm a member of the Executive Council of the User Experience network (UXnet) which has Local Ambassadors in a rapidly increasing number of countries (25, I believe, as I write this) working to foster the growth of user experience communities and to facilitate networking among them (see UXnet Local Ambassadors: Building a Global Community One Locale at a Time). And I'm presently interacting with people in Asia and elsewhere to make UXnet's Advisory Board international.

I have also led expansion of user experience capability outside of the U.S. within businesses which have employed me, working with and within offices in multiple countries to develop and promote their user experience practice. I have hired, managed, coached, and advised individuals and teams in these offices, and worked to improve working relationships of user experience personnel with others within as well as across geographic boundaries.

I am very proud of all of this work, and I've delighted in getting to know and work with so many people around the world, traveling to Italy, France, Netherlands, India, Australia, Germany, U.K., Austria, and elsewhere to make it happen. Indeed, I hope much more work and travel of a related nature lies ahead for me.

Last November, I visited Microsoft Research Asia in Beijing to learn more about Neema Moraveji's exploration of issues of designing for the Chinese. As I stated in a recent blog entry:

"Great dividends await those companies who put ample resources in understanding the culture and living patterns of emerging markets, and in applying that understanding to identifying new opportunities for design for user experience."

Presently, I'm learning Mandarin via podcasts. I would have benefited from such learning when in Beijing last year, though I was able to get by reasonably well as the use of the English language in China is increasing. However, knowing more Mandarin than I did is important.

Offshore, and the offshoring of, user experience work is a reality that will increasingly affect us all.

Working "middle out"

As asked by the editors of interactions magazine in the March+April 2006 issue, "Is your company guilty of employing a multitude of [user experience] professionals, using them too late in the process, and growing them into tomorrow's janitorial caretakers of the interface?"

Do you happen to be one of those many user experience professionals often (or usually) brought into the process later than would be advisable -- sorta in the middle of things after alot of work has already been done in which you, or other user experience professionals, should have been significantly involved?

If so, try working "middle out."

On my first day as Director of User Research & Experience Strategy at Studio Archetype, I was asked to help a design team test three concepts they had generated for a major new website for Xerox. Yes, designers had generated the concepts -- a very good thing. But, no user research of any value had been done to guide concept design.

I suppose I could have told them, "Sorry, let's start over, do some decent user research, and then design the concepts." Indeed, a part of my role in the company was to introduce and integrate user research in the right way into the process. But neither the team nor the client would have been happy with that kind of response.

So instead, I designed a concept test that included some of the research that should have been done earlier. I called this approach, "starting in the middle and working backward and forward simultaneously." The concept test moved the process forward from where it was, while also working backward to do work that should have been done previously. And by involving the designers in the research in significant ways, the team came to realize that the user research could have been done earlier, a realization which helped move the quality of the concept design process forward for future projects.

In previous blog entries, I've referred to similar stories of working "middle out" in other workplaces. In some of those cases, the product concepts were not generated by designers, and I refered to whomever owned those important decisions about product concepts (or strategies or designs or...) -- decisions that user experience personnel should own or should influence more substantially -- as the people "in power" with whom it was essential to partner:

"involving those with power in an intensive process of rapid ethnographic research and its analysis/synthesis in certain cases, and in an intensive process of rapid iterative design and evaluation in others, was key. And they were involved in such a way as to enable ... them to directly experience how important user experience should be to shaping those decisions. The ultimate result was an elevation of user experience personnel into a relationship of strategic partnership."

At DUX 2005, Audrey Crane of Dubberly Design Office (DDO) told a very different -- yet very similar -- story entitled, "Middle-Out Design" in which those in power were physicians, engineers, and a product manager who were developing a complex product that enables physicians to enter orders on a handheld device.

"The client came to us in the middle of the project having already invested a year in design, content development, and engineering. The client was understandably looking to move forward -- they were not interested in starting over or even in a lengthy reassessment. The client (a self funded start-up) wanted to move forward as quickly as possible. ... [They] did not feel that they had time for extensive research and product concepting... [though they] had only began to consider how to organize screens and content.

...What we needed was a kind of 'middle-out' approach that would both address details quickly and address larger conceptual questions—so that the detailed work sprang from a logical foundation and resulted in a cohesive product. And the approach had to be something that our client was comfortable with, not a heavyweight or complicated process that would take time to explain and get accepted.

We decided to borrow from our experience in the quality assurance (QA) cycle of software development. Specifically, we introduced the bug tracking process, re-cast to address design issues or 'design bugs'."

Audrey's case study describes how careful assignment of priorities to design issues enabled them "to visibly focus [their] limited time on the most important problems" while "setting aside tangential issues gracefully."

"In the beginning of the project, we were concerned about jumping into the middle of a work-in-progress without taking the time to work out a product concept with the client. In the end, DDO found that some issues simply couldn’t be resolved without modeling the product concept. We reached that conclusion with the client, from the perspective of trying to resolve a specific issue. As a result, we never had to 'sell' modeling the product concept. The [client] team saw the need for themselves."

One final paragraph from Audrey's case study:

"In the final analysis, nearly all of the projects we work on are 'Middle-out' design problems -- it is unfortunately very rare to have an opportunity to start design during the product concepting stage. [This project] was so clearly starting in the middle of the software development process that we had the perspective to tackle it in a unique way. It never occurred to us to try to wrestle a 'perfect' process into an imperfect situation."

However, for future projects with the same client, or in those companies that employ a multitude of user experience professionals, it is hopeful that working "middle out" -- however it is accomplished -- will only need to be used as an approach to help transition an imperfect situation into one in which user experience personnel get involved much earlier than the middle.

---
More on "starting in the middle and working backward and forward simultaneously" appears in a chapter I co-authored entitled, "Strategies to Make E-Business More Customer-Centred." (Appears in "The Usability Business: Making the Web Work," Springer-Verlag London Ltd, November 2001.)

And according to the DUX 2005 blog, Audrey Crane's DUX 2005 case study will soon be appearing, along with all of the other DUX 2005 case studies, on the AIGA website.

Making changes to a company's culture

Both of the first two Designing for User eXperience (DUX) conferences included multiple stories of attempts at changing corporate culture.

Two -- one told at DUX 2003 about Alias|Wavefront and one told at DUX 2005 about Intuit -- are particularly interesting to compare.

In both cases, many years had passed since a software company had last designed, developed, and released a "version 1.0" product. Neither company was well-poised to do so again.

As told at DUX 2005 (and elsewhere -- see my earlier blog entry entitled, "On concept design, ethnography, MRDs, and product vision"), at Intuit the obstacle was an "organization ... entrenched in twenty-one years of legacy processes and mindsets":

"The entire organization, its skill sets and processes, was centered on creating an annual version of a product on a fixed schedule with a fixed deadline. Every mindset, timeline, and assumption had to be challenged..."

As told during my opening plenary interview of Bill Buxton (along with Mitch Kapor) at DUX 2003, at Alias|Wavefront the similar obstacle was that they had no design process at all akin to the design process successfully used again and again by its industrial design customers -- "some of the best industrial designers in the world" -- or akin to the preproduction process successfully used again and again by its film making customers -- "some of the greatest filmmakers in the world."

Nevertheless, in both cases, existing process (or lack thereof) was ignored, an excellent, user experience centered and led research and design process was initiated and followed, and a new product was brought to market. In the case of Alias|Wavefront, the product even shipped early.

And in both cases, market response to the new product was phenomenal.

However, a comparison of the organizational impact reveals very different results.

At Intuit, much of the new process has become a standard. More new products conceived and designed in a similar fashion are on the way, and the title of the "User Experience Lead" on the project was extended to include the words, "Product Visionary."

At Alias|Wavefront, noncomformance of the new process with the corporate norms was not well-received, so in spite of the phenomenal success of both the new process and product, Bill -- Alias|Wavefront's "Chief Scientist" -- found himself out of a job.

Why were the organizational responses so different?

Bill has long been attentive to issues that need to be addressed in order to make changes to the way companies approach design. At CHI 99, I interviewed Bill on stage (along with Cliff Nass), and I asked about some the obstacles to doing good design in business. One of Bill's answers:

"I want to find out how to have the skill of user interface design understood so that people will respect it in the same way that they respect the skill of hacking an operating system or designing a microprocessor. Since the skill of design is not well understood, everybody is an expert, and they all have an equal vote. There's no other discipline that I'm aware of where everybody has an equal vote, regardless of their skill or expertise. So, one of the ingredients that will bring us to better design within companies and other organizations is getting to the essence of what the core elements of design are that we have to put into place...in terms of the organizational structure of our teams and so on." (from Conversations with Clement Mok & Jakob Nielsen on Web & Web Design Limits for HCI, and with Bill Buxton & Clifford Nass on Human Limits to HCI, interactions, January+February 2000)

However, a key problem at Alias|Wavefront appeared to be a lack of executive support. Recently, Bill wrote about the importance of executive support, in the form of a "Chief Design Officer" (akin to the "Chief Experience Officer" I wrote about in an earlier blog entry):

"Is design leadership an executive level position? Do you have a Chief Design Officer reporting to the president? My view is that if you do not, you are not serious about design or innovation. Furthermore, you are telegraphing this fact to all of your employees, along with a clear message that they need not be either. As a result, you might as well fire all of your creative people, since you are setting them up to fail anyhow." (from Innovation vs. Invention, Rotman Magazine, Fall 2005)

Though there is no Chief Design Officer or Chief Experience Officer at Intuit, a maturing financial software market had prompted CEO-level support for the development of new products that "would truly make a difference in people's lives."

Late last year, Bill was hired by Microsoft, a company he refers to as:

"in transition from being an engineering-led company to as much a design-led company. There are more designers at Microsoft on any single team as there were not too long ago in the entire company. It's a wonderful change." (see Newsmaker: PC or people--who's the boss?, December 20, 2005)

Evidence of that change includes Microsoft's having given control of the design of Office 12 to a team of user experience designers, as reported by lead designer Jensen Harris at the December 2005 BayCHI meeting. And the Office 12 user interface is dramatically different from any Office user interface which has preceded it.

Have these changes been favored by executive support? At Microsoft, they wouldn't have happened at all without such support.

Hence, Bill contributions are likely to be received much more positively at Microsoft. Bill's personal mantra -- below -- will be repeated within Microsoft often.

"Ultimately, we are deluding ourselves if we think that the products that we design are the 'things' that we sell, rather than the individual, social and cultural experience that they engender, and the value and impact that they have. Design that ignores this is not worthy of the name." (from Bill's website)

Still time to register for "Managing User Experience Groups"

I will be co-teaching a 6-session, evening course entitled, "Managing User Experience Groups" in Silicon Valley beginning 25 January.

The course -- really a workshop -- is intended for those who presently or may in the future manage a user experience group; those who are higher level managers whose domains already or may in the future encompass user experience; and others who in other ways (can) impact how user experience personnel are managed.

What is the scope of "user experience" and of the work a user experience group does or should do? Who should be a part of a user experience group? With whom should members of a user experience group work, and how? How should such groups be positioned in companies? What reduces the effectiveness and impact of user experience groups, and what can be done about it?

Join us in exploring answers to these and other questions of relevance to effectively managing groups that are often cross-functional (i.e., composed of designers, researchers, information architects, and others) and often misunderstood. Learn answers to these types of questions for a wide range of user experience groups in a wide range of companies, and gain insights for answering these questions in your company.

Dates, times: 6 consecutive Wednesday evenings, January 25 - March 1, 2006, 6:30-9:30pm

Location: UCSC Extension Silicon Valley Campus, 10420 Bubb Road, Cupertino, CA 95014

For more information or to register: UCSC Extension Silicon Valley course website

(And as stated in a previous blog entry, we have been talking with numerous user experience group managers, directors, VPs, etc. from a diverse mix of companies as we have been working on this course. We intend to talk with more in the coming weeks, and hope to hear from more to expand our network.)

Designing for emerging, non-Western markets

During the recent Designing for User eXperience (DUX 2005) conference, Ashwini Asokan demonstrated a coffee preparation ritual of Southern India during which coffee is poured back and forth between tumbler and cup several times. As she explained, alternative means of coffee preparation imported from other parts of the world haven't caught on, because they do not support this graceful ritual which is filled with "social, religious, traditional, emotional, and cultural significances related to the daily event." However, attending to and understanding the ritual enables identification of new opportunities for coffee product design more likely to succeed in India.

Also during DUX 2005, Neema Moraveji described "fundamental and broadly-applicable issues of designing for the Chinese" that surfaced during an exploration in interface design for the Chinese migrant worker population. These issues included "difficulties in Chinese character input, interfaces on a Chinese scale, and the Chinese people's sense of privacy." As in the case with India described above, attending to and understanding these issues should enable identification of new opportunities for product design more likely to succeed in China.

Other DUX 2005 presentations addressed related issues, such as in the context of designing an Arabic user experience, and even in the context of redesigning General Motors websites in differing world markets.

I visited Neema at Microsoft Research Asia in Beijing abit more than a month ago, and while there was able to attend demos they prepared for attendees of the Design for the New China Markets Conference sponsored by IIT's Institute of Design. As stated on that conference website:

"Western companies interested in selling products and services to the new China market are discovering that, as Chinese consumers become more sophisticated, their development teams must compete more aggressively to create offerings that better fit the Chinese culture and living patterns. Companies who thought it was sufficient simply to understand 'the China market' are shocked to find there are actually several China markets, and that their offerings need to be created with the same care and sophistication as the offerings they create for the sophisticated and diverse markets in the West."

And as Ashwini and her co-author state in the paper they prepared for DUX 2005:

"Technological innovation and development has reached a high point in the world today. In this context, people all over the world demand for more value addition and meaningful experiences. Demands for novel and fancy experiences with technology are being replaced by the need to return back to the roots of their culture. Organizations ranging from small companies to big nations are struggling to redefine their identities by finding a balance between technology and culture, and innovation and experience."

Clearly, great dividends await those companies who put ample resources in understanding the culture and living patterns of emerging, non-Western markets, and in applying that understanding to identifying new opportunities for design for user experience.

In preparation for teaching a course on "Managing User Experience Groups"...

I will be teaching a 6-session course with Lillian Svec via University of California Extension entitled, Managing User Experience Groups, beginning late January in Cupertino, CA.

As part of our preparation for that course, we are interviewing an assortment of user experience managers/directors/VPs in an assortment of companies to learn of their approaches, challenges, strategies, etc.

If you are a manager/director/VP of user experience (or some subset or variation thereof) and might be up for a chat with us, please let us know. We'd love to connect with you.

The importance of DESIGNING a conference program (session)

A few weeks ago, I reviewed several panel proposals for CHI 2006. And I was impressed by how nicely most of the proposals attended to designing the panels for a stimulating and original audience experience -- a requirement specified in the CFP.

A few years ago, I was a Panels Chair for CHI 2004, and my goal then was to replace several of the series of short talks which typically comprised CHI conference panels with "stimulating and original audience experiences." Previous CHI conference Panel Chairs had encouraged authors of panel proposals to design their panels to this effect, but few authors ever did. So, I and my Panels Co-Chair revised the CHI conference panel CFP considerably, requiring panels to be designed:

"Consider using a combination of different styles of presentations in a panel. Genuinely design your panel for a stimulating and original audience experience. The conference facilities are flexible, so consider creative use of the space. Panels consisting largely of a series of short talks -- a panel format that has become the norm at CHI conferences -- will not be accepted unless the submission adequately justifies that format, explaining how that format is best for the audience experience. All panels must be designed to be especially engaging, and submissions must explain how the panel format will achieve that kind of audience experience."

Additional instructions we developed included examples of engaging formats and elements to inspire panel design.

The two CHI conference panel CFPs written since then have pretty much used the same wording, retaining the requirement that panels be "genuinely designed."

Was this requirement successful? To some extent. Most CHI 2004 panel proposals attempted to meet the requirement, but most attempts tended to be conservative, with the actual "performances" on stage even more conservative -- i.e., more like traditional CHI conference panels -- than promised in the proposals. CHI 2005 panels I witnessed were also conservatively designed, for the most part, and a particularly engaging but appropriate component of a panel proposal I was a part of was deemed too risky by reviewers, suggesting reviewers were still applying somewhat conservative criteria.

Hence, it is nice to see authors of most of the CHI 2006 panel proposals I reviewed do a good job at attending to the design criteria. And I hope that those who choose which CHI 2006 panel proposals to accept will make sure the design requirement has been fulfilled.

Of course, panel sessions are only a small portion of a large, multi-track CHI conference. But panel sessions have been a large portion of the much smaller, single-track DUX conference.

Prior to my work to make CHI conference panels more engaging, I was one of two Program Chairs for the first Designing for User eXperience conference (DUX 2003). For that conference, all submissions requested were case studies or case study variations. No panel proposals were requested in the conference CFP. However, my Program Co-Chair and I decided to make every conference session a panel.

We did this after having read all of the many conference submissions and their reviews as part of our process of "genuinely designing" the conference program. We identified relationships and key differences among submissions that we believed were important to highlight and explicitly address during the conference. And on that basis, we decided to accept alot of submissions, and pack them into a very limited number of sessions, each of which would be a panel that needed to be well-designed in order to engagingly highlight those relationships and differences.

So, we discussed this need (suggesting panel design options derived from our reasons for grouping the accepted submissions as we did) with each of the session chairs we had selected and sent the following message to each accepted submission author:

"Our intent is to have each program session creatively designed into an interactive panel. Hence, your session is unlikely to be a typical panel session featuring a series of short talks, followed by Q&A. While relevant details of each accepted submission will still be presented by their authors, it is important that each submission be addressed in the way that it relates to the overall theme of the panel, as well as tie into a broader statement about what it means to design for user experiences. Precisely what that means for author participation in the session will be worked out with the session chair."

There were some grumblings from some of the authors, as this meant that their presentations could not be designed independently of the presentations of others and that they could not address everything they had addressed in their submissions. But, the resulting panels were well-designed. They were very engaging. They were creative. They compared and contrasted different though related approaches, real-world constraints, etc., providing a unified experience and value for conference attendees of all levels of expertise.

Yes, some of these panels were better designed than others, but they all worked and worked very well. The combination of these panels and the two plenary panels I designed and moderated comprised a well-designed, unified experience. (The only session that didn't work well was an "invited" panel we handed over to another person.)

The conference was a huge success, ending in a standing ovation.

Having successfully programmed so many gatherings (e.g., in addition to being a DUX 2003 Program Chair, I programmed the monthly meetings of BayCHI for 12 years), I decided to shift to being a Conference Chair. I was asked to co-chair CHI 2005, but instead chose to co-chair the second DUX conference (DUX 2005), given my focus on user experience practice and practitioners.

Given the success of the DUX 2003 program, it was not surprising that the DUX 2005 Program Chairs chose to take a similar approach to that I had taken with my DUX 2003 Program Co-Chair. Indeed, I encouraged it!

However, as the conference unfolded, it was much to my dismay that most of the panels had not been designed at all. I had expected them to be, but they were not. Instead, they were mostly a series of short talks prepared independently, with most presenters rushing to talk about as much as they could of what they had addressed in their submissions, though there was far too little time to do so. Significant similarities and differences among submissions of importance to user experience practitioners were not the focus. And I'm still perplexed as to why some very academic submissions were even accepted to be a part of a conference for user experience practitioners.

Some presenters did a wonderful job, recognizing that their presentation time was limited and fitting a focused, informative, and engaging presentation within it. Others oddly fought the time constraints on stage, and in one humorous but wasted presentation, even mocked them. And, of course, the experience of the panels was usually less than a unified whole. And though the conference program included some fabulous components (e.g., the amazing Bill Irwin at the opening plenary), as a whole, of course, it was also less than a unified experience.

So, although the conference has received some glowing praise (e.g., from Elizabeth Bacon), it has also received some knocks (e.g., from Steve Portigal).

Is designing a conference program (session) important? Without question. Hence, whenever you have responsibility for any portion of a conference program (session), see to it that that your portion and the program (session) as a whole is genuinely designed.

Blogging for DUX 2005

It might look like I've stopped blogging, but that has been far from true.

For the past few weeks the sole focus of my blogging has been the Desiging for User eXperience conference (DUX 2005), for which I am a Conference Chair.

Come visit the DUX 2005 blog, which I'll keep active for awhile after the conference is over. (That is me in the photo, with Brian Blau, Conference Co-Chair to my right, and Bill Irwin, Tony Award winning actor and DUX 2005 opening plenary speaker and performer, to my left. DUX 2005 opens today!).

Walls

In the world of "user experience," walls have a bit of a bad name.

For example, "throwing" something, such as requirements, "over the wall" is considered bad, since it often means a lack of advisable collaboration or partnership preceding or following the throwing.

Such walls imply a strict division of ownership, which the User eXperience network's Executive Council (including yours truly) have argued might be inappropriate:

"Who owns user experience (UX)? This is the wrong question to ask. We don't believe any single group can own UX.

What's the alternative? In our view, a useful focus is collaboration, not ownership. The best successes come from collaboration. Whatever type of product, service, or document you are creating, whether it's a Web site, an application program, an MP3 player, or a financial form, user experience encompasses so many diverse aspects of your product that 'ownership' just isn't a useful perspective. UX is about providing value to your customer and the business serving that customer. The best user experience is the product of many different disciplines working together."

(from the May+June 2005 special issue of interactions entitled, "Whose profession is it anyway?")

But walls can actually contribute greatly to the advocated collaboration.

For example, using walls as a work surface can greatly facilitate collaboration. And this facilitation can have a long and powerful life if the work on the walls can remain over time, particularly if it provides an immersive workspace that continually informs and guides the work.

Judy Olson and colleagues describe how such a use of walls can be beneficial in a CHI conference paper entitled, "A room of your own: What would it take to help remote groups work as well as collocated groups?":

"Collocation of cognitive artifacts and team members offers the broadest bandwidth for cooperative work. Team members developed shared documents together, making the work tangible. Artifacts helped coordination and motivation as well. The key feature was that they were persistent, allowing easy access (by a glance, not a file retrieval) and large enough to allow cross connections to be perceived. The presence of one's co-workers helped with coordination, implicit learning, easy transitions from one phase of work to another, and social facilitation."

Such use of walls was critical to our collaborative work in Viant's Experience Center (see photo) and has been critical to the collaborative work of many others (for example, see Marc Rettig's documentation of the many ways walls were used to facilitate collaboration at HannaHodge and on a project described at DUX 2003).

But even walls of ownership can contribute to the quality and appropriateness of the collaboration involved in designing for user experience. As the editors of interactions state in that special issue referenced above:

"Attributing responsibility or accountability is different than attributing participation: We believe that UX (user experience) is by its nature collaborative. Working with multi-disciplinary teams is a significant part of our work life.

...(However,) 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."

The case for case studies (and DUX 2005)

Several people have made the case for case studies over recent years. Among them is Dennis Wixon, who in the July+August 2003 issue of interactions argued that the current research literature largely fails the practitioner:

"If our discipline is serious about public discussion of methods as they are applied in industry, we will move to ... a broad-based case study approach, examining outcomes that are relevant to both practice and business. Our relevance as a discipline and our career success as practitioners depend on such a change."

The current editors of interactions say more in the July+August 2005 issue:

"Case studies are important; they're readable, they're engaging, they reflect on the same issues you do, and sometimes they present an approach that is so gloriously and confoundedly obvious you'll wonder why you didn't think of that. They also emphasize best practices. But don't take our word for it. Nancy Frishberg, one of the DUX 2005 program chairs said recently about case studies:

'The case study format encourages more interplay between the images and words, because of the extended length (compared with some other conferences including CHI). It also helps remind practitioners that learnings from projects are worth recording and sharing whether they count those projects as unvarnished successes or not.'

...The good news is there is an excellent conference where practitioners share best practices: DUX 2005 (www.dux2005.org). We encourage all practitioners to consider attending DUX 2005 at Fort Mason in San Francisco this November. The program consists of Design Case Studies, Design Practice Studies (less focus on evidence, more on process), Design Research Studies (evidence through research that provide guidance or prediction of results), and Sketches (work in progress)."

More details of the DUX 2005 program have been appearing recently on the DUX 2005 conference website. Among them is a listing of ~60 agency, industry and academic case studies, research studies, practice studies, sketches and posters, from diverse cultural geographies, spanning a broad range of design exploration. Tutorial details are also there, as I referenced in an earlier blog entry. To come are more details about the opening and closing plenary sessions, studio tours, and an assortment of special events. (As I've been posting to various mailing lists today: though not described on the website as yet, the opening plenary session will feature 2005 Tony Award-winning actor and MacArthur Award recipient Bill Irwin, comedian and performer Heather Gold, interactive artist J.Walt Adamczyk, and special recognition of World Usability Day.)

So, if you are a user experience practitioner, give serious thought to spending your 3-5 November 2005 at the Fort Mason Center in San Francisco. (And register soon. Early registration rates expire 1 October, and we do expect a sellout.)

Is "user" the best word?

One day when I was head of the User Research & Experience Strategy discipline at Studio Archetype and Sapient, a marketing strategist burst into my office eager to share an idea. "Your people shouldn't do only 'user' research," he exclaimed, "You should also do 'non-user' research! You should be investigating why people aren't users. And even for those who are users, you should be exploring what they do when they aren't users that has an impact on what they do as users."

"We already do all that -- and more," I responded, rather surprised to hear that he thought we didn't.

"But then why do you call it, 'User' Research?" he asked.

Wow -- the power of words. Even though he had been involved in some of our work prior to this conversation, the label of the discipline excessively constrained what he thought we did.

Hence, I'm sure my use of the word "user" in my tag line of "Changing the Role 'User Experience' Plays in Your Business" also excessively constrains what some people think I mean. Aware of that, I do place the words "user experience" in quotes; however, I doubt that does much to eliminate misunderstanding.

When I was at Viant, another marketing person argued that I should use the words "customer experience" instead of "user experience" when I talked about this stuff. Indeed, it was the "Experience Center" I started at Viant, shedding both of the problematic first words. (I'm sure you know the arguments against the use of "customer" in this context, though a great many use that term instead.)

The word "user" has taken abit of a beating over the years in the context of the label "user-centered design." "Usage," "experience," "performance," "human," "customer," "activity," and "value" have been among the words advocated as replacements (resulting in "usage-centered design," "experience-centered design," etc.), with "-centered" also being tossed by some in favor of "scenario-based," "contextual," "task-oriented," "goal-directed," "culture-based," or "experience" (resulting in "scenario-based design," "contextual design," etc.), among others.

The alleged value of these alternatives varies. For example, in the Winter 2002 issue of "User Experience," a former student of mine, Hunter Whitney, and a co-author bemoan how "user-centered design" is nothing but "usability-centered design" to many people; that is, design is often inappropriately framed in terms of efficiency and ease-of-use rather than the total experience. So, they advocate the following:

"...begin to think of and talk about our customers and users as people who have needs for status, esteem, a sense of belonging, love and, of course, usability. Users need to complete tasks. People need to feel needed. Approach what you do from a person-centered perspective. Replace user with person in your research and design vocabulary and you'll be amazed at the change in your and your team's thinking. Yes, it is just a change of a word, but it can have an immediate impact on your team and the groups they influence."

Don Norman more recently joined the fray by advocating for "activity-centered design" in the July+August 2005 issue of interactions.

Yet, the word "user" hangs on strongly. Hence, we continue to use it in the title of the conference I co-chair: Designing for User eXperience (DUX) 2005. And it remains a part of the label of UXnet (the User eXperience network), for which I am an Executive Council member.

In the UXnet website FAQ, we include the following:

"Why use the label User Experience?
We know that some people object to 'user experience' because:

• they don't like the word 'user,'
• or they don't like the word 'experience,'
• or they don't think you can design an experience.

Despite all this, we chose it for our umbrella term because:

• it's in common usage and reasonably well understood
• it is neutral - and used by all the communities in one form or another, and
• we had to call it something!"

So, is "user" the best word? Is "user experience" the best label? Well...

Effective collaboration and fun

One of the submissions I reviewed recently for DUX 2005 was a paper about a game designed to facilitate the analysis and synthesis of diverse collections of data (some from ethnographic studies, some from participatory design sessions, some from technological explorations, ...) by diverse, multidisciplinary groups of researchers and designers. The output of the game is intended drive the process of identifying and designing needed, desired, and sustainable technologies.

A game? Why a game?

The authors of "Facilitating Collaboration through Design Games," a paper presented at PDC 2004, provide this partial response:

"The overall aim of the design games is to help facilitate a user-centered design process for cross-disciplinary design groups early in the design process. Framing collaborative design activities in a game format arguably improves idea generation and communication between stakeholders. By shifting focus to the game, power relations and other factors that might hamper idea generation are downplayed."

The impact of those power relations and other factors appears to be minimal during what is described as a typical, well-run session of The Bridge, a collaborative analysis, design, and assessment methodology involving users, engineers, design/usability personnel, and potentially others as designed by Tom Dayton and former colleagues:

"The athmosphere is fun, sometimes goofy, with periodic showers of paper as discarded index cards and sticky notes are torn up and thrown over shoulders." (from chapter 2 of a book on Bridging the Gap from User Requirements to Design)

Writing on emotion and design, Don Norman describes the relationship between affect and behavior:

"Affect...regulates how we solve problems and perform tasks. Negative affect can make it harder to do even easy tasks; positive affect can make it easier to do difficult tasks.

The positive affective system seems to change the cognitive parameters of problem solving to emphasize breadth-first thinking, and the examination of multiple alternatives."

And according to Patricia Ryan Madson, in her new book, "improv wisdom: don't prepare, just show up":

"Having fun loosens the mind. A flexible mind works differently from a rigid mind. The pleasure that accompanies our mirth makes learning easier and creates a climate for social as well as intellectual discovery."

However, there are dangers. According to Don Norman, positive affect "has the side effect of making people more distracted." Plus, people not participating might complain if you are having more fun than they are having, as I once learned when facilitating collaborative ethnographic data analysis and synthesis sessions a few years ago.

So, find a sound-proof room, facilitate the sessions well to address distraction effectively, ...

On concept design, ethnography, MRDs, and product vision

At a BayCHI Usability Engineering BOF meeting last month, Suzanne Pellican, a User Experience Lead at Intuit, described the process via which the new and very successful Quicken Rental Property Manager was conceived, designed, and developed. According to Suzanne, one of the reasons for the success of this product was that she was able to deviate from common product development process and design the product concept -- iteratively involving potential users -- prior to the creation of a Market Requirements Document (MRD).

In many companies, MRDs are generated before user experience professionals have an opportunity to get involved. Many product development processes tend to imply, if not dictate, that design doesn't begin until after identification of market requirements.

At Yahoo!, a product development process that I had a hand in creating had a "Design" phase preceded by a phase that ended with development of an MRD. Troubled by this labeling, I put alot of work into developing diagrams showing how design and user experience personnel should be involved at different points which led to the development of the MRD. I also promoted development of means to help product managers and other personnel follow such a process.

Doing iterative concept design prior to generating an MRD was not the only reason for Suzanne's success. One of the other key reasons: she and others had done a great deal of ethnographic research which gave rise to the product idea and which provided crucial design guidance.

Because of the success of Quicken Rental Property Manager -- the first new product released by the Quicken team for many years, Suzanne's title was extended. She is no longer just a User Experience Lead; she is now also called a Product Visionary.

Are user experience practitioners playing major roles in envisioning new, innovative products in your business?

Join us in sponsoring DUX 2005

The response to the DUX 2005 Call for Participation was enormous. So, we are now beginning the thrust of our campaign to invite companies to join us in sponsoring DUX 2005.

We'll be initiating our big PR push for the conference later this month as we publish many more details about the conference program. This PR push will extend up to, through, and even after the conference, but now is the time to join us so to achieve maximum benefit from your DUX 2005 sponsorship.

As stated on the DUX 2005 website:

"Sponsorship of DUX 2005 demonstrates that your organization understands the impact user experience has on business success and identifies your organization as a leader in supporting the development of the practice of designing for user experience."

Hugh Dubberly and Robin Bahr of the Dubberly Design Office are taking the lead in inviting companies to join us as sponsors. Multiple sponsorship packages have been pre-designed to facilitate sponsorship discussions, but feel free to propose deviations from those. You can contact Hugh and Robin via sponsorship@dux2005.org.

We hope your company will choose this way to become an important and highly visible part of the premier conference for user experience practitioners.

Start anywhere

Where do you start if you would like to change the role user experience plays in your business?

According to a chapter entitled, "Where Do I Start?" in the new book "Fearless Change: Patterns for Introducing New Ideas" (see my recent "Patterns for Achieving Change" for more info on the book and its contents):

"an effective change agent begins as an Evangelist. That is, we see this pattern with this name as the starting point for the rest of the pattern language. The name has a religious flavor and there's a good reason for that: We've found that unless you are truly passionate about the new idea, others will not be convinced to leave the tried and true ways and follow you."

In a chapter entitled, "Strategies to Make E-Business More Customer-Centred" in the 2001 book "The Usability Business: Making the Web Work," I and my co-author answered the question in a different manner. We called a strategy we used in a variety of organizational contexts, "Starting in the middle and working our way backward and forward simultaneously." As I state on my website:

"this strategy employs techniques which enable development of the kind of understanding of user experience that is needed for moving forward appropriately but that could have provided critical direction to earlier activities. Recognition of the latter by those responsible for the earlier activities can increase the chances that this kind of understanding of user experience will be developed earlier in the future and, hence, will play a different and more valuable role in the process."

A tweak of the label to refer to organizational hierarchy rather than process yields another starting point that can be a good one: "Starting in the middle and working your way UPWARD and DOWNWARD simultaneously."

The most appropriate starting point, and how best to frame it, will depend on the situation in which you find yourself.

However, I like the advice of Patricia Ryan Madson, as presented in the new book, "improv wisdom: don't prepare, just show up." Patricia describes why a particular San Francisco improv trio is so successful:

"They understand this vital improv principle: All starting points are equally valid. They begin where they are, often in the middle."

(See "Done any good improv lately?" for more on the relevance of improv to changing the role user experience plays in business.)

Stellar DUX 2005 tutorial lineup

Six outstanding tutorials will be offered on day 1 of the three-day Designing for User eXperience 2005 conference.

Marc Rettig returns to DUX to lead a workshop on tools for analyzing and understanding the layers of human experience, a prerequisite for successful design.

Steve Portigal, whom I referenced in a related blog entry ("Done any good improv lately?"), will offer a tutorial about improv, ethnography, and innovation, and how the three fit together.

How to choose high-value, high-impact Web development projects will be a part of the focus of a tutorial presented by Janice Fraser on the ROI of user experience and the context of UX practice.

Shelley Evanson will provide instruction on designing for service; Mark Baskinger will teach methodologies of hand-generated visualization; and Brian Lanahan and Gary Hirsch will teach how fundamental principles behind effective stories can inform work on brand identity, design, and user experience.

Information about each of the above offerings can be found on the DUX 2005 website.

(Thanks especially to Rakhi Rajani, DUX 2005 Program Co-Chair, for her work pulling together this stellar tutorial lineup.)

Patterns for achieving change

How do you go about changing the role "user experience" plays in your business?

A new book by Mary Lynn Manns and Linda Rising entitled, "Fearless Change: Patterns for Introducing New Ideas" describes 48 patterns (i.e., recurring best practices -- strategies) "for driving and sustaining change in your organization." And it presents a framework -- a pattern language -- for how the patterns work together at different points in the change process.

The following paragraph from the end of chapter 5 provides a flavor:

"If you've been able to apply the patterns in this chapter, you've been busy! You've had a meeting using the pattern Piggyback or Brown Bag. Perhaps you were able to Do Food and you scheduled the meeting at The Right Time. Your brought some interesting books or articles, hoping to Plant the Seeds and point to External Validation for your new idea. You talked about the Next Steps for your fledgling effort and maybe you used e-Forum to help Stay in Touch with people who are getting interested in your work. If you were really lucky, your collection of like-minded folks has started to form a Group Identity."

Patterns of a different sort, and how they can work together effectively, are described in a May+June 2005 interactions article entitled, "Success with User-Centered Design Management." According to the authors, "Doing good design work is actually the easier part of the software user interface design process. The real challenge lies in getting (good) designs realized in a product." Formalize Communication, Manage Expectations, and Facilitate are among the patterns, or "principles," that Jeremy Ashley and Kristin Desmond argue can be applied to meet this challenge.

Patterns described in both publications can help you figure out how to address your particular challenge regarding changing the role "user experience" plays in your business.

(My thanks to John Thomas of IBM Research for refering me to the book on Fearless Change, and to Luke Kowalski of Oracle for referring me to the interactions article.)

Framing change / Changing frames

How do you go about changing the role "user experience" plays in your business?

As described in a May 2005 Fast Company article entitled "Change or Die," how you "frame" the change is important, as you often need to change the way things are currently framed.

"Our thinking is guided by narratives, not facts. When a fact doesn't fit our conceptual "frame" -- the metaphors we use to make sense of the world -- we reject it."

I made a short presentation about this at a symposium a number of years ago. Calling my presentation, "Models We Live By" (mimicing a portion of the title of a George Lakoff book, "Metaphors We Live By"), I talked about the conceptual models -- the frames -- that governed much of the thinking at my place of work then that were obstacles to my introduction of forms of user-centered design, ethnographic and usability research, and the like.

So facts and analyses will not alone motivate change?

"Behavior change happens mostly by speaking to people's feelings. This is true even in organizations that are very focused on analysis and quantitative measurement, even among people who think of themselves as smart in an MBA sense."

In a presentation on the Business of Design earlier this week in San Francisco, Tom Andrews and colleagues from Stone Yamashita emphasized the importance of engaging emotion in their work with corporate executives to redefine and change organizational culture.

Should you motivate change by the emotion of fear?

"It's too easy for people to go into denial of the bad things that might happen to them. Compelling, positive visions of the future are a much stronger inspiration for change."

The extent of the role compelling visions of the future can play in achieving change in a business is very nicely described in a July 2005 Boxes and Arrows article entitled, "Customer Storytelling at the Heart of Business Success."

But oftentimes decision makers need to participate in the development of those compelling stories for change to occur. I've talked about this in a couple of earlier blog entries (e.g., "Perturbing the ecosystem via intensive, rapid, cross-disciplinary collaboration"), where facilitation of that development is key ("The need for good facilitation").

Indeed, Stone Yamashita's approach to designing organizational change is very much one of creatively facilitating their clients' development of those future visions. (For more on the work of Stone Yamishita, where several of my former colleagues do wonderful work, see "Designing Change" in the May/June 2005 issue of Communication Arts.)

(My thanks to Juli Betwee of pivot.point for providing me with a copy of the quoted Fast Company article.)

Collaboration sessions

How do you achieve effective collaboration among the multiple disciplines involved in designing for user experiences?

Someone I've worked with -- Sasha Verhage -- tells how in Collaboration Sessions: How to Lead Multidisciplinary Teams, Generate Buy-In, and Create Unified Design Views in Compressed Timeframes (see this July 2005 article in Boxes and Arrows). Sasha describes an approach he has used for several years for running effective collaboration sessions during website redesign projects.

Guidance for running collaboration sessions for various types of projects is widely scattered. I've refered to other types of collaboration sessions from my worklife in previous blog entries (e.g., "Perturbing the ecosystem via intensive, rapid, cross-disciplinary collaboration"). I'll refer to still others in future postings, and will talk more about some of the elements that successful sessions have in common (I already talked abit about "The need for good facilitation," which Sasha also emphasizes).

Sasha tells me that he has received email from people around the world asking for additional information about his approach. What kinds of information do you or others you know seek regarding collaboration? In what contexts do you experience collaboration challenges? What approaches to collaborating do you find particularly effective?

Design humans in or design humans out?

In the most recent issue of ACM's Ubiquity, Francis Hsu argues for "lowering the frequency and necessity of human data inputs" in future IT systems and applications.

When I worked at Pacific Bell many years ago, I often heard similar arguments. IT systems were designed to minimize human involvement in their operation. Humans were to be involved only when there were "exceptions" -- i.e., cases that the technology could not handle on its own. The goal was to reduce this pricey human involvement as much as possible.

Reducing pricey human involvement remains the goal years later for lots of systems. The Vice President responsible for usability and user productivity at a major enterprise software and services company emphasized the importance of this goal in a conversation I had with him earlier this year.

Contrast the above perspective with that of John Thackara, who visited the San Francisco Bay Area in May to promote his book "In the Bubble: Designing in a Complex World." John lamented the ongoing goal of replacing people with technology, telling tales about the terrible user experiences that so often result. Referencing very different, innovative examples exhibiting outstanding user experiences, John advocated a design principle of "enabling human agency" -- of designing people in, rather than designing people out.

Should humans be designed in or designed out? Is the answer, "it depends"? If so, on what does it depend?

For more information on John's new book, including extracts from the book, see www.thackara.com/inthebubble/.

Submission deadline for DUX 2005 extended to July 1

To accommodate the strong interest in submissions and the posting of the Submission Kit later than expected, the DUX 2005 Conference Chairs announce that the deadline for submissions has been extended from June 15 to July 1. (The decisions about submissions will likewise be extended by two weeks, from August 1 to August 15.)

Designing for User eXperience (DUX) invites submission of longer Studies and briefer Sketches, described on the DUX 2005 website. The downloadable Submission Kit elaborates on details regarding language and format, and provides a template to further guide authors.

We invite you to participate in the premier conference for User Experience practitioners.

Richard Anderson, Brian Blau, John Zapolski
DUX 2005 Conference Chairs

The Chief Experience Officer

A few years ago, a new C-level executive -- the Chief eXperience Officer (CXO) -- began to appear here and there, though mostly in e-business consultancies. I talk about this role on my website (see "Changing the Role 'User Experience' Plays in Your Business"), refering to it as having "responsibility for integrating 'customer experience' into every step of an organization's process." And I quote Challis Hodge's 2001 description of the role:

"The CXO should ensure that an organization delivers the appropriate experience at every point of contact it makes with the public. This CXO must understand the processes, methods, and tools necessary to understand people, and should be able to translate that understanding into successful points of contact with users, customers, shareholders, employees, partners, and visitors. ... In both corporate and professional services positions, the CXO should be responsible for keeping the entire organization focused on the user and the points of contact with the user."

About that time, I proposed a "Rent-a-CXO" business idea to Marc Rettig, former CXO at Hanna Hodge. However, the CXO concept did not gather momentum, and the number of CXOs in business declined with the number of e-business consultancies.

More recently, there has been a rise in the number of Directors and VPs of User Experience, as an increasing number of businesses recognize the important role user experience plays in business success. However, few if any of those roles have the breadth of responsibility envisioned for the CXO. Hence, might the concept of the CXO be largely relegated to a blip in history?

In a March 2005 article entitled "Who Knows the Customer Best?," Jeffrey Rayport writes, "Customer interfaces can either be a strategic advantage or a huge liability—a chief experience officer can ensure it's not the latter."

More from the article:

"Many companies have worked hard to meet customer needs by deploying interfaces wherever consumers or customers want them, whether essential or not. At most companies, this helter-skelter deployment has resulted in a plethora of interfaces—retail points of sale, call centers, interactive voice-response units (VRUs), sales forces and detail people, interactive kiosks, and Web sites, not to mention marketing-communication mixes that range from television and print to events and sponsorships. While managers might question whether all of these elements—especially marketing activities—constitute a company's presentation layer, customers make no distinction. The fact is, every one of these touch points strategically shapes customers' attitudes and behaviors.

In modern companies, who takes responsibility for these disparate interfaces and touch points? Who's accountable for the optimization of interfaces on both a stand-alone and an integrated basis? Who ultimately ensures that the elements of complex corporate systems—technology, marketing, processes, and R&D—create loyalty-inducing experiences for customers? Often the responsibility falls to the CEO, who's best positioned to see across the entire organization but is overburdened with other responsibilities; sometimes it falls to the chief marketing officer, who understands the marketing challenge but misses, or can't influence, the integration across nonmarketing interfaces, such as call centers and Web sites. It may fall to the CIO, who may control the technology but not marketing, sales, or service strategies. Given these barriers, none of these is a good answer.

To ensure desirable customer experiences, companies must appoint dedicated chief experience officers. Call this individual the 'other' CEO—or, as we prefer, the CXO (not to be confused with the commonly used term that refers to any C-level executive). This executive's strategic agenda starts with a line of inquiry regarding the company's presentation layer. In every business that competes on service or relationships, these questions can highlight enormous strategic internal issues, such as operating efficiency, organizational design, and enterprise economics.

The new executive must relentlessly focus on unifying the disparate functions of human resources, marketing, operations, sales, service, and technology. For most companies, such integration suggests an unholy alliance of warring fiefdoms and silos, and that's precisely why the C-suite needs an individual with the power and authority to deliver integrated experiences for customers."

Might the time finally be ripe for the role of the Chief eXperience Officer in business?

"The magical interdisciplinary view"

Planning a project? Figuring out what to do? Gathering requirements?

How do you approach these things?

Scott Berkun, speaker at Tuesday evening's BayCHI meeting, provides some answers in a chapter of his newly published book, "The Art of Project Management."

In it, Scott describes three perspectives that comprise those answers -- business, technology, and customer, and argues that the latter is the most important, though it is the weakest in most organizations.

Scott recommends use of a Venn diagram of these three views to diffuse perspective bias (i.e., to show, for example, that there are "great technological ideas that do not benefit the business or the customer, as well as great ideas to help customers that are not viable for the business or possible with current technology.") Such a diagram "generates respect across perspectives because everyone is forced to realize that they need to collaborate with people who have knowledge they don't possess in order to be successful."

Scott writes, "if no effort is made to bring divergent points of view together, ... planning meetings become battlefields for attacking and defending opinions based on these perspective lines." "Bringing an interdisciplinary view to a project enables you to make choices that cut across the very boundaries that limit your competitors."

Scott argues for "organizing the planning process first around customer research," then problem statements derived from the customer research (i.e., "descriptions of specific end user or customer issues"), then conversions of those problem statements into feature statements or scenarios (i.e., descriptions of things "a customer will be able to do as a result of the project, or the tasks they will no longer have to do"). This ensures that arguments from any perspective will be made within the context of the most important perspective -- that of the customer.

You can download this chapter of Scott's book for free at www.scottberkun.com/books/artofpm.

Partnering with power

In a presentation at CHI 2005, Dennis Wixon emphasized the importance of partnering with power in order to play a strategic role in a business. In a January+February 2005 interactions magazine article entitled, "Ease Your Design Anguish," Deborah Gill-Hesselgrave and Mark Hall stressed the need to "become business partners with the people whose mortgage payments rely on meeting business-performance objectives and incentives."

But how do you do that? How do you go about "partnering with power"?

Partnering with power is rarely solely a matter of walking up and saying, "Hey, partner with me." Plus, it is often the case that those seeking such partnership hold less power, and sometimes, in part because of that, the existing relationship is strained.

In a previous blog entry, I referenced a couple of examples of partnering with power from my work, calling them "perturbing the ecosystem," since they were such a signficant shift from the norm. In those examples, the power consisted largely of ownership of important decisions (e.g., about product strategy, concepts, designs, ...) which those of less power wanted to own or wanted to influence more substantially.

As stated in that previous blog entry, involving those with power in an intensive process of rapid ethnographic research and its analysis/synthesis in certain cases and in an intensive process of rapid iterative design and evaluation in others was key. And they were involved in such a way as to enable them to exercise their ownership, enabling them to directly experience how important user experience should be to shaping those decisions. The ultimate result was an elevation of user experience personnel into a relationship of strategic partnership.

As reflected in the case reported by Dennis Wixon, the business benefits of such a partnership can be phenomenal (see www.mgsuserresearch.com).

Do you still feel undervalued and not strategically positioned where you work? Consider developing a strategy for partnering with power akin to that described above. And if you are among those with such power, consider developing a similar strategy in which (other) user experience personnel can demonstrate the importance of the roles they can play in your decision making process.