Alan Cooper的憤怒

來自專欄 UXTOOLS用戶體驗設計工具

題圖：Alan Cooper在自家農場滅火

十多天前，Alan Cooper在Medium上更新了一篇文章，首先對目前設計領域泛濫的各種新名詞表示了不滿，隨後對目前設計界普遍採用的Prototype-Test模式進行猛烈的炮轟。然後，文章的評論區就炸開了。

鑒於老爺子在設計領域的至尊地位，這篇文章很快引起了熱烈的反響，截止目前在Medium上已經獲得了近4000個巴掌（Medium沒有用點贊）。年紀大一些的設計師（包括IDEO的設計總監）還是比較客氣地探討，表示很受啟發，自己也有類似的困惑云云；而有些年輕的設計師則毫不客氣地猛懟了回去，還有各種圍觀的，插科打諢的，場面很是熱鬧，頗有意思。

雖然大多數設計師表示贊同Cooper對目前設計模式的批評，但大家拜讀完之後似乎都有覺得這篇文章似乎還沒有講完！我第一次看完後，對前面批評部分還能理解，後面部分看起來還是抓不住老爺子高高在上、飄忽不定的思維火花。

後來我把文章推薦給好友路意（Zine創始人、《深則直人》譯者），他讀完之後做了一個較為完整的概括性總結，供大家參考：

Alan Cooper老爺子應該是對UCD領域的現狀有些不滿，感覺太多人給交互設計粉飾了各種頭銜和術語，而且濫用「原型-測試」方法，把原來應該以用戶為中心的設計，變成了以設計師為中心的設計了。 人們沒有耐心去更多的了解用戶，只希望通過構建一個原型，然後進行快速迭代測試來收集用戶意見，他認為這是有問題的。因為這相當於先給了一個方案讓用戶有所反饋，而這個原型本身就會對用戶的行為產生影響，把用戶帶入了他所稱為的認知幻象的金字塔，大概就是行為心理學裡的確認偏差，有效性偏差，甚至海森伯格的觀察者效應等等。

他認為這樣會毀了UCD這個行業，因為這樣下去，其實是沒有辦法帶給用戶更好的產品的，這些也會在產品上市之後反應出來，而金主們也會逐漸懷疑設計行業的能力。 他寫道：冬天已經到來，只是分布不均。所以，他的目的應該主要是希望呼喚行業可以轉回到認真研究和了解用戶需求，回到他最初倡導的 目標驅動的方向上，理解用戶任務的目標。

總之，這篇文章的TNT當量還是相當可觀，值得一看，不過篇幅較長，大約需要20-30分鐘。另外，由於是在Medium上獨家發布，只能科學上網才能閱讀。如果不能翻牆，我把原文正文附在了下面，不過就看不到熱鬧的評論區。

題圖均摘自Cooper的原文

The Endless Battle

User-centered versus designer-centered

Alan Copper

For the past 25 years, I』ve focused on the process of determining the form and behavior of technology products. A lot of other people do this, too, and we can』t seem to agree on our tools, our process, our objectives, our responsibilities, our titles, or even what to call what we do.

The term I prefer is 「interaction design.」 I wasn』t the first to use it, and I don』t particularly like the term, but it was the best I could find at the time. I』m not sure anybody really likes it, as evidenced by the many practitioners who have invented their own nomenclature, me included.

Welcome to the hellish world of terminology in the tech business.

But I』m not here to talk about terminology. I』m here to talk about the aforementioned 「process of determining the form and behavior of technology products,」 but because of the terminology jungle, I have to lay out some ground rules first.

In 1990, interacting with software was a novel experience for most people and, as we on the inside of the industry well knew, it wasn』t very pleasant. Our users complained. They yelled at us. They told us our products were too complicated, too geeky, too obscure, and too hard to learn. Eventually, we admitted that we had to make our software 「user friendly.」 We tried to imagine a process that could do that and called it 「user-centered.」

But we didn』t actually know how to make software user friendly. We didn』t actually know how to be user-centered.

In academia, at the time, there was an older discipline variously called 「human-computer interaction」 or 「computer-human interaction,」 abbreviated as HCI and CHI respectively. HCI was an analytical process that consisted primarily of testing products already in existence by observing and recording how well real users performed. Eventually, in collaboration with engineers, they found it less expensive to test earlyversions of a product, otherwise known as a prototype, rather than waiting for the final version.

The primary tool of the HCI world was usability testing, wherein a human test subject would be asked to use a product while being silently observed, typically from behind a one-way mirror. Because engineers think about systems so differently than users do, usability tests always surprised the observing HCI pros, and when the engineers watched, they were shocked as well.

Those surprises had kernels of valuable insight, and HCI pros always claimed?—?honestly?—?that they gained tremendous value from them, value that ultimately benefitted the users. I have no doubt that that is true, but I believed then, and still believe today, that prototyping-and-testing is one of the weakest and most expensive interaction design tools you can use. The reason why is simple: it comes after much programming has occurred.

There is nothing generative about prototype-and-test. That is, it isn』t…design. HCI professionals gave engineers advice on how well their code was performing, and offered suggestions for improvement, but little more. It』s inherently post-facto. It』s just a critique of someone else』s design, albeit a rigorous one.

Prototype-and-test didn』t even acknowledge the concept of observing the user before the product had been created, or of generating any design imperatives in advance of engineering. And when, 25 years ago, I proposed that such a thing was possible, HCI professionals unanimously reacted with imperious, incredulous rectitude, 「How can you know what users want?」 They denied outright that such a feat was even possible, let alone desirable. I had many lengthy discussions, debates, and heated arguments with educated men and women on this point, and I never converted a soul.

I had a singular advantage over most of the other players in this game. I had spent the last 15 years writing and inventing software, including lots of prototypes, but I had never been drilled in academia』s prototype-and-test catechism, so I suspected otherwise, and set out to find a generative, user-centered process that could make tech products easy-to-use.

I made so much progress inventing an interaction design methodology, that from the moment I began to the time I published a 550-page (soon to be bestselling) book on the subject was less than five years. Four years after that, I published another one. Both books have had multiple editions, are still in print, and many practitioners credit my writing with creating their career for them.

Not only was prototyping-and-testing not a part of the discipline I created, I specifically called it out as problematic, non-generative, and recommended against it in my books.

The core tenet of all my work on interaction design is based on the simple notion that if you can identify the user, and learn what they are trying to accomplish, and why they want to accomplish it, you have all of the information necessary to generate a good design. And you can do it in advance of any engineering or coding. That』s why I call my approach 「goal-directed.」

Just because goal-directed design is conceptually simple, that doesn』t mean it』s easy.

It』s actually very hard to learn about the inner workings of someone else』s mind. Programming is easy by comparison, as is usability testing, and I suspect that is one reason why prototype-and-test is making such a powerful comeback.

Yes. Sad, but true. After many years licking its wounds on the sidelines, prototype-and-test is in remission and gaining currency around the world. Designers now have more powerful tools to create their own prototypes, and a trendy new name has emerged, 「design thinking.」

Because with this method designers can create their own prototypes, there is a frisson of generative effort, and testing prototypes in front of users seems a lot like being user-centered. Unfortunately, the whole notion of learning about, understanding, and analyzing the user has been reduced to a few platitudes and maybe a poster on the wall. It becomes a designer-centered process instead.

Prototype-and-test is very ego gratifying because it always keeps the designer in command. It puts the emphasis on the designer』s experimentation rather than on the user』s needs. User testing always yields some morsels for improvement, so everyone inside the building feels like a winner. Management likes it because it never rocks the boat. Developers like it because it rarely requires big changes. You can think of prototype-and-test as institutionalized, professional, sanctioned 「faster-horsing.」

Prototyping-and-testing is a very useful pedagogical tool. A student of interaction design needs to learn how human users react to programmed behavior and there is no better hands-on method than writing something interactive and then watching users flail, misinterpret, and curse your work. But just because something is good for training doesn』t mean it』s effective in the real world. Unfortunately, few students today ever learn the lesson that, in the commercial world, the drawbacks of prototyping-and-testing make its use problematic.

When you create a prototype you expose yourself?—?and your users?—?to a myriad of cognitive illusions.

There』s the sunk-cost fallacy, confirmation bias, recency and validity illusions, and countless others. The data you gather from your prototype-and-test is deeply compromised by its very Heisenbergian existence. Test subjects want to please, they want to help. When you give them an artifact, they will riff on it, regardless of its appropriateness.

Hey, I』m not knocking prototyping! I lived off of my prototyping skills for a decade, and the products I made changed the world. For example, back in the 1980s, I wrote a prototype that amazed Bill Gates so much that he bought it, and eventually released it as Visual Basic, one of the most successful programming languages. Prototyping is good for invention. It』s good for communication. It』s good for learning. But it comes at a huge cost.

Without a doubt, the biggest cost is that prototypes are artifacts of code, not design. Modern tools blur the lines somewhat, but not enough to make a difference. Code has different imperatives than design does, and more powerful ones. Design is done for users. Code is done for computers. Doing them at the same time creates a very powerful conflict of interest.

After you』ve done some real user-centered design, then by all means go ahead and prototype your work. Put it in front of users and fine-tune it based on their reactions.

But every single person or organization that I』ve seen do this always uses it as an excuse to shorten, reduce, deemphasize, and eliminate the user-centered design phase.

I』m currently judging a major design contest, reviewing over 90 entries by top designers and companies. Only a couple of them used interaction design. Almost all of them used some variant of prototype-and-test. Their solutions are attractive and clever, but are they good for the user? How can they even answer that question when they don』t even know who the user is? Few of the submissions even bother to mention the user.

The rock-solid core of interaction design is the user, not the designer. Fans of prototype-and-test need to study human cognition as hard as they study composition, color theory, or information architecture. Read Kahneman』s Thinking Fast and Slow, or any of Dan Ariely』s books. The smallest word or gesture can change the user』s response.

nteraction design is a lot harder than most practitioners imagine because it asks bigger questions, and it asks them before artifacts exist.

Our field』s endless quest for a title is partly due to the widespread misunderstanding of what we do for a living. Do we execute the boss』 vision, or do we advocate for the user』s goals? UXers are the kind of people who want to make others happy, and we』ve been willing to change the name of what we do to please others, but a side-effect of changing how we call ourselves is that we change how we behave. It』s easy to make your boss happy at the expense of the user.

I don』t care what name you call it, I mind how you do it. Today, most practitioners don』t call themselves interaction designers, preferring the term 「user experience designer.」 But waddaya know, when few name it, few do it. Putting a UX designer in an interaction designer』s role gets you…something else. Sure, I sometimes call myself an 「experience designer」 because, like, I want to be cool. But I』m an interaction designer. That』s because my work is primarily about the user, and only secondarily about me and my ideas.

Doing real interaction design means subordinating your clever inventiveness to the needs of your user.

Knowing your user isn』t hard, but it demands that you let go of your bright ideas first. It』s not about your solutionizing but about your attentiveness. That』s hard. And special. And rare.

I』m disappointed to see interaction design fading from the world. The magnitude of the loss won』t be fully understood for another decade. In tech, the zeitgeist swings like a pendulum between diversity and consolidation. We had diversity with interaction design, now we have consolidation with prototype-and-test. Safer. Business always grows and flourishes in times of consolidation. Users always benefit in times of diversity.

So, practitioners do 「design thinking,」 or 「user experience,」 or 「product design,」 or 「service design,」 or 「product strategy,」 but not user-centered interaction design. The word soup just reflects how we have let our mission and our effectiveness drain away. It creates hidey holes for weak performers. It delivers cleverness and coolness and flashy demos, but it probably won』t deliver satisfied users. When that happens, the bean counters will get wise, and they will call an end to the party. There will be resentment and anger. The money people will close the spigot. To paraphrase a popular TV show, backlash is coming.

Winter is here. It』s just unevenly distributed.

This screed originated in a lengthy Twitter-rant I did a few weeks ago that was favorably regarded. I wasn』t sure I should post it here, and I』m still not sure it』s a good idea. I suspect I』ll just come off as a grumpy old man telling kids to get off my lawn. But I think excessive money in the tech world has compelled people to abandon their youthful, altruistic notions of helping the world with better software design. Now they just want to create products that make the most money in the short term. We have to change that.

全文完