交互设计需要什么样的需求
T公司做互联网个人软件的，其WEB相关的产品经理(PM)都很“盲”，网盲的盲。因为这些人大都是刚毕业就找过来的，没有任何经验的毕业生，而且很多都是和互联网专业不相干的，在到公司之前甚至都不了解公司的产品。他们每天背负的任务只有一个——“收入”，很少去研究行业发展和相关产品，更不要提如何做好产品的设计了。
有事实为证：某PM到其他部门同事的座位上讨论产品，看到同事正在使用一个竞争产品，该PM问：“这个是什么？！感觉很不错呀！”。实际上这个竞争产品已经出来很久了，而且在业内较有名气，作为产品经理他们竟然不知道。当设计师仔细告诉这个产品是什么、怎么用、怎么好以后，他们回到座位依然会打电话问“那天你用的那个xxx是什么来着？怎么下载？”。同事晕倒。
他们的PM和UE之间经常这样合作：PM突然想出来一个好的赚钱的点子(或者上头因为“业绩不好”压过来一个任务，他们又想出来了一个“强奸用户”的办法)，什么都没有准备或者只准备了一个“项目说明”，描述”我们想达到什么目的”，然后就直接拿跑去跟UE的同事说：我们有一个新项目，要怎么向用户收钱，你给我们“交互一下”吧…
B公司做互联网社区，他们的PM个个都是“职业网虫”，对于互联网和自身业务理解非常深。这些人大都是从各大互联网社区中挖掘出来的，也有很多是专业非常对口能力很强的高才生。他们没有收入指标只有简单的流量压力，每天在想的事情就是如何为网站创造更大的流量更好的粘度，从而卖掉更多的广告。他们对于产品设计也有自己的理解，但对于界面设计这种他们认为“很无关紧要很容易”的事情向来不屑一顾。
之所以说他们是“职业网虫”是因为他们每天都混迹在中国各大网站上，每天都在不停的关注着业界动态和网站数据，不停的分析和体验着用户的行为。互联网上新出来的东西他们总是第一个先接触，互联网上所有的“意见领袖”他们都很熟悉，他们每个人都有自己的博客，在各大社区上都有自己的马甲…
接下来也说说他们和UE之间典型的工作方式：当要发起一个项目时，PM从来不会和任何其他部门的同事商量，他们只会在自己部门内部讨论并直接形成“结论”，然后他们会成立小组，所有小组成员分工撰写详细的PRD。PRD的详细程度甚至到“界面上的某个按钮应该放在什么位置，应该多大”。等PRD写完之后，回去找UE的同时进行“设计”，并要求每个设计细节必须遵照PRD…
T公司的这种情况造成的后果是：他们的设计师往往很累，项目进行的更累，而且容易出现设计和需求的偏离。
设计师在设计之初都很难真正理解PM的具体需求，PM也没有能力描述清楚需求，导致项目总是在不停的反复。甚至往往由于时间关系，产品设计稍微达到预期就得上线，不能做到本可以达到的更好效果。在这里设计师走着走着成了产品的主导者，最终很容易就发现产品的发展偏离了原始的方向，按照设计师那个不完整理解的构想走了…
B公司的这种情况造成的后果是：对于设计并不擅长的PM在做设计，设计师成了摆设。设计师成了“界面”的制作者，很少能够真正参与到设计。
遇到对于项目要求比较简单的产品还好，最多只是细节设计出现一些比较白痴的问题。等遇到对于设计要求较高的产品时（比如交互要求很强的软件产品），PRD文档的“直线描述方式”不能表达清楚完整的产品设计。由于PM坚持自己主导设计，结果导致设计一团糟，而本可以做好设计的设计师却没有机会参与到其中。项目拖延时间，公司蒙受损失。在这里产品经理成了设计师，一个按钮一个颜色都会产生争执，最终的产品设计不是极其普通就是极其糟糕，更好的设计效果不能出来。甚至陷入到了产品的细节难以自拔…
(以上为两种极端情况的假设，请勿对号入座)
其实这里存在一个最基本的问题：产品经理是应该只给出简单需求，还是应该直接给出设计方案？
我的答案是：两种极端都不行。
angela写“如何了解用户”的时候我们回复说：“其实所有的用户研究最主要的问题就是解决：‘用户需要什么，用户希望要什么’”。同样的道理拿到这里通用：
如果你渴了，希望我帮你解决这个问题。那么不要告诉我“给我来碗稀饭”，这样我没法了解你的真实需求，如果恰巧我没有稀饭，你只好饿着；也不好只告诉我“我渴了”，这样在我有水又有稀饭的时候，可能只会给你一杯水，不便于我直接给出更合理的方案（对于水和稀饭其实你更想要稀饭）；你可以告诉我“我渴了，给我来碗稀饭吧”。如果有稀饭，我会直接给你。如果有水没有稀饭，我会说“我给你来碗水吧。现在没有稀饭”。
如果只给出简单需求，会大大提高沟通的成本，特别是设计师理解需求的成本，往往会造成设计过程的反复。如果直接给出设计方案，势必造成设计师没有发挥的空间，而PM不是专业的设计者（或者说没有时间、或者不应该深度参与到具体设计中）却要主导设计的所有细节，最后造成糟糕的设计成果。
所以，我并不赞成Banlon和子条他们说的：“老妈子就是老妈子，妹子就是妹子，哨子就是哨子”。哨子不只是有必要告诉老妈子今天街上是否热闹有多少客人，还有必要建议老妈子今天让什么样的妹子先出台，什么样的妹子可以在后面等更有钱的主，但只是建议；老妈子也不只是应该把客人分配给妹子，还有必要建议妹子用什么样的方法对付什么样的客人，但只是建议。老妈子不能代替妹子伺候客人。
绕了这么多，其实想说的很简单：
什么人做好什么事，是规矩。但如果什么人只管做好什么事，就是团队最大的忌讳。协作才能真正提高效率。
PM的需求文档不应该只是需求，还应该有粗糙的够“解释需求”的“设计方案”。设计师拿到需求时应该结合PM的“设计方案”去理解需求，这样更快也更直观。但PM的“设计方案”只是为了说明需求的“方案”，对于设计只是建议，不是必须遵循的“方案”。
3月 15th, 2008 at 1:37
T公司的PM真牛气啊，回到座位上居然是打电话问链接，强！
3月 15th, 2008 at 1:49
竟然能沙发~终于看完这篇文章，很赞同作者的想法，不过文章更多的在要求PM对项目的理解和控制，作为设计师，在协作沟通上面是否也应该有主动的一面。
一巴掌拍不响，一个糟糕的项目往往出自很多方面的因素。PM的PRD固然重要，但是我们设计师在做什么？不要一直围绕PRD转，也不要一直读着以前的数据去分析自己的优势，去看看用户在怎么用，竞争对手在怎么运营，之后再回过头来看看自己的产品应该怎么做。
产品的路是靠走出来的，不管是谁，放下手中的电脑，走出去主动沟通吧！
3月 15th, 2008 at 8:09
唉，t公司的现象似乎非常普遍。其实也是很无奈的事情。一开始就没有顺着正确的方向前进，等发现不对的时候，又发现转变要花很多时间。下不了狠心，或者是某种私心不愿意去改，最后只能是“就这么着吧”，问题越积越多，越来越严重，最终有那么一天会爆发。
3月 15th, 2008 at 9:02
PM的这个度的确很难把握,更难得的是团队的协作.
如果上述的两家公司团队合作都一年以上了,我想很多事情就从本来极端向中庸靠拢的.所以作为PM其性格和沟通是非常必要的.
其实PM偶尔请团队里面的人吃吃饭即使AA制都是有意义的.
这两天在看N久前流行的<明朝那些事儿> 书中对于团队的协作写得非常到位.领导知人善任,手下个性羡慕,善于突袭的,善于防御的,善于左翼攻击,善于右翼大压,善于谋略,个个都是英雄,但是他们的性格都在领导的眼里面,那个动荡的年代,领导是都和手下们吃在一起睡在一起的,聊聊家长,说说故事都很容易知道对方是个怎样的人.
PM不仅仅对产品流程各个环节要通晓,更重要的是在于管理,在于团队协作.
很不幸,也很有幸,白鸦凶提到的两个极端我都遇到过,而且身在其中! ^_^
3月 15th, 2008 at 10:09
2个典型的例子，如果，这2个现象同时出现在一个地方，Orz!
相比之下，第一种其实比第二种累多了，毕竟B公司的人似乎更热爱自己的网站。
本着热爱这个前提，很多问题就有解决的余地。
3月 15th, 2008 at 10:48
这个“建议”，定义的很到位。给需求，给线框图是对的，但只是建议，而且有必要建议，否则确实会出现偏差。余世维为什么要讲几个小时的课程来教“如何有效沟通”，因为保持思想一致最重要，而思想一致的桥梁就是沟通，PRD大部分时间就是共同及备案的作用，所以，PM先练好自己的PRD，同时多了解其他职位的工作，才能给出合适的，合理的，合体的PRD。
3月 15th, 2008 at 11:40
什么人做好什么事，是规矩。但如果什么人只管做好什么事，就是团队最大的忌讳。协作才能真正提高效率。
说得好啊~
我现在就在白鸦说的第一中pm底下煎熬~~~
3月 15th, 2008 at 15:24
其实我一直认为，一个项目的PM并不象做技术或其它专业职位，需要具有一些特殊的专业背景，就目前的情况来看，一个PM在项目里的角色和这个PM以前的工作背景和专业背景有很大关系，总是不自觉的流露出PM自己的一些专业特点。一个好的PM应该是全面的，应该可以把一个团队各个工种结合在一起的纽带。
3月 15th, 2008 at 16:21
第二种情况在现实在还是有的,至少我接触到过,也亲身感受到过!
现在往往很多小公司小网站是这样的，不分PM，不分UE，可能两者同是一个人的行业。
还有很多时候时候根本就没有PRD，想到了要做什么就开始做什么，只是看到了类似的案例就把它当成PRD，要求一个星期或者更短的时候内赶出来。结果可想而知！
3月 15th, 2008 at 17:55
~~~~ 深有感触～～～
3月 15th, 2008 at 20:12
其实我的本意也并不完全是责忠于位，只是在你说的B公司中，发现设计师心中有一种关乎存亡的危机感，为了生存，他们也抢着做需求，用自己的短板和别人的长板去丈量，结果可想而知。建议适可而止，不可做的过多，这是我的看法，跟白鸭也是相似的。
3月 15th, 2008 at 23:39
做技术的推荐不要关起门来做技术，
做产品的更不要一味的依靠自己的网感去做设计….
相信部分团队都会有鸦总文中提到这样那样的问题，如何去平衡,PM的确很重要
推荐思域说的<明朝那些事儿> ,
3月 16th, 2008 at 9:04
收藏至20ju.com
3月 16th, 2008 at 22:44
说到PRD,不尽想起曾经看过最好笑的一个改版任务的PRD,内容基本形式就是：无数的老版本界面的截图,搭配上"这个不要删掉"、"这个改为XXX"等文字说明,实在太搞笑了…简直像个教师在改小学生作文…
设计师看了根本不知道为什么要这样做，无从理解改版的意义，更无设计着力点..简直无语…把设计师当成是施工队..
3月 16th, 2008 at 22:49
B+T就是BT呀，看来总有PM要被你骂。
不过我认为，这是一个要逐渐达成的平衡：PM和设计师的能力平衡。
在设计师不懂什么叫交互设计的时候，PM就应该告诉设计师该怎么交互；反之，如果设计师是交互设计的大拿，自然不需要PM过多的去设计。
3月 17th, 2008 at 0:20
楼上不要陷害我! 我说的是两个公司代号而已. 如果是BT的意思,那就先说B公司后说T公司了.
3月 17th, 2008 at 9:43
94smart很有想象力！
3月 17th, 2008 at 10:26
发现Banlon把白鸦写成了白鸭:D
理想的状态，PM和设计师能互相尊重、默契合作
3月 17th, 2008 at 10:49
我是在T公司的PM带领的团队下做着B公司的事情。
3月 17th, 2008 at 12:50
好东西
3月 17th, 2008 at 15:32
不要光说理论，理论很多人都懂。有时配合点例子更具意义。
顶了。
3月 17th, 2008 at 16:17
每个公司的案例都不一样，但是白鸦说的情况已经很有代表性了。最近我们UE组就遇到了这样的问题，老大让我写个规范来。不知道能不能规住这些范。估计，还是要沟通和谐，培养意识吧。路好长啊，走上了UE“事妈”这条路。
3月 18th, 2008 at 8:42
我在T和B混合的公司.
3月 18th, 2008 at 10:35
我所在的公司，PM是偏T型的，但做事方式呢是偏B型的。
但都没有那么极端，对于详细的需求，PM的权利小于RD，RD的权利小于领导。
而“交互设计”在这个环节里，是处于RD角色…和其他真正的RD一样，在需求与实现和交互等问题上协商达到一个尽可能的平衡。
我觉得问题最根本还是在协作互动上…但是，如果有一个经验（对产品、对市场、对协作沟通…）丰富的PM，那么这种问题基本上就可得以解决。
3月 19th, 2008 at 13:28
白鸦(16楼) - 08/03/17 0:20
楼上不要陷害我! 我说的是两个公司代号而已. 如果是BT的意思,那就先说B公司后说T公司了.
比较有趣
我感觉PM给UE什么资料这个不是最重要，UE和设计师理解需求是重要的！
PM做的好不好，重要的是让具体工作的人了解的任务，你采取什么方法是你的本事，你不写文档说两句能搞定也行，具体看你们合作的人具体特点而定。
3月 19th, 2008 at 19:57
大家为什么都挑明自己在什么公司干吗？难道不怕你们的“PM”认出ID吗？
莫非总有一天，PM这个词会成为邪恶的象征？
3月 20th, 2008 at 17:02
形像得很！确实很BT的PM :$
还是不要对号入座的好，也不好指桑骂槐。。哈哈，和谐嘛，就不会像tony说的“PM这个词会成为邪恶的象征”那样了
B司的设计很累很无奈；
T司的设计很闲很悲衰。
3月 21st, 2008 at 17:32
世间万物，不是对就是错。不是左就是右啊。
只有偏执狂才能生存，BT公司是两极严重，却都是做的还不错还赚钱的~~~nnd
3月 22nd, 2008 at 17:57
Seven估计是个地道的老外，对中国文化了解不多~~~
3月 22nd, 2008 at 20:40
tony， 其实楼上这么多回复中seven是最了解T公司和B公司情况的。 身在其中呀…
3月 22nd, 2008 at 23:39
29楼tony是？
3月 23rd, 2008 at 2:10
呵呵，原来这个blog支持重复的用户名。
3月 24th, 2008 at 20:58
总是听到UE的同事“抱怨”PM，有时候就会想，PM到底是怎么产生的？
有得PM同时“负责”着N多个项目 ，而且是跨度很大的项目，其实也提难为PM的有时想来：）
3月 25th, 2008 at 15:28
[…] 二 用户带着目的A来，得到更优方案B。（白鸦和angela都拿吃做过比喻） 我再罗嗦两个例子： A […]
3月 26th, 2008 at 18:01
太理想啊，知易行難，呵呵~
3月 31st, 2008 at 1:48
白鸦兄总是苦口婆心的讲真理。
我喜欢这一篇，顶这篇。
因为这篇结尾有个“总之”：我跳过正文，光看了结尾几句话。时间精力有限，就不看正文了，漏掉那些精彩的例子也没办法。喜欢结尾有“总之”的blog！
4月 2nd, 2008 at 10:40
产品策划、设计、运营之间有一个主脉就是大家需要共同参与，相互理解思路。虽然现在行业的职能分工越来越细，但并不代表各个环节之间没有关系。 产品不能闭门造车，设计不能任意妄为，运营需要卖点，因此不主张所有岗位只关注自己的一亩三分地，只有综合水平提高了，专业水平才能形成突破和质的飞跃。 希望大家有机会多多交流 chinaljian@hotmail.com
4月 15th, 2008 at 16:18
"什么人做好什么事，是规矩。但如果什么人只管做好什么事，就是团队最大的忌讳。协作才能真正提高效率。"
最近刚加入一个新团队，发现这个问题的重要性了。
4月 18th, 2008 at 12:27
白鸦，我很欣赏你的看法，就关于本文讨论的意图而言，我在我的公司是这样的：
我所带领的网站部应该说是起到你上文提到的PM部分职能，
通常网站的新功能或新模式的改进都是由网站部来提供的，而且是直接给出设计原型，
一开始我也想给一个草图简单说明各个部分的功能需求即可，
但可能是我个人偏好，我都是让设计师直接按照我自己的理解去设计，
直到我满意了给技术和业务部门作为靶子来讨论，
实践了几次之后，发觉这种方法很有效率，
一、很多人看到实际的样子，更加准确地、有的放矢地传达了意见，
二、凭借经验，一般的原型需求只有很少的改动，往往大的方向和格局都是正确的。
三、在与技术沟通功能的逻辑关系的时候，能很形象地推理出矛盾，加上可能我个人也喜欢逻辑推敲，
我愿意在考虑前台需求的时候，同时考虑后台是如何衔接的，
所以在设计原型的时候格外注意每个功能的前因后果以及多种操作可能。
我想这种职能的要求和划分也许对未来的这种需求上的矛盾会有所帮助。
4月 18th, 2008 at 15:39
我坐在的情况就比较囧了。。。
公司没有UE部门~基本上我在兼任。
本人是设计师！
而公司的商务部门跟上面的T公司差不多唉。。。。
4月 18th, 2008 at 15:59
项目策划与设计总是存在一定距离。当一个纯粹的策划方案交给设计后，设计是否能做出策划所想的呢？策划是否需要为设计考虑用户体验？
4月 25th, 2008 at 18:01
白鸦说的是普遍现象。其实现实中还真的没有几个公司能够达到理想中的各司其职的状态。人总有强势和弱势之分，观点总是存在差异。要说，腾讯和百度还真算是不错的了……
5月 21st, 2008 at 17:41
交互性很强的软件产品，难道PM就会设计很差么？这点我不是非常同意。因为我本身就是做软件产品，在这个过程中，我们反而觉得交互设计师的逻辑能力没有更有效的突出。如果仅仅针对用户体验方面的，我是比较欣赏他们。
交互设计师在很多公司隶属于用户体验部，而且很多公司倾向于招有设计基础的人员，这样也造成了他们逻辑方面的一些弱势。相反，我们的PM是更能有效的理解以及设计出相应的模型。
对于T公司所招的人，我个人还是认为挑选人才时，需要非常慎重。PM一定要对各种互联网产品非常熟悉，逻辑能力也需要非常强。一个对产品都不关系了解，对基本的操作功能都不熟悉的人，根本就不是合格的PM。
7月 26th, 2008 at 11:16
不错也
7月 26th, 2008 at 11:20
很全面哟
8月 12th, 2008 at 23:56
文章写很好..两个极端得确反应了,现在互联网的某些情况
PRD固然重要,但及时的沟通与交流也不能缺
10月 27th, 2011 at 11:14
[…] 第八章 交互设计做什么 交互设计需要什么样的需求 http://ucdchina.com/blog/?p=408 […]