Back in December I mentioned that I have been writing a chapter for Andrew Sears and Julie Jacko's Human Computer Interaction Handbook. This is a pretty monumental volume and it's an honor to write for it. They gave me a pretty broad mandate for the chapter: they asked me to write about the relationship between HCI and the customer experience. Before I could write that, I decided to unpack what "the customer experience" meant, and the more I thought about it, the more I realized that what I wanted to do was to more precisely define what "user experience" means. Now I know this is folly--as a term in wide use, user experience has about 1000 different definitions--but I wanted to have one of my own, at least for the duration of this chapter. The definition I came up with is that, in a nutshell, the user experience of a product is everything that's not human-computer interaction. It's everything that affects how someone interacts with a tool--whether it's software, hardware, a service, or whatever. To me, this meant that I had to deal with all of the squishy, abstract things that good cognitive psychology and computer science-trained designers like me try not to deal with: business goals, emotions, relationships, branding, etc.
This is a big problem, and one where I'm only beginning to put the pieces together, but I decided to write down everything I had been thinking and see what happened. Well, what happened is that I wrote the most wide-ranging book chapter I think I've ever produced. That may or may not be good, but I do try to cover everything from familiar territory about focus groups and Jesse's elements diagram to identifying organizational goals, talking about the rise of field oberservation (whether you want to call it "ethnography" or something else), to emotion and brand...all the way to managing with agile user experience development. It's either a jambalaya or a patchwork. I can't tell and Andrew and Julie have been gracious enough to let the chapter stand as it is.
It's probably the closest I'm going to come to writing a sequel to my book for a while and I'm glad to have had the opportunity to have explored these ideas.
I've put a draft (550K PDF) of it up. This is not the final draft, as I'd like to encourage people to buy the book when it comes out, but I wanted to share it because I'd like to get some feedback and because, well, because I'm excited to have done it.
Wow, and thank you so much! I think I agree with you on most your points, I may have just not made myself clear in the chapter.
I agree that the relationships between customers and organizations are more complex and there are many more touchpoints than I've outlined. Defining them would take a whole book, or several. My goal for this chapter was to underscore for the book's audiences-- academics, designers and students--the intertwined relationship between designing human computer interactions and making products for organizations.
I don't think we're in disagreement about fieldwork. Implicit in my description, and maybe I need to make this clearer in the chapter, is that part of the process of understanding the customer is understanding their relationships with others. I'm not trying to suggest that only observing how people physically perform tasks is sufficient. It's not. Economic (and, some would argue, power) relationships are a huge, often implicit, part of any task. It's important to know what those relationships are when designing a way to support those relationships in the context of trying to sell a product which enables that support. (if that sentence makes any sense ;-)
I also completely agree that stated organizational and stakeholder goals are often at odds with actual long-term needs. Often, as an outsider to an organization, it's easier to see this. As a consultant, when I identify such mismatches, I try to talk companies and individuals in them into re-examining their goals. Unfortunately, that's something that not all people or organizations can do, or do well. Often, we have to work with the goals they have. Knowing those can adjust the goals for a product so that it satisfies someone, and it puts the role of running the business in the hands of the management, whose job it is. That doesn't mean that it's going to perfectly serve the real needs of the organization, but starting by working with an organization's stated desires is better, I feel, than working from neither stated goals or real needs. You gotta start somewhere, and you gotta trust your client to make the big decisions about their company.
Thank you, again, for your thoughtful and insightful comments.
Well I have read it through once and will a few more times in order to properly digest the information properly. There is something missing you are there and yet you aren't.
Your definition for customer experience is almost but not quite there. Mostly because of assumptions made about general industry standards and existing business standards as they relate to marketing, branding and PR. However, this is from a large organization perspective not small to medium. In either case the customer experience has much wider implications and interactions both direct and indirect. Relationships between a given business and or product and the customer have a much wider perception than those you have entreated. Your concept of initial or perceived benefit is driven by marketing and branding. This is in hope that a trust bridge will be established between the customers and the actual buy in to the product. When this perceived experience is less than expected the customer experience is ended prematurely and dissatisfaction instead of loyalty is input into the experience and customers will not only become a negative advocate but more likely than not abandon support relationships and future upgrades as well.
There are many customer experiences outside the realm of the sales mechanisms addressed through branding, sales, marketing, etc that you have introduced. Touchpoints in the new context of customer experience goes beyond boundaries of business relationships you have addressed as well. They are both direct and indirect. All are manageable either reactively or in a proactive event. In any case your perspective is to narrow and it affects the direction of the paper and its assumptions.
Also your focus is almost all on existing users as opposed to perspective user (customer) or refers primarily to large institutional development which is very different than small app development for small and medium size businesses as well as the observational dialogues.
There's not enough room here to really detail much. I agree with the need to do field observation as compared to other testing and measuring of user input but the over all methodology is wrong, at lest from a business perspective. I have used this type of observation for a number of years and have moved away from the developer/designer centric view to that of business operational view. Focusing on user experiences in all business processes from the business operational perspective then applying designer developer skills to develop the app to meet the needs of the client to support business processes not to change them. Your methodology focuses on using designer/developer approach is in conflict with the actual user experience from the customer side. At least as I understand it. This is reflected in suggested questions and check list. This is a very designer perspective not that of the end user (customer). You need to observe not only the process, but why they do what they do and the business relationships between each function or the user relationships between each function.
Your Idea of company goals = needs is a bit off as well. Goals more often than not are at odds with real needs. Perceived need yes, but if development follows that direction it will not satisfy the customer and leave them with either abandoning the project, or finding another vendor to fix it or they will have high levels of dissatisfaction and low customer loyalty if any. There is a mess of examples out there to substantiate this. I believe your right on the political structures of business and their affect.
Stake holders are another issue. There is no way to understand stake holder buy in until you do an in depth observation study of the users and the business processes. From a developers/designers perspective as you have outlined the stake holders will be different with different buy in. As far as stock holders as a stake holder are concerned, not really. Maybe on paper and theory they are, but in actual real world not. They are very removed from the process and customer experience. The goals and needs for the customer have to come first in order to have user buy in. The Customer experience needs to be primary. If this happens then financial returns will follow with greater velocity, any way just some main points.
Customers drive competition, innovation and development, not the business. In this perspective the customer need and associated experiences need to be addressed first. Your example of TiVo is a good example of this. Innovation was their, but customer need wasn’t. Those who praised it were developer/designers that were perceived by the market norm as techy, and those who initially used the product and testified of its virtues were also techy outside the main identity niche intended for the product. The intended customer had no need for it and so competition and development were not driven. Only when a perceived need was established with the intended customer niche did this take place even if in a still somewhat conservative manner. In fact if I remember correctly they had to re-establish their market focus with a smaller intended target market in order to get a reasonable response. Hey Customers rule.
If your interested in a dialogue I'll be happy to add my perspective if you are interested. Keep up the good work. Whether I agree or not it is well written.
http://cdccustomerservice.blogspot.com