Orange Cone

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

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.