Wednesday, December 14, 2005

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.

Friday, December 09, 2005

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.

Thursday, November 03, 2005

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!).

Monday, October 03, 2005


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."

Thursday, September 15, 2005

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 ( 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.)

Tuesday, September 13, 2005

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...

Thursday, August 18, 2005

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, ...

Thursday, August 11, 2005

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?

Wednesday, August 03, 2005

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

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

Tuesday, August 02, 2005

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.)

Wednesday, July 27, 2005

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.)

Tuesday, July 26, 2005

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.)

Friday, July 22, 2005

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.)

Wednesday, July 13, 2005

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?

Wednesday, July 06, 2005

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

Friday, June 03, 2005

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

Friday, May 13, 2005

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?

Thursday, May 12, 2005

"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

Tuesday, May 10, 2005

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

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.

Tuesday, April 26, 2005

Perturbing the ecosystem: Getting UX-related organizations to work together

Twice in this blog, I've referenced the CHI 2005 Development Consortium, which I led earlier this month in Portland, Oregon. In my most recent reference, I described this 2-day workshop as an opportunity to "perturb the ecosystem" -- to significantly increase collaboration among UX-related professional organizations, and to create a hunger and an opportunity for more to happen along the same and similar lines in the future.

Over the intensive two days, leaders of multiple professional organizations examined user experience practitioners' experiences of the organizations and their offerings, why the organizations and their conferences are as they are, ways the organizations and their offerings are changing, alternatives to professional organizations and their offerings, needs of user experience practitioners and of companies that hire them, and ways the organizations could collaborate to meet more of those needs. Participants emerged from the consortium committed to making things happen and very eager to take next steps.

Specific outcomes will be reported in upcoming weeks, primarily via UXnet. However, you can now access an overview of the consortium, as well as position papers submitted by participants prior to the consortium, at

Wednesday, April 20, 2005

"You're Richard Anderson, aren't you?"

"You're Richard Anderson, aren't you?" asked a fellow I didn't recognize at the farmers' market in San Francisco. "I attended alot of the BayCHI programs you ran for many years, and I'd just like to thank you so much for all the work you did. Those programs were really great and had a great impact on me and my thinking and my work."

Though I resigned my position as BayCHI Program Chair two and a half years ago, this type of interaction still occurs quite often, most recently at an eBay party in Portland, Oregon (site of CHI 2005) two weeks ago.

Sometimes the people who approach me in this way, as was true most recently at an Adaptive Path party last month, tell me that they took my full-semester user-centered design course and thought I was a great teacher, and say they are still using lots of what I taught. This is particularly interesting to me, since I last offered the course in the year 2000; hence, these people took my course no less than 5 years ago but sometimes as many as 12 years ago.

That Adaptive Path party -- a delightful throwback to parties of the boom days -- brought me face-to-face with several people who took my course. Not surprisingly, Peter Merholz, one of the principals of Adaptive Path, was there, who has said my course had a major impact on his career path. Lillian Svec was there; Lillian was the first Director of IA at Studio Archetype and Sapient, and later became Director, User Experience at Also there was Rick Bond, who became Manager of Intuit's User Experience group; Alex Wright, who was Director, User Experience at Phoenix-Pop; ...

I saw several former students of mine at the CHI conference as well. For example, Kit Lofgren was there; Kit is still head of Abbott Usability, which is doing some very interesting work, as she described to me during the conference reception. Pradeep Henry was there; Pradeep became very successful in India, where he founded and heads Cognizant's busy and growing India-based usability group, wrote a book on technical communication usability, founded South India CHI, developed the first usability conference series in India, etc. And so on.

I also ran into people who have worked for me in the past. For example, I was delighted to run into Michael Kronthal, whom I hired at Yahoo! and who proceeded to do nothing short of fabulous work there. Via those who have worked for me in companies such as Yahoo! and Sapient, I've been able to have a major impact on the roles user experience and user experience personnel play in those companies, which has been most rewarding to me.

"Look at all the people you've influenced," my girlfriend tells me alot, such as after the scene at the San Francisco farmers' market.

It has been a great pleasure, but there is much more influencing to be done. The DUX conference, UXnet, and the CHI 2005 Development Consortium provide venues via which I'm able to do some of this. But I'm eager to greatly extend the kind of work I've done when working within companies.

Friday, April 15, 2005

DUX 2005 CFP now available

The Call for Participation for the second Designing for User eXperience (DUX) conference is now available at

As for the first DUX conference, four categories of submissions are solicited: design case studies, design research studies, design practice studies, and design sketches. Studies must report on implemented designs and the methods and techniques people have used, specifying what worked, what did not work, and why.

Look over the CFP and start composing your submissions, as the deadline for their receipt is June 15. A submission kit that provides greater detail about acceptable submission format and structure will become available via the website soon.

Note that DUX 2005 is a fabulous opportunity for your company to make it clear that it supports good design for user experience. Look for descriptions of sponsorship opportunities to appear on the website soon as well.

Send your questions or comments to me via, to all three conference chairs (myself, John Zapolski, and Brian Blau) via, or to the program chairs (Nancy Frishberg, Rakhi Rajani, and Clark Dodsworth) via We are planning a somewhat bigger and even better conference than DUX 2003, which was a sellout and a wonderful experience.

Sunday, March 20, 2005

Perturbing the ecosystem via intensive, rapid, cross-disciplinary collaboration

Last month, a group of 40 people comprised largely of "usability practitioners" and open source developers assembled in San Francisco for a "Usability Sprint." For 3 intense days, participants worked in small teams to improve the usability of 6 software development projects. But the larger goal of the sprint, and the reason it was a sprint, was to "perturb the ecosystem" -- to "make the community smarter, not just the individuals" -- to dramatically change open source developers' understanding of usability and the common belief that open source and usability don't mix well, and to create a hunger and an opportunity for more to happen along the same and similar lines in the future. And according to the participants who described the 3-day sprint on the March 8 BayCHI program, all of these goals were met.

In my work at Yahoo! and at Viant, having business, engineering, and user experience (UX) personnel collaborate in rapid ethnographic research and its analysis/synthesis resulted in UX personnel becoming partners in the development of business and product strategy, which was a major change to the ecosystem. This created a hunger and opportunity for more to happen along the same and similar lines elsewhere in both companies.

Also in my work at Yahoo!, having designers, design researchers, users, and sometimes other members of the product team collaborate via intensive, rapid, iterative design and evaluation not only improved design but also improved the relationship between designers and design researchers, and between these UX personnel and product management. This, too, created a hunger and opportunity for more to happen along the same and similar lines elsewhere in the company.

Intensive, rapid, cross-disciplinary collaboration is common in companies known for their ability to innovate effectively, and is somewhat akin to a process used in companies like Landmark Education, which claims to transform people's lives.

In a couple of weeks, I'll be leading a two-day consortium for leaders of multiple UX professional communities focused on meeting the needs of UX professionals and the organizations that serve them. The intent of this somewhat intensive, rapid, cross-disciplinary collaboration is to perturb the ecosystem, resulting in significantly increased and ongoing collaboration among UX-related professional organizations, and ultimately among the professionals they serve.

Tuesday, March 01, 2005

Jef, you will be greatly missed

Jef Raskin -- creator of the Macintosh project at Apple, a much-published writer (e.g., The Humane Interface, Addison-Wesley 2000), consultant, and so much more -- died this past weekend.

Jef was always willing to speak at a BayCHI meeting whenever I asked him to do so, which I did multiple times when I was BayCHI's Program Chair. On one of these occassions, I was given the privilege of interviewing Jef on stage on the topic of "crimes against the human interface." And Jef appeared on the final program of my 12-year, Program Chair stint. During all of his appearances, Jef talked at least abit about his experiences with companies that did not understand the important role of the "human interface" to their business.

Jef was passionate about his work, and was passionate about so much else as well (e.g., building and playing organs, building and flying kites), as was evident when I visited Jef in his home.

I did not know Jef well, but he was a friend and a big supporter of mine. I will miss him.

He will be greatly missed by many.

Tuesday, February 22, 2005

Getting the organizational relationships right

The CHI 2005 website now reveals several details about the conference program, including information about the opening plenary. According the the website, Randy Pausch of Carnegie Mellon University will be opening the conference with a presentation entitled, "Confessions of a Technologist who has worked with Psychologists, Artists, Designers, and Other Creatures who are Strange to Me." And among the points Randy will be emphasizing is that "neither side can be there 'in service of' the other."

Recently, someone I know expressed concern about a new group in his company -- one that is being labeled as a group that provides design services. In this person's view, the group is going to have problems if it is positioned within the company as a service group.

Don Norman spoke of this when I interviewed him on stage at CHI '99 (for the full interview, see Organizational Limits to HCI: A Conversation with Don Norman and Janice Rohn from the May+June 2000 issue of interactions magazine): "An extreme oversimplification that a friend of mine made is that there are two kinds of people in organizations -- there are peers, and there are resources. Resources are like usability consultants -- we go out, and we hire them. We’ll hire a consultant, or we’ll have a little section that does usability and think of it as a service organization. We call upon them when we need them to do their thing, and then we go off and do the important stuff. That’s very different than peers, where a peer is somebody I talk to and discuss my problems with, and who helps to decide upon the course of action. As you get higher and higher in the organization, this becomes more of an issue. The executive staff talks to the executive staff, and they have beneath them all this organization, which are their resources that they deploy. But the big decisions are being made among peers. And it’s really important, to advance in the world, to be thought of as peers."

A design manager in one of my client companies would often say that product management tended to treat user experience personnel solely as "pairs of hands" rather than as "heads." Product concepts would be developed and sometimes pretty thoroughly fleshed out by product management before they would involve the user experience personnel (i.e., interaction designers, graphic designers, user experience researchers, etc.) in the company. Hence, user experience personnel, who believed they needed to be involved in product conceptualization, were often unhappy with the tasks they were limited to, and felt undervalued and not understood. Meanwhile, product management, who just wanted the user experience people to do what they told them to do and when they told them to do it, felt user experience personnel were the source of too much complaining and resistance. This was an unhealthy relationship that needed to be fixed.

What relationships do user experience personnel have with others in your company?

Thursday, February 03, 2005

Serving on a jury / Collaborating on a judgment

Over "the holidays" (late December and into January), I found myself serving on a jury in a court of law here in the United States. Instead of arranging and taking a last-minute trip to Europe to celebrate the new year (as I was thinking of doing and was being encouraged to do), I sat in a jury box watching and listening as opposing sides in a tricky civil case fought to win me over.

I had served as a jury alternate a few years ago, present at the full trial but then not permitted to participate in jury deliberations at the trial's conclusion. On another occasion, I was selected as a jury member, only to watch things end immediately following the prosecution's presentation of opening arguments when the case was settled out of court.

Few people I have asked have ever wanted to serve on this kind of jury, since most have argued that they have better and more profitable things to do. And I've always been troubled by the idea that justice is well-served by placing a critical decision in the hands of 10-12 citizens, most of whom do not want to be involved. (My knowledge of the research of Elizabeth Loftus only strengthened this concern.)

But I've always wanted to participate in a jury's deliberations, to experience directly what that can be like.

So, I got my chance.

Success in the business of "user experience" requires working together -- bringing multiple perspectives to bear on a problem -- collaborating on a judgment. And rarely do participants in this process think it is done particularly well. There are excellent methodologies for doing this well, most of which rely on a good facilitator. But few know of or employ them.

So, just how well might a somewhat randomly selected group of jurors work together, locked in a room, assembled around a table to debate the issues of this tricky case, and guided by a foreman selected from among them?

I was impressed.

Did things go as smoothly as they could have? Not exactly. Jurors often talked over each other, got frustrated and upset, insisted that only their perspective could be right, etc.

Did jurors consider more than the evidence presented in court, contrary to the instructions of the judge? Yes.

Were jurors swayed by an inaccurate understanding of the way memory and remembering works? Of course (see the work of Elizabeth Loftus referenced earlier).

Did irrelevant factors (e.g., a desire to not have to come back the next day) sometimes influence how jurors voted? Yes.

Nevertheless, I was impressed -- greatly. All jurors took their responsibility very seriously. All jurors cared about reaching a just judgment. All jurors made significant contributions to the deliberations. All jurors ultimately seemed to give consideration to the input of the others. And almost all jurors contributed to the facilitation of the process. In the end, all jurors seemed to think very highly of all of their colleagues and that our final judgment was as just as it could be.

Do I think there is a better way to run a collaborative session? Yes.

But on the basis of this experience, I'd be happy to serve on a jury again someday, though preferably not instead of ushering in a new year in Paris.

Wednesday, February 02, 2005

DUX 2005 -- specifically where & when (& who)

In an earlier posting, I announced that the next Designing for User Experiences conference -- DUX 2005 -- would be held in San Francisco (as was DUX 2003) and much later in the year than DUX 2003 (which was held in June).

Indeed, DUX 2005 will be held in San Francisco at Fort Mason Center, a unique cultural and educational center located on San Francisco Bay, from Thursday through Saturday, 3-5 November 2005. Mark your calendars now.

As was DUX 2003, DUX 2005 is being co-developed by three professional associations: ACM SIGCHI, AIGA Experience Design, and ACM SIGGRAPH. The DUX 2005 conference chairs: yours truly (i.e., Richard Anderson), John Zapolski, and Brian Blau (contact all three of us via The DUX 2005 program chairs: Nancy Frishberg, Rakhi Rajani, and Clark Dodsworth.

More info about DUX 2005 will become available during the upcoming weeks. I'll announce the availability of the website and CFP via this blog.

Monday, January 17, 2005

Easy5: India's fifth usability conference

And speaking of offshore user experience research, design, and development...

I used to teach a full-semester (15-week) "user-centered design / usability engineering" workshop via University of California Berkeley Extension. It was a very successful course, one which significantly changed many of the participants' worklives for many years to come.

One of those participants was Pradeep Henry, who after taking the course, returned to India to, among other things, build India's first usability lab, write a textbook on user-centered information design, found and chair CHI South India (India's only chartered SIGCHI chapter), build a usability & design team at Cognizant (which has completed more than 225 offshore user interface evaluation and design projects), and chair India's first five conferences on software usability.

For each of these software usability conferences, Pradeep has asked for my recommendations regarding who to invite to appear as a plenary speaker, and he has followed my recommendations each year, beginning with Susan Wolfe for 2001, then Joe Konstan for 2002, me for 2003 (hey, he had actually asked me to be the plenary speaker for 2001 and then for 2002, so when he failed to ask me for 2003, who else was I going to recommend? ;-), Aaron Marcus for 2004, and Marc Rettig for this year.

This year's conference -- Easy5 -- takes place later this week in Bangalore.

(Pradeep will be a member of the "Outsourcing & Offshoring: Impact on the User Experience" panel I'll be moderating at CHI 2005.)

Outsourcing & Offshoring: Impact on the User Experience

The extent to which product development is outsourced offshore continues to increase, creating considerable controversy.

What is the impact of this on the user experience (UX)? Can UX research and design be done effectively offshore? Should certain types of this work remain onshore? On what do answers to these questions depend?

At CHI 2005 in April, I'll be moderating a panel which will attempt to answer these and related types of questions. Organized by Liam Friedland and Jon Innes, the panel will feature an array of perspectives: from technology startup to large company; from U.S.-based outsourcing and offshoring of all or only select parts of UX research & design, to full-service design and development done entirely offshore.

What are your questions and experiences regarding this topic? Let me know as I begin to prepare for moderating this important panel.