管理者不应直接参与产品的开发与设计
小型团队有着大公司、大团队不可比拟的优势，沟通成本降低、效率大幅提高，并且往往小型团队的设计师能更早、更完整的参与到产品的生命周期中去。
小型团队，能者多劳，但是最大的问题是：具有一票否决权的管理者（往往是创始人）直接参与产品的开发与设计。
管理学上有一种叫做家长式管理的方法，在创业初期比较有效。所以小型团队的管理者往往会直接参与产品的开发与设计。但是所谓家长式管理绝不能套用到程序和设计上来。所谓：将在外，军令有所不受。君非吾，焉知呼！
管理思想家Henry Mintzberg把管理者比作杂技演员，同时丢着四五个球，实际手里抓住的只有一两个，且抓的时间还不长。如果管理者从头到尾直接参与了产品的开发和设计，那么要么这个产品很容易偏离用户的需求、要么产品后期运营会有问题，一个人难以平衡商业、技术和设计（Keeley 的三角品质模型），这需要一个团队。
作为公司的管理者，如果干扰和侵犯了程序员、设计师的工作，那么这位管理者应当亲自写程序或者设计，然后另外雇佣一位职业经理人。
为什么会这样？
管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。不然估计程序员也会起来抗议。为什么？因为他们对于设计的一知半解。如果一点都不了解，那倒也罢了。问题是设计相对于程序来说，更容易让人觉得自己很懂。人的审美观与生俱来，但管理者对于设计的了解，往往局限于视觉设计的皮毛，更谈不上交互设计。有时交互设计师并不能给出严格意义上的数据证明，其交互设计方案就因为个人喜好（比如因为配色的问题）被一票否决掉了。
要让管理者、领导者看懂产品早期的交互设计原型是非常困难的。管理者往往喜欢看到带有视觉设计的原型后（这个时候产品往往已经成型，就像地基都打好了），再毫无理由的投出自己的一票否决权。
设计团队必须为产品质量负责
产生上述问题的根本原因是管理者觉得所有的责任（风险）都将会由他承担。一个设计师承担的责任在管理者眼里微不足道。这是出于对自己以外的人的不信任。但是我们都应当明白，团队中的任何一个人都相应的有一定的责任和权力。
在现在这个设计师不被重视的大环境下，设计师应当勇于承担自己的责任。既然是设计师设计了产品的交互、外观，设计师不为这些负责不是很奇怪的事么？与责任相对应的，是权力。既然设计师需要为这些负责，那么设计师就有权力保证开发人员 100% 实现了界面。如 Alan Cooper 在《交互设计之路》中所说，“交互设计师应该为产品质量负最终责任，应该让交互设计师决定程序的内容和行为。交互设计师应该是用户的代言人，应该有权利控制产品的所有外部特征。”
时间先后并不代表工作的重要性，或者谁控制谁
因为上面 Alan Cooper 说到应该让交互设计师决定程序的内容和行为，所以我还想提一下，时间的先后并不代表工作的重要。设计师不要沾沾自喜，这只是说交互设计应该放到程序设计之前进行，用交互设计原型提高代码编写的准确性和效率。而流程上的先后，也不表明设计师的工作比程序员重要或者是设计师在控制程序员。建筑设计图纸很重要，钢筋水泥也很重要，室内外装璜同样也很重要。
最后，其他
刘邦曾说“夫运筹策帷帐之中，决胜于千里之外，吾不如子房。镇国家，抚百姓，给馈饟，不绝粮道，吾不如萧何。连百万之军，战必胜，攻必取，吾不如韩信。此三者，皆人杰也，吾能用之，此吾所以取天下也。”良好的沟通是流程的基础，而沟通的基础则是信任。当管理者认识到各个职位承担的责任和拥有的权力，并且信任设计师，那么就不会有那么多问题了。
3月 22nd, 2007 at 8:38
深有同感，可现实工作中痛苦的并不止于此，例如：产品策划人员压根就不懂任何技术，且只对管理者负责，这种情况该如何解决呢？是个问题，思考中…
3月 22nd, 2007 at 9:09
呵呵，其实中间还有个沟通的环节，就看如何把握了！
3月 22nd, 2007 at 11:46
我那老板就是这号人物 啥都乱掺和 烦死人 急了我都想揍他。
3月 22nd, 2007 at 12:12
这是一种信任问题,我的感觉,在互联网公司里面,产品设计实在太重要了,直接关系到产品的成败,管理人员的成败,甚至企业的成败……在理解的基础上多沟通,产品设计团队也不可以一意孤行,就觉得自己才是正确的也不全对. 事实上创业者的有些直觉和经验,对产品的改进和主要方向还是会有积极影响的……说到这,就归结到上面网友waitu的话了.
3月 22nd, 2007 at 12:25
产品经理创业后就不能做产品经理的工作了吗？是谢尔盖·布林还是拉里·佩奇把自己定位成产品经理来着？
3月 22nd, 2007 at 12:47
管理者提出大体的概念，而设计和开发人员负责具体产品的呈现。
3月 22nd, 2007 at 14:11
你说的没错，在带有视觉设计的产品中，管理者都是带着个人眼光来看待的。当产品加入视觉设计后，产品就非常具有倾向性，观众很容易用个人好恶来评判，更忽略了产品内在的东西。所以作为设计师，一般都会全面和管理者沟通，了解他们的好恶，再在下一步的设计中加入自己的想法。
3月 22nd, 2007 at 14:56
@Yoyo
有一篇文章推荐阅读一下：Don't make the Demo look Done
@ApemanChen
产品经理也有产品经理自己的职责和权力
@waitu
对，沟通的基础是给予信任。比如团队的新成员总是不被信任，又急于想得到信任。这时候产品往往会走形 :P
@duhu
这样的产品经理属于没有管理能力也没有专业能力的人，应当趁早换。或者先学会怎么当产品经理。
3月 22nd, 2007 at 17:32
我目前所在的公司就存在这个问题，老总对产品、设计师、开发人员完全不信任，常常以自己的喜好随意改变需求和给一些非专业的意见，导致开发效率严重降低，虽然说他也可以算是一个用户，但我们产品、设计师、开发等也都是用户，是否应该系统的分析后才做决定呢。
3月 23rd, 2007 at 0:28
[…] 管理者不应直接参与产品的开发与设计 - 以用户为中心的设计 […]
3月 23rd, 2007 at 9:39
这种现实就是社会性的病根，短期内可能无法解决。权力设计、权力审美是中国企业管理中关于权利实践性的问题，管理者对权利的理解很大程度就是自我为中心，我才是最牛比的，传统封建君主般的现代企业管理。当然这不是指现存的所有企业，但是大多数就是如此
3月 23rd, 2007 at 9:45
呵呵，在很多人看来，信任一个专家比让自己成为专家要难的多….
3月 23rd, 2007 at 10:17
指出了这个行业中遇到最多，也最让我们头疼的问题。确实，沟通过程应该给予更多的信任作为管理者，更多的应该从客观上看待问题，而不是从个人喜好上面，我就曾经遇到过一个产品经理对手下设计师的设计稿一直不满意，以致到最后干脆问下属要了设计源文件，自己做起设计来，这个项目最后的结果可想而知。
3月 23rd, 2007 at 11:03
产品方面代表用户的利益，国际4A广告公司的大牌设计师也不会不顾客户的意见，自己埋头搞设计。互联网的设计从来都是不入流的，只是刚刚起步，大部分设计师都是半路出家的和尚。就把自己当成专家了。做设计的最牛的人，都是善于倾听的，善于沟通的。设计不是艺术创作，他是一个满足他人需求的创作过程，是带着锁链在跳舞。
3月 23rd, 2007 at 12:02
其实往往实在狠的时候我想说： 实在不行设计师干脆不要去给别人当“制作”了， 教会他们用PHOTOSHOP算了， …
3月 23rd, 2007 at 14:56
Yiya: 客户和用户不是同一个概念；客户不代表用户。
3月 23rd, 2007 at 15:27
Yiya: 我觉得设计师不能认为自己是带着枷锁跳舞。没错，这句话很酷，但是酷并不能证明这句话的对错。我觉得这种想法很消极很阴暗，对团队、对产品、对用户是不利的。满足他人需求的创作，同时也在满足自己的某种欲望，即创造符合用户需求和期望的产品。设计师应当开放自己的心态，你也说的，应该善于倾听（用户）和善于（和领导者）沟通。所谓的枷锁，来自于 PM 的压力、管理者的压力，用户的需求不是枷锁。
但是，PM 或者管理者不总是错的，设计师也不能盲目自大，要理性。
3月 23rd, 2007 at 19:01
[…] 管理者不应直接参与产品的开发与设计 […]
3月 23rd, 2007 at 22:10
仔细想想, Junchen的这个主题有一个公司规模大小的条件界定, 如果是创业型公司, 管理者往往也是开放团队中的成员之一. 而且这里还有一个参与形式的问题, 一般来说, 决策权往往还是在管理者一边, 开发中的歧异有时也会是因为管理者没有很好传达商业策略或用户目标, 也可能是设计师没有很好理解和执行. 所以Yiya提到的倾听也包括设计师对管理者的需求倾听. 文中最后一段真可谓经典了. 只是补充一点, 信任的基础是理解.
3月 23rd, 2007 at 22:30
Moond: 是的。我是觉得本文遗漏了规模大小的问题，而且提出现象后并没有很好的提出解决方案，还缺少对各种情况的分析。但是如果全写出来的话，估计篇幅很长而且牵扯到很多管理学方面的内容，更理论化。对，倾听包括对管理者的需求倾听，比如设计师也需要阅读 MRD？
3月 26th, 2007 at 11:26
很有感触，我觉得还是对于员工的不信任问题。对于干涉设计师，设计人员设计的管理者，往往觉得自己的东西不行！就像我吧，我只是个做网站设计的，小公司，小场面。所以老板很喜欢来跟我讨论这个地方那个地方的设计怎么样怎么样，而且往往喜欢把我的东西拿给他所谓的某某高手去做评价或者建议，然后再来让我改这改那。心想，如果你觉得我不咋地，你觉得他咋地，你请他来做事咯。而且工作环境对我有着极大的影响力，因为是小公司，底盘有限的而被安排在老板背后的位置上工作，注意，不是隔间，而是全开放。Orz。
3月 26th, 2007 at 11:56
Evan，我觉得你的老板太过于关心外观呈现，有些时候你应该旁敲侧击一下。有很多更重要的事情等他处理，何必在个人喜好这件事上如此较真呢？
3月 26th, 2007 at 14:43
Evan同学，这种老板太多了，我们都叫他总理。
好管事、不放心、多疑，明朝最后一个皇帝崇祯就是这么死的。
3月 26th, 2007 at 15:55
发觉这个网站在myie上输入文字有bug，只能改用ie。evan,其实很多boss或领导也不是很有时间来评头论足你的作品，不过他们不说些什么就体现不出他们的水平。。。有些人就是有这样的心理。如果你用专业的角度去问他，他们又会模棱两可的回答你一些不着边际的答案。只能54他们
3月 26th, 2007 at 17:34
fung: 从某种角度说，产品并不是设计师的作品。 // myie 的问题可能和 TinyMCE 有关，目前我们正在寻找更好更合适的编辑器 :)
3月 27th, 2007 at 11:39
管理者参考产品的开发与设计的确有问题。我觉得管理者如果注意参与的方式和涉入的深度对开发与设计应该也有一定的帮助。但要把握一点，管理者就是管理者，不应该否决设计和开发人员的观点，如果有疑问，可以让设计和开发进行说明和论证，或去咨询其他的设计和开发，这也是管理者应该做的。管理者应该尊重设计和开发在项目中的地位！
3月 27th, 2007 at 16:29
我们假设文中的命题是对的。那么有个问题，谁来告诉管理者应该怎么做？通过什么渠道？
3月 27th, 2007 at 16:30
PS：为什么回复成功之后会跳转到文章开头？
3月 27th, 2007 at 17:38
xinxin83: 管理者不需要知道设计具体是怎么回事，有设计师就可以了。就像管理者不需要知道怎么部署服务器一样。管理者有其他很多很重要的事等着他去做。
//回复之后跳转到所发评论是个好建议，WP的程序有一些奇怪的设定，特别是后台。我们会逐渐的完善WP这个系统 :)
3月 28th, 2007 at 11:53
管理者是在抛很多球。在企业利润永远是第一的！ROI才是boss关心的。
3月 28th, 2007 at 15:42
toten: 针对产品的用户体验设计并不与企业利润冲突。举个景点的啤酒和尿布的例子，其实大家可能不知道，在发现啤酒和尿布存在关联后，沃尔玛并没有立即采取将这两者放在一起，而是内部进行了激烈的讨论。一种观点是：将啤酒和尿布放在比较接近的位置（用户体验）。另一种观点是：将啤酒和尿布相隔一定的距离，这样用户在买这两样的时候会浏览更多的商品（商业利益）。最终沃尔玛采取了第一种方案，而这个案例也为 IBM、HP 等大公司所传颂。
3月 31st, 2007 at 13:36
法西斯管理…受够了；完全无法交流~且这样的公司发展前景一般也很差，他们有他们一套的领导班子，上升空间极低。还是早闪为妙。
4月 4th, 2007 at 15:13
想有一个比你欣赏水平还高的老板？想有一个能够把设计完全完全的交到你手里的老板？似乎很难。总算以后我在扮演老板或者决策者的角色的时候，都不一定会让设计师满意。
4月 5th, 2007 at 21:20
设计师把自己的心态摆好最重要，老板考虑的方面会相对全面一点。不干预设计，apple能做出那么好看的东西来么？呵呵如果设计师的出发点正确，我想明白事理的老板都会支持的。
4月 6th, 2007 at 10:16
Steve Jobs，他学过书法，知道衬线字体和无衬线字体的区别、行距、Kerning，我相信他都知道如何制作一款字体。对文化、情感、时尚的把握，他超越了很多专业设计师。
如果说老板（对产品的设计）考虑的更全面，那么说明前期的沟通存在问题。设计一款产品，领导者有义务说出自己的计划和忧虑。
其实我写本文的目的，第一是想让管理者清晰的认识到自己的强项和责任，第二是让设计师认识到自己的责任和权力。谈到心态的话，每个人的心态都必须摆正。但是并不代表软弱。
4月 29th, 2007 at 12:50
确实有你说的这方面的事情！但也根据情况以及公司的状况有所差异！
5月 14th, 2007 at 13:25
电力电缆…
不看好这个…
6月 13th, 2007 at 19:46
[…] 管理者不应直接参与产品的开发与设计 […]
6月 18th, 2007 at 3:02
[…] 管理者不应直接参与产品的开发与设计 […]
1月 3rd, 2008 at 22:35
我是学工业设计的 这学期刚学了设计管理课
让管理者懂设计 让设计者懂管理
2月 26th, 2008 at 11:20
公司管理者餐不参与产品设计完全取决于公司的产品设计团队的实力是否得到了领导的认可
领导其实都相当甩手掌柜，底下人忙乎去，自己赚钱多好
就是因为99%的公司的设计团队很弱，领导才不得不自己上阵。因为设计师不对产品最终效果负责，只队需求方负责，所以责任就落在需求方身上了，大一些的产品，自然就落到管理者身上了
管理是责任、权利、义务的平衡与艺术。管理理论都是花架子，事后诸葛亮
3月 6th, 2008 at 11:10
太有感触了，之前在一家公司做的时候，老大只和我们说一句话：给我一个理由。永远不会先开口。这让我们做事的时候主动性非常强。后来个人原因换了一家公司，现在这老板真正是总理！啥都管，每天看着非常忙，和产品开会，和商务开会，和营销开会，每次开会都在激烈争论。现在感觉整个公司的人都在混日子一样，反正老板怎么说怎么做，我的感觉就是这个公司很危险，非常危险。
3月 7th, 2008 at 17:17
[…] 这方面我还是一个freshman，不过看了一些文章，经过一些实践后也算是有了一些想法。希望如果有这方面的前辈路过的话，能不吝指教。首先，作为一个团队，不管出于什么目的，如果产品设计出来团队成员自己都不是忠实用户，那么这个产品必然是失败的，体验自然毋庸置疑也是失败的。我相信不管做什么，没有信念和态度是做不好的，哪怕成员再明星。从现在的互联网团队看来，无非是两种，一种是资本营销圈子，一种是技术理想圈子。后者的信念和态度自不必说，只要团队的方向正确，产品和体验不会差去哪里。而前者往往有惊人之举，纯粹的资本运作自不免有财大气粗或者重财轻技的毛病，直接影响产品的质量。总之，团队成员必须首先是用户角色模型之N。其次，管理者不应该直接参与产品的设计。这个问题在UCDChina有过讨论，我对此太赞同了。说的更精确一点，即：具有一票否决权的管理者不可以直接参与产品设计。UCDChina里分析的几点我十分的赞同，尤其是对管理者参与产品设计的原因的分析： 产生上述问题的根本原因是管理者觉得所有的责任（风险）都将会由他承担。一个设计师承担的责任在管理者眼里微不足道。这是出于对自己以外的人的不信任。但是我们都应当明白，团队中的任何一个人都相应的有一定的责任和权力。 […]
4月 30th, 2008 at 18:03
原则上是这样的，但很难做到哦。
总之产品团队就是在最优体验和长官意志中找平衡吧。
5月 8th, 2008 at 0:13
[…] 引用ucdchina： “管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。不然估计程序员也会起来抗议。为什么？因为他们对于设计的一知半解。如果一点都不了解，那倒也罢了。问题是设计相对于程序来说，更容易让人觉得自己很懂。人的审美观与生俱来，但管理者对于设计的了解，往往局限于视觉设计的皮毛，更谈不上交互设计。有时交互设计师并不能给出严格意义上的数据证明，其交互设计方案就因为个人喜好（比如因为配色的问题）被一票否决掉了。 要让管理者、领导者看懂产品早期的交互设计原型是非常困难的。管理者往往喜欢看到带有视觉设计的原型后（这个时候产品往往已经成型，就像地基都打好了），再毫无理由的投出自己的一票否决权。” ——说得太对了！正因为视觉设计能直观地看到，管理者们通常较关注产品外观，而令设计师成了仅仅是帮助管理者实现某个理想的工具。曾经看到某设计师很牛X签名档：“很多老板喜欢请一个专业人员来帮忙实现他自己不专业的构想。” －－－这句话经典，哈哈！ […]
5月 8th, 2008 at 0:39
管理者总是更喜欢插手设计，因为只有设计容易看到、感觉到，而很少有管理者精通程序。
我是反对这种观点的，因为在软件行业，多数管理者均是程序员或规划出身。相反我认为与管理者良好的沟通才能设计出更易用的产品。
1月 4th, 2009 at 15:58
接触过一个插手开发的管理者，让公司的开发人员们非常头痛。
一次，开发人员就需求文档要求，提出开发方案A。这位管理者看后，以其经验判断认为不理想，给出方案B。开发人员觉得方案B有问题，但一时又没有找到有说服力的证据，无奈只好此方案进行开发。
果然，在开发过程中，因为方案B设计得不合理，导致项目出现了很多问题。而当开发人员想方设法将问题一一解决后，突然发现，DEBUG后的方案B，其实就是他们最初提出的方案A。
而此时该项目已经严重超期，那位管理者还为此非常不满，认为是开发人员能力有问题。
1月 4th, 2009 at 16:16
TO 46楼的朋友：
无论是开发还是设计，都需要花费大量时间与精力，做具体而琐碎的工作，这正是管理者们所无法做到的。管理者需要处理多项事务，注定不能对其中的任何一项深入展开。而浅尝则止的心态，是无法做好具体工作的，即使是领域专家也是一样。
当然，经验丰富的管理者，那是团队成员可遇而不可求的，他们可以给出宝贵建议与思路。
与管理者沟通可以加深对产品需求的理解，前提还得是这们管理者已经对需求非常了解，甚至需求就是他提出的。但如果这位管理者，本身不是乔布斯那们的设计达人，这样的沟通并不是提高产品易用性的必要条件。
1月 8th, 2009 at 14:53
管理者参与设计令设计师处于很尴尬的地位，你说是管理者的设计还是设计师的设计？往往都是管理者主导设计师的手来执行的设计，而设计师的设计往往被管理者一再的推翻，使设计一而再再而三为了一个设计改动，然而有可能又因为管理者的一句话所有的设计又再次的被推翻，继而打消设计师的主观能动性，从而使设计师从主动的计变得被动的设计。这样的管理者不乏少数，作为设计的我们处在很尴尬的地位。
1月 11th, 2009 at 0:54
事隔近2年再来看这个问题，我几乎完全不能同意本文的观点。我会写一篇文章来说明:)
1月 12th, 2009 at 0:45
@愆伏 这篇文章几乎是完全站在设计者角度写的。现在再看，我自己也不完全赞同文中的观点。需要辩证的看这个问题。
1月 12th, 2009 at 21:00
[…] 刚好看到UCDChina.com中的一篇文章《管理者不应直接参与产品的开发与设计》，感觉说得太有道理了。上面这个故事，可以用来充实文章的论据。 […]
5月 31st, 2009 at 10:40
道理上时该这么做的，可是国内所有项目团队哪个管理者不直接干预啊。。从体制上来说难啊。。。
11月 26th, 2009 at 9:38
目前正在痛苦地体验着文章描述的过程.
万念俱灰的情况下,重读这篇文章,不禁内牛满面
4月 18th, 2010 at 16:02
[…] 管理者不应直接参与产品的开发与设计 http://ucdchina.com/blog/?p=4 […]
4月 24th, 2010 at 11:06
刘邦曾的“夫运筹策帷帐之中，决胜于千里之外“是管理真谛
5月 14th, 2010 at 22:41
[…] … 原文章：http://ucdchina.com/blog/?p=4 […]
10月 18th, 2010 at 2:09
不参与开发设计，但是却必须有开发设计的经验。
个人认为一个管理者应该是综合能力要强的
3月 13th, 2011 at 16:59
而且一个管理者后面还要有好的团队。
10月 27th, 2011 at 13:35
[…] 管理者不应直接参与产品的开发与设计 http://ucdchina.com/blog/?p=4 […]