Book REPORT:Subject To Change

曹竹

Sooner or later, every developer out there gets sick of the long hours, the process, the verification and the deadlines. Most developers end up in development management, which ends up being more about estimates and balancing resources rather than product management. This book points out a way out of this situation.

Chapter 1 lays out the foundation of the argument, which is that customers aren't attracted to features; they're attracted to an experience. It is critical to look at what your customer is actually trying to accomplish, and to make the experience of accomplishing that task as positive as possible. Accumulating feature after feature is good only if the original intended task experience is not compromised, otherwise it simply adds noise to what should be an elegant experience.

Chapter 2 presents the idea that the experience is a strategic decision, and then defines what that does and does not mean. It provides a long list of clarifications given the context. Quite frankly, the whole thing reads like an article that slowly abolishes many lessons learned in academic marketing classes. My favorite one is the ideal of Parity - the misconception that a product can be competitive simply by matching features with the competition.

When your focus is on the experience and the user's motivations, you can no longer assume that the consumer is people who exist just to give you money, but instead have to give that person an objective, a background and etc. You will no longer transfer your message for a particular group, but will instead approach individuals to discover how you can best meet their needs and improve their experience.

Yet none of this can be accomplished without information, which is usually garnered by research. Interestingly enough, the book does not necessarily go into individual research methods, but focuses more on the importance of qualitative over quantitative research and the need to involve every team member. Research, as is stated, too often happens in a strategy or research group independent of the team that will actually implement their findings, and thus the opportunity for consumer empathy is lost within minutes of the PowerPoint presentation. It is only by keeping everyone involved that information gained is relevant and provides durable insight.

Chapter 5 comes back to the beginning, and really drives the idea that success is not driven by features, capabilities or marketing, but by the experience of the customer. It's not just the experience of completing a specific task that is meant here, but the entire support system relating to that task. You might have an iPod, but without an iTunes all you have is a pretty piece of plastic. Find out what the customer wants to accomplish, figure out what it'll take to perform all steps of that, and build a system to do so.

Chapter 6 continues on and talks about the actual implementation strategies. Design is picked apart by discipline, target, competency, strategic importance and implementation, and the chapter itself does a remarkable job breaking down common misconceptions. Design is necessary, strategic, and is presented as a belief rather than a discipline, one that everyone must implement to properly contribute to the delivery.

Chapter 7 then goes into the implementation by speaking about agile development methods. Agile is presented within a strategic context rather than a reactive context. Too often when management hears "Agile Development" the first thing that comes to mind is "Development will be faster", or more responsive, and in many cases this is true. Even so, the book presents it as an integral part of experience based design, and discusses how its rapid nature can be used to convert a design iteratively into a fully functioning application, while allowing user experience evaluation at every step of the way.

And with that, Chapter 8 closes the book. It is the conclusion and summary of the entire book. The only thing certain is change, and here's how you deal with it.