Wednesday, January 31, 2007

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

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

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

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

Some of those who groan on encountering the topic of SMART goals might be particularly interested in what Robert Middleton has to say about them:
"You've probably read a lot about goal setting. Perhaps you've heard of the famous "S.M.A.R.T." formula - Specific, Measurable, Achievable, Relevant and Time Specific. Well that's OK, but it's not really the best way to set goals.

To set and achieve goals you need to be unreasonable.

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

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

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

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

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

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

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

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

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

Imagine, Think, Opportunities, Commitment, Action: I.T.O.C.A.Now that's a pretty bad acronym compared to S.M.A.R.T., but I promise you it's a better formula for getting what you truly desire."
Robert's full article is entitled "Setting Unreasonable Goals" and is dated January 30, 2007.

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

Friday, January 26, 2007

Frank N. Stein

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

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

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

(The "N" stands for Nigel.)

Wednesday, January 24, 2007

Ownership of the user-customer experience

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

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

The editors of interactions magazine are among those who agree, as I quoted in "Walls":
"...product management doesn't build or design products: their job is to own product vision and strategy (naturally with the other stakeholders' input). Engineers own code development and code quality, with a wide range of specialties (architecture, code design, QA, and release management, to name a few). Product marketers take clear ownership of marketing communications and product campaigns, keeping the pulse of the marketplace, and trying to detect what it will buy. Therefore, it's only logical that human-computer interaction professionals take ownership of the user experience. We are, after all, user experience experts, despite the fact that we depend on other development participants to meet user and business needs."
Another who appears to agree is Cisco's Jim Nieters, who, in a paper to be presented at CHI 2007, describes the role his user experience design focus team must be permitted to play before it is willing to get involved in a project:
“The UXD Focus Team functions as the architect who provides the blueprint for the elements of the product that defines the user experience, and the developers function as the carpenters who deliver to the specifications. If the product team does not agree in advance to these roles, the UCD group does not accept the project.”
However, contrast those perspectives on ownership with the perspective of Jeremy Ashley, VP of Applications User Experience at Oracle:
"A culture of UI entitlement creates an atmosphere where the UI designer will not perform until he or she is given a driving role in the process. ... The valued participant often finds a way to compromise..."
And consider the broader view of Don Norman, which I referenced in my first blog entry ever ("In a business, which organization should own the user experience?") as well as again in "Where should 'User Experience' be positioned in your company?". The latter includes the following words from Don:
"Why should any particular organization own it? The company should own it. ... Who owns user experience at Apple? In part it is Steve Jobs, but in many ways it is the company. Yes, it was Steve Jobs who put in the focus and said 'do it this way, or go away.' But I think a successful company is one where everybody owns the same mission. Out of necessity, we divide ourselves up into discipline groups. But the goal when you are actually doing the work is to somehow forget what discipline group you are in and come together. So in that sense, nobody should own user experience; everybody should own it."
Don's perspective is extended somewhat by Forrester Research, which in a report published just this month states:
“Treat customer experience as a competence, not a function. Delivering great customer experiences isn’t something that a small group of people can do on their own -- everyone in the company needs to be fully engaged in the effort.”
However, consider the following related perspective that implicitly references an important role which perhaps should be owned by "user experience personnel":
"We want to make customer experience everyone's business by making the process of creating experience intuitive and repeatable."
The above words are from Secil Watson, Wells Fargo's SVP of Internet Channel Strategy, and the "we" she refers to is her Customer Experience Research and Design group. As I described earlier this month, her group goes about doing this at Wells Fargo by embedding ethnographic research insights in user-centered design tools for strategic business planning. And this is changing the Wells Fargo culture. As stated by Wells Fargo's Robin Beers and Pamela Whitney:
“The UCD tools enable designers, researchers, and business people to make meaning together and this meaning is co-constructed such that no one functional area holds all, or even most, of the knowledge on a project. The willingness to invite full participation in the research and then release the findings so they can evolve within the organization are key factors that continue to push the Wells Fargo culture to become increasingly customer-centric."
So, are the user experience practitioners who think they should own the user experience wrong? Or are there at least some aspects of the user experience that "user experience personnel" should own? Is ownership advisable in some situations but not in others? What exactly does "ownership" mean?

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

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

Wednesday, January 10, 2007

Developing user-centered tools for strategic business planning

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

I've addressed aspects of this in previous blog entries, as have other bloggers. Among the others are Jess McMullin, whose design maturity continuum describes design activity as evolving in companies from the role of styling to making things work better, to problem solving, and ultimately to problem framing to shape strategy. Another is Luke Wroblewski, who recommends that designers use their design skills "for business visualization":
"The same communication skills that help designers create effective visual and interaction designs for products can also play a significant role elsewhere in the product development process especially during early strategic work. ...

... Especially early on in the product development process, design artifacts are able to create buy-in for a product vision, provide market context, or illuminate data, processes, goals, and the impact of decisions."
Some of what I did as Director of User Research at Studio Archetype during the late 90s was work with Jeff Bauhs and others to design and develop models of user behavior, thinking, and experience that reflected research findings. And we did this to provide user-centered tools to guide decision making about what clients should offer to consumers via the web.

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

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

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

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

The result:
"...a transition from a product- to a more customer-centric culture. This shift was becoming crucial as disconnects in customer experience increasingly arose not within the boundaries of the product and service platforms but in the transition and integration points between different areas..."
By extending the task model with metrics derived from surveys and other sources, Wells Fargo has developed an impressive user-centered strategic toolkit that guides project identification, project prioritization, business case definition, and much more.

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

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

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