回到主页

Alan Cooper的愤怒

About Alan Cooper's Anger 

· 新闻

题图: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.

END

所有文章
×

还剩一步!

确认邮件已发至你的邮箱。 请点击邮件中的确认链接,完成订阅。

好的