2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Happy New Year.

"The three-legged stool of collaboration"

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

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

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

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

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

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

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

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

Regarding the first of these three elements:

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

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

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

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

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

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

And lastly:

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

But there is more:

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

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

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

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

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

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

Borrowing from the field of child development...

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

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

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

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

Have things not changed in eleven years?

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

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

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

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

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

Easy7

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

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

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

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

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

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

A version of this posting was published in UX Magazine.

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

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

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

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

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

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

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

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

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

What a diverse collection of "propellers"!

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

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

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

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

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

Words (and definitions) matter; however...

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

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

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

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

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

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

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

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

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

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

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

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

Words (and definitions) matter; however...

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

Apparently not just about "Managing User Experience Groups"

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

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

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

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

As stated in the course description, course topics include:

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

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

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

Attending to the entire experience

A couple of months ago during a special tasting in San Francisco to mark the introduction of the Scharffen Berger Chocolate Mocha Freddo to the menu of Peet's Coffee & Tea stores, Jim Reynolds, Roaster Emeritus of Peet's, and John Scharffenberger, co-founder of Scharffen Berger Chocolate Maker, described the importance of removing everything from one's mind that could impact the experience of tasting. But to what extent can one really do so? To what extent is that even desirable?

The special tasting featured multiple pairings of different types of chocolate and different types of coffee. For one pairing, the taste of the coffee washed out the taste of cherry in the chocolate. For other pairings, the taste of one enhanced the taste of the other. Clearly, it was not possible to negate the impact of the taste of one on the taste of the other. Nor was it assumed that you could do so.

The special tasting also featured Jim's and John's descriptions of the origins, history, and benefits of chocolate and coffee and of their chocolate and coffee making process. These guys really know their stuff and made the experience of the evening event a delight.

I was already a big fan of Peet's coffee and of Scharffen Berger chocolate. Many of their offerings simply taste great to me.

However, my experience of Peet's coffee in their cafes has almost always been enhanced by my experience of their staff, the look and feel of the cafe environment, and the community of Peet's devotees. Somewhat similarly though perhaps less extensively, my experience of Scharffen Berger chocolate has been enhanced by my tour of the Scharffen Berger factory a few years ago.

And whenever I taste the products of either company -- separately or now sometimes in combination, I am probably not able to remove from my mind the effects of all of those experiences, including my impressions of Jim and John and other aspects of the delightful experience of that special tasting event. Nor do I expect Jim or John would really want me to do so.

---
Of relevance to this blog entry are the three very different definitions of "user experience" that are presented in a previous blog entry entitled, "Where should 'User Experience' be positioned in your company?" Which of those three definitions is the most appropriate definition for your company?

Changing the course or pace of a large ship

The challenge of building and establishing a corporate user experience function, getting it understood and valued, enabling it to contribute to a business to the extent that it can, etc. can be a big one. As the head of a now large and quite successful corporate user experience organization recently told me, early on (i.e., ~5 years ago when he joined the company as manager of a very small UI group), he felt like he was rowing a small boat to try to change the course of the large ship to which it is attached via a rope.

Interestingly, a director in another very large corporate user experience organization recently invoked a similar metaphor, describing the pace of change he was able to achieve as akin to the pace of an oil tanker rather than a speed boat. However, he was talking about the situation now, not years ago when the organization was in its infancy.

Does this boat metaphor never lose its relevance in the business of user experience?

It has long been argued that changing the role "user experience" plays in a business can take a long time. Back at CHI 96, I led a discussion about what was needed to achieve such change as suggested by several papers presented at the conference. At the top of that list of needs: a considerable amount of time.

How much time?

Well, to reference one example, a DUX 2005 case study entitled, "Creating a User Experience Culture at a Non-Software Company," describes a 5-year process that had its beginnings before that 5-year period and was not yet complete.

Over the years, several scales have been published which demarcate stages companies pass through as their way of addressing user experience (or some aspect thereof) matures. Earlier this year, Jakob Nielsen presented his version of such a scale, accompanied by estimates of the time it takes a company to move from one stage to the next:

• "Stage 1: A company can remain hostile toward usability for decades. Only when a design disaster hits will it be motivated to move ahead.
• Stages 2-4: Companies often spend two to three years in each of these stages. Once it enters stage 2 (usability recognized, but derived from the design team's own opinions), a company typically takes about seven years to reach stage 5 (forming a usability group with a usability manager).
• Stages 5-7: Progress in maturity is considerably slower at the higher levels. A company will often spend six to seven years each in stages 5 and 6, thus requiring about thirteen years to move from stage 5 to stage 7 (integrated user-centered design).
• Stage 8: Few companies have reached this highest level of usability maturity, so it's premature to estimate how long it takes to move from stage 7 to stage 8 (user-driven corporation). In most cases, it's probably twenty years."

Must these things always take so much time? Do companies always have the luxury of taking so long?

In earlier postings, I've referenced cases in which significant change was achieved quite rapidly, and described approaches to contribute to such change. But, as stated simplistically in a paper I co-authored entitled, "Improving the Design of Business and Interactive System Concepts in a Digital Business Consultancy," "old habits die hard." In that consultancy, process and role changes were made in such a way as to become infectious. However, in spite of the enthusiasm, groups tended to return to more familiar ways of working without an adequate system of support for the new ways.

Indeed, much is needed to make such change an ongoing and increasingly effective part of a company's culture.

In addition to a considerable amount of time, needs suggested by the papers I referenced during that 1996 CHI conference discussion included:

• collaboration with others;
• benefit (likely and realized) to all participants;
• high-level organizational committment.

However, there can be numerous obstacles to achieving these three. (See "Organizational obstacles" and "What to do about those organizational obstacles.")

Yet, when such needs are achieved, stable cultural change can be possible; when they are not, ... (See "Making changes to a company's culture.")

A corporate user experience VP I spoke with recently talked about how her medium-sized company's DNA was still akin to that of a start-up. Several other user experience management personnel with whom I've spoken describe their companies as technology-centered through and through.

What is the nature of the culture of the company where you work? Does that nature impact the role user experience plays or can play?

What boat metaphor describes the feeling that you and/or others focused on user experience experience in your place of work?

---
See "Corporate usability maturity: Stages 1-4" (Alertbox, April 24, 2006) and "Corporate usability maturity: Stages 5-8" (Alertbox, May 1, 2006) for Jakob Nielsen's full description of the above-referenced maturity scale. These types of maturity scales have their critics, but they do provide some helpful guidance.

The CHI 96 papers I refered to: Atyeo, M., Sidhu, C., Coyle, G., & Robinson, S. "Working with marketing"; Comstock, E. M. & Duane, W. M. "Embed user values in system architecture: The declaration of system usability"; Gale, S. "A collaborative approach to developing style guides"; Miller, A. "Integrating human factors in customer support systems development using a multi-level organisational approach"; and Sawyer, P., Flanders, A., & Wixon, D. "Making a difference - The impact of inspections." There is lots of good stuff to be found in such older publications.

"The way we work has enormous power"

"The way we work has enormous power," stressed Curtis Carlson during a presentation last week at PARC about a new book he has co-authored entitled, "Innovation: The Five Disciplines for Creating What Customers Want."

According to Curtis, innovation is now the primary means of growth, prosperity, and quality of life. Yet, he claims, remarkably few individuals, teams, and enterprises possess all of the disciplined skills needed to identify and develop opportunities for innovation.

Claiming a need for a new generation of innovation best practices, Curtis identified Doug Engelbart as an exemplar of someone whose very different way of working enabled his achievement of profound innovations.

I had the privilege of interviewing Doug on stage at PARC back in 1996. During that interview, and again just a few months ago when the photo to the left was taken, we talked about the obstacles Doug has experienced getting people to consider new ways of thinking about technology and ways of working. According to Doug, prevailing paradigms prevent serious consideration of alternatives.

One "paradigm" likely to impede consideration of Curtis Carlson's message is the view that "good management kills innovation" -- a commonly-held perspective described on the PARC auditorium stage a couple of years ago. Curtis argues that the opposite is true.

And there are many "paradigms" that impede consideration of some of the ways of working that are particularly conducive to identifying and developing opportunities for innovation.

A new book by Luke Hohmann entitled, "Innovation Games: Creating Breakthrough Products Through Collaborative Play" describes some of those ways of working. "Collaborative play"? (See my blog entry on Effective Collaboration and Fun.) Might there be existing ways of doing things where you work that would impede consideration of engaging in collaborative play?

Are your ways of working particularly conducive to identifying and developing opportunities for innovation?

----
photo courtesy of Eugene Eric Kim and taken at the 3rd anniversary party of Blue Oxen Associates; that is Trace Cohen on the left, Doug in the middle, and me on the right

Managing User Experience Groups (second offering starts in October)

I'm excited about offering Managing User Experience Groups beginning in October, our second offering of this 6-session evening course.

In preparation for the course, I've been interviewing more user experience Managers, Directors, and VPs across a wide range of companies. Plus, we are trying to figure out how to fit everything more tidily into the 6 3-hour sessions which span a six-week period. There is so much to cover!

Common user experience group goals include:

1. get more done;
2. have what is done not be a waste of time, effort, money, …;
3. have group and its members succeed and improve/grow;
4. play a more important role (often/eventually: move earlier in process to play a more strategic role).

In short, the course -- really a "workshop" in many ways -- is intended to help participants achieve these and related goals wherever they work.

As stated in the course description:

"Becoming an effective user experience group manager requires a significant shift from being an individual contributor or managing other types of groups. And thriving as a user experience group manager usually requires addressing significant organizational challenges."

So, if you are in or near the Silicon Valley, and if you:

• presently manage and/or are in the process of building a user experience group;
• may in the future build and/or manage a user experience group;
• lead or manage (in) an organization which includes user experience personnel;
• or (can) impact how user experience personnel work or are managed,

we'd love to have you join us for this second offering of Managing User Experience Groups.

And if you are a Manager, Director, VP, or Chief Officer of user experience (or some subset or variation thereof) anywhere in the world and might be up for a chat, let me know. I'd love to connect with you.

"What do they think 'design' is anyway?"

Sharing some birthday cake with Sara Little Turnbull last year on her birthday, I listened as Sara talked about the instructions she had given to a group in Seattle seeking to design new public trash receptacles. Rising early, donning boots, and accompanying city garbage collectors as they emptied existing trash containers were among the instructions. Observing trash container use by the public, both human and non-human (e.g., birds), were also among the instructions.

Sara has long been a practitioner and proponent of such field research. When she was an editor of House Beautiful magazine during the 1940s and 1950s, she visited as many as 400 homes a year to understand what people valued and considered to be important. And field research has been integral to her subsequent several decades of work as a strategic product design consultant.

Sara's emphasis on such research has influenced many over the years, particularly during her many recent years at Stanford University and including the likes of David Kelley, which impacted practice at what is now IDEO.

As we ate that birthday cake last year, I commented about how many designers still don't see the importance of doing that kind of research.

"I know," replied Sara. "Isn't that amazing! What do they think 'design' is anyway?"

What do YOU -- the reader of this blog -- think "design" is?

Chatting again with Sara less than two weeks ago (when the above photo was taken), we talked more about what could be done to help companies better understand what design is.

----
photograph courtesy of Maureen Hoffmann

The unconference

Recently, I ventured into the trendy world of the "unconference," first attending a BayCHI program about unconferences, then a few days later participating in DCamp, an unconference focused on design and user experience.

Hardcore proponents of unconferences argue that conventional conference sessions are boring and of no value compared with the kinds of interaction among attendees that is usually permitted to occur only between conference sessions. They advocate replacing conventional conferences with "unconferences" during which attendees collectively create a conference agenda filled mostly with sessions during which attendees can participate extensively.

Following a conventional presentation about unconferences, attendees of the BayCHI program were asked to separate into small groups to share and analyze their own stories about "a time in your entire conference going experience when you have felt most alive, most inspired, and most proud." Stories from members of the small group I was in emphasized meaningful connections with others and the great feeling of experiencing that one is a part of a community, themes which resonated with others as among the key benefits of unconferences. But what was interesting was that these themes came mostly from experiences of conventional conference sessions, rather than from what occurred between such sessions.

What was also interesting, though probably only to me, was that three of the six stories shared in my group of six were about experiences for which I had been significantly responsible: 1) DUX 2003, which changed this story teller's career path and even prompted him to move to San Francisco; 2) a BayCHI presentation of June 2000, which changed this second story teller's career path as well; 3) and multiple presentations comprised of on-stage interviews of "user experience" luminaries. I was a Program Chair for DUX 2003, the Program Chair for BayCHI back in 2000, and the person who conducted those on-stage interviews.

So, how did DCamp compare with those kinds of experiences? I enjoyed DCamp, and fully participated, leading a session entitled, "Is 'User Experience' Positioned in the Best Place in Your Company?" (see my previous blog entry), and diving into other sessions, including an improv circle (as captured in the embarrassing photo to the lower right). I even joined in the singing of the DCamp song, the existence for which I had given its composer considerable -- albeit good-natured -- grief. (For a scary experience, you can listen to a recording of that singing that is downloadable from the DCamp wiki. ;-))

There were some stimulating sessions at DCamp, including Luke Hohmann's session on innovation games and Steve Portigal's session on designing for the increasing overlap between cultures and between disciplines. Steve told everyone at the closing of DCamp that he particularly valued the times when meaningful connections with others occurred (see the above reference to this theme as it emerged during the BayCHI exercise), but most of those appeared to have occurred between unconference sessions, as he describes in his blog:

"As with most conferences, the hanging-out is lots of fun. People I've never met before, people I've met once or twice before, people who work with or know others I know, people to suggest books, or share their own stories, or to ask me about myself."

Steve also comments on his experience of the unconference sessions, contrasting them with those of a "more traditional event":

"I think the sessions are a mixed bag; the audience is varied and the presenters can't count on an audience having a certain level of experience with their topic. Every session I was in started off with one topic and wandered more or less into something different, or at least a narrow corner of what was brought to us by the presenter - and that was okay - that was the point.

But that means that only one session made my head spin, the rest were comfortable, a bit provocative, a bit interesting, but not challenging or building new ideas or anything. That's probably a reasonable proportion for a short event, consistent with a more traditional event."

As I suggested earlier, achieving stimulating, meaningful professional connections doesn't require unconference sessions, but it isn't likely to happen during sessions of a conventional conference -- or of an unconference -- unless those sessions are well-designed.

What I'd like to see is the integration of elements of unconferences into DUX 2007, to increase the chances of again achieving the magic experienced by the BayCHI storyteller referenced above, as well as by many others, during DUX 2003.

Where should "User Experience" be positioned in your company?

Last month, the following message from John Armitage (quoted here with his permission) appeared on a popular discussion list:

“My company is examining where in the organization chart the UE team belongs. We are a $1b enterprise software company and the UE team is 12 people and two years old. We started in Engineering, were moved to a staff shared services organization, and recently were moved into Product Management in order to have a greater, more strategic impact. Our role is primarily to work with Program Managers, in Engineering, to write product specs.

Some are suggesting that UE belongs in Engineering, primarily because 'product management should not be writing specs' and 'no other companies have UE in product management'. Only a small 'strategic' UE group would stay in PdM, doing research and standards but no direct specification.

As UE Director, I’m comfortable in PdM. I think we (in PdM, representing product appropriateness, competitiveness, quality) can partner with PgMs (in Engineering, representing efficiency, feasability, schedule, constraints) to leverage each other’s skills to reach a good spec. I worry that being in Engineering will compromise the UE design towards the needs of engineering.

(Where does UE belong?)”

John is just one of many people in a wide variety of companies who have been trying to answer some variation of this kind of question.

Earlier this year, I co-taught a Managing User Experience Groups course via University of California Extension in the Silicon Valley. And one of the many issues we addressed during this course was "where should User Experience groups be positioned?" The positioning of User Experience was considered to be very important to those who took course, many of whom were User Experience group managers. It has certainly been of importance to me when I've managed User Experience groups. And it was considered very important to the many User Experience Managers, Directors, and VPs we interviewed when we were preparing the course.

So, where should "User Experience" be positioned in a company?

The best answer to that question might depend on what "user experience" means in the company. Thus far in this blog entry, "User Experience" has largely been a reference to a group of people that in some way attends to "user experience." But, what is the scope of what the User Experience group attends to?

Without question, the term "user experience" means different things to different people. For example, here is a definition published by Dirk Knemeyer in Dirk's blog about a year ago:

"…user experience is specifically native to digital interactions. That is what defines it: having to do with the holistic quality of digital interactions. …what characterizes user experience, what sets its boundaries as just one component of human experiences, is the fact that it has developed from and is centrally a measure of the digital."

Here is a bit of a broader definition from Don Norman, the person who purportedly coined the term "user experience" several years ago. This is how Don defined the term one of the times I interviewed him on stage (download the full interview, PDF 1.8MB):

"I believe that what's really important to the people who use our products is much more than whether I can use something, whether I can actually click on the right icon, whether I can call up the right command... What's important is the entire experience, from when I first hear about the product to purchasing it, to opening the box, to getting it running, to getting service, to maintaining it, to upgrading it. Everything matters: industrial design, graphics design, instructional design, all the usability, the behavioral design... so, I coined the term 'user experience' some time ago to try to capture all these aspects."

And here is an even broader definition, published in the blog of Peter Merholz about a year ago:

"User experience should not be just about interactive systems -- it's a quality that reflects the sum total of a person's experiences with any product, service, organization. When I walk into a store, I'm having a 'user experience.' When I call an airline to make a reservation, I'm having a 'user experience.' And innumerable elements contribute to affect that quality of experience."

Should the breadth of the definition of the term impact the positioning of "User Experience" in a company?

What does "user experience" mean where you work? Some companies use the term "user experience," when all it really means in that company is "user interface." Some companies use the term "customer experience" instead, which almost guarantees a certain positioning. (See "Is 'user' the best word?" for more about the impact of such word choices.)

What definition of "user experience" would be of greatest benefit where you work?

Something else to consider is how the positioning will affect working relationships. During the CHI 2005 plenary address, Randy Pausch argued that "neither side can be there 'in service of' the other." Don Norman elaborated on this in the interview referenced above:

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

(For more on this, see "Getting the organizational relationships right.")

In the discussion list posting quoted at the start of this blog entry, John Armitage expressed concern about the impact on working relationships of being positioned in Engineering. And he said more (again, quoted with his permission) in a follow-up posting:

“The big question is authority. Engineering is happy to have all the advice they can get, as long as they maintain control over what gets built. My goal is to give my designers the ability to escalate detailed UE issues outside of engineering so that they can be heard and discussed by Product Mgt. If UE reports to engineering this can be prevented.”

But similar things can be said about being positioned elsewhere. For example, the VP of Customer Experience Research & Design at a Fortune 100 company told us about his discomfort with being positioned within Marketing, as paraphrased below:

"There should be a natural tension between Customer Experience (pulling to pure experience, facilitating completion of tasks, etc.) and Marketing (which is about selling and profitability and driving traffic etc.). Since we are positioned in Marketing, we share Marketing's goals, which can be challenging, since Marketing might go for short term gain, which results in long term loss."

Should User Experience stand alone? If standing alone, User Experience can still risk being treated as a resource. But, the above-referenced VP of Customer Experience Research & Design thinks his group should stand alone. And in some companies, it does stand alone.

But for User Experience to stand-alone and not be treated as an optional resource, some have argued that you need a seat at the C-level executive table (see arguments of this nature in "The Chief Experience Officer" and in "Making changes to a company's culture").

A year and a half ago on stage at Stanford University, I asked Don Norman about some of these issues, and here is part of what he said:

"I thought that the product teams at Apple when I was there were very effective. ... Any given product team always had somebody from marketing, always had somebody from the user experience group, always had people from the engineering groups. And there was communication with sales. And in that working group where you had at least these three different (groups represented) -- there was a user experience requirements document, and a marketing requirements document, and an engineering requirements document -- I thought these teams worked really well together. So well that people would forget which part of the team they were, but they were all solving problems."

Don's words are reflected in the diagram at left which he published in his 1998 book, "The Invisible Computer."

Similar diagrams have been published by others, including Scott Berkun in 2005 (see "The magical interdisciplinary view" and below right).

So, should User Experience never be positioned within Marketing or Engineering?

Perhaps the best positioning depends on the nature of the company and might change over time. For example, in another blog entry, I commented on the importance of "partnering with power." In some companies, perhaps the best positioning is in the organization with the most power.

However, what is the ideal positioning to work toward?

In that interview of Don Norman a year and a half ago, I asked Don, "In a business, which organization should own the user experience?" In a blog entry I authored shortly after that event, I reported that Don's answer was pretty much "All of them." Here is more of what he said:

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

(For more on the issue of organizational positioning and user experience ownership, see "Walls.")

What to do about those organizational obstacles

My most recent blog entry included a long, rather intimidating list of organizational obstacles to designs making it into or through the user-centered design (UCD) process.

What can be done about all of those obstacles?

The authors of the quotation with which I began that blog entry answer the question this way:

"These barriers can be overcome if designers broaden their roles and better understand other stakeholders' charters."

and

"Successful collaboration with other disciplines that make up the software development lifecycle is the key to success."

In several blog entries, I've emphasized the importance of such collaboration to overcoming organizational obstacles. But successful collaboration isn't necessarily easy. Indeed, here is one of the obstacles within the long list referenced above:

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

Exactly why can successful collaboration be so challenging? Earlier this year, I asked that question during a session of the Managing User Experience Groups course I co-taught in Silicon Valley. The answers came pouring out very quickly, as they described obstacles to collaboration as experienced where the students worked:

• egos
• not knowing that others are doing the same or related work elsewhere in the company
• different interpretations of the same terms
• language & time zone differences
• hidden agendas
• divergent interests (i.e., little interest in collaborating)
• differing priorities
• unclear work process
• lack of time
• the belief that "the more people involved, the less efficient the process"
• tendencies for people to engage in the same discussions over and over and over when trying to collaborate
• an inability to assess level of participants' understanding of UCD
• discrimination (of many types)
• lack of respect (though sometimes justified)
• conflicts of interest
• territoriality
• some feel threatened by UCD
• in many environments, collaboration is considered to be optional
• some prior negative experience with user experience personnel

As referenced in previous blog entries, successful collaboration often requires:

• skilled facilitation;
• walls (of two types);
• an effective collaboration process;
• a willingness to have fun.

As also referenced in previous blog entries, successful collaboration might require:

• working "middle out";
• clear executive support;
• partnering with power;
• "perturbing the ecosystem".
  

But it can require even more.

Among that "more" (though overlapping with some of what has already been listed): as quoted above, "designers broaden(ing) their roles and better understand(ing) other stakeholders' charters."

-----
The paper quoted above: Kowalski, L., Ashley, J., & Vaughn, M. When Design is Not the Problem -- Better Usability Through Non-Design Means, CHI 2006, Montreal, Canada.

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.