Q2：产品岗位应该读哪些书？
内容导读：此文除了推荐了几本产品岗位可能对你有用的书以外，还附上了当年我阅读此书时的些许读书笔记，因此文章篇幅会有些长，请耐心阅读。可能有些人会觉得这些书都很老了，但确实是这些书，影响并让我一直坚持到今天还奋斗在产品的一线。希望能给大家带来帮助。
另外，如下链接可以引导你去看产品问答的其他内容：
----------开始分界线----------
很多关于产品的资料实际上网上都有，这些资料有的是产品前辈的日常心得的总结，有的是成功的经验分享或是失败项目的反思，这些都是极具实操性和价值的干活，唯一的缺点就是零散，不具有系统。不一定适用于所有刚入门的新手。所以这个时候阅读几本好的书籍往往会让你在整体上对产品的概念，工作方式和流程，需要注意的一些问题和经验的总结。
介绍几本，适合新手产品的书籍，供大家参考。
《人人都是产品经理》
人人都是产品经理
这本书不用我多说了，产品新手估计已经人手一本了。
《设计与生存》
设计与生存
以下是我在2011年阅读此书时的一些感悟：
两天看完马宁伟先生的《设计与生存》，两百多页的文字直言不讳的道出了自己做IT管理的点滴心得。很久没看到这样的内容，能够让我在一边看书的同时一边不自觉的在嘴里默念着“真是本好书”。
作者的主要工作偏向电子和硬件方向，和我们现在的互联网产品有一点距离，但丝毫不影响这本书对人的启发。这大概就是所谓管理的通用性吧。其中说到的有关用人和管理方面的细节对于刚刚留意于此的我很是受用。提炼几点深受启发的内容，分享给大家：
1、关于工作态度
热爱你的工作，才会投入，才会花心思，才会不断进步。在一个“发烧友”面前，所有规章制度都是多余的。如果只是想混口饭吃，对不起，这不是对你说的，因为你还体会不到投入工作给你带来的心灵上的愉悦。
一直觉得之前很浮。最近似乎一下子就很能体会到投入工作时带来的那种“畅快”，有一种多年的便秘忽然通了的感觉。很多之前存在在工作中的结也迎刃而解了。以前做事的确有点瞻前顾后，还得过多考虑别人的感受，这些小地方思考的多了，反而阻碍了工作上的进展。现在心中无杂念，一切为用户，为产品，对事不对人，所以做什么都有足够的自信了。我靠，我是不是又到了一个境界了。
2、关于职业规划
人说“男怕入错行，女怕嫁错郎”，如果你老抱怨自己进入不了状态，不喜欢自己的工作，那么请你停下来，好好梳理一下自己的职业规划，找到自己的位置再上路。找准自己的职业规划，沉淀在某一个行业里。
最近一直在和身边的朋友讨论“产品经理”这个话题。我发现国内的产品经理受大环境的影响都表现的很浮躁，跳槽率很高。往往都是哪里待遇好就去哪里，很少有人能沉淀在一个行业里，慢慢积淀。作为“产品经理”的发源地宝洁公司，他们对这个岗位的全诠释一直保持着最原始的理解和执行。在宝洁，每一个产品经理都是在各自的行业领域里是专家和资深人士，对行业的认识深刻到能够把握住每一次潜在的机遇。
我想，随着互联网行业慢慢趋于理性，那些沉下去的人，会渐渐浮出水面，被发现。从我做起吧，做一个“砖家”。
3、关于培养机制
公司前一阶段一直在搞大讲堂，这个活动的初衷是好的，为了内部培养一些想要进步和不满足现状的同学。这点我在进公司的时候就有想过，所以程程同学找到我的时候和我一拍即合。我想通过这个活动在公司找到“有做产品欲望”的同学，不懂没关系，重要的是你想。三堂课下来，很可惜，没有像我期待中的那样，哪怕是一封邮件，告诉我你想学。我不知道是大家都太腼腆了呢还是根本没有这样的人存在。
4、关于分享，设立否决项
一个公司能留得住人主要有三方面因素。第一，公司的知名度；第二，极具竞争力的待遇；第三，有事做，能学到东西。
我说第三点，为什么去年公司施行单休人员流失率不高，今年单休却很高。这和第三点有关，事多，团队氛围好，大家都有统一的奔头，不乱，有条不紊。
培养一支好的团队不容易，留住更不容易。所以建立一个良好的分享机制对团队的稳定和发展很重要。
任何一个喜欢分享的人，如果一直向别人分享自己的知识，而得不到别人的知识反馈，慢慢的就会停止这个行为。所以分享是相互的，有些人能力是有，你问他他只肯告诉你结果，操作细节绝口不提，对此有些公司在招人时明确的设立了否决项，如果你不愿意分享你的知识，那么你就不适合留在这里。
5、关于团队意识
很多公司招聘的条款上明确写着“良好的团队意识”。这点看似是一条软条件，但其在工作中的重要性是相当的重要。尤其是在项目型的团队中，有明确的项目进度和质量标准。一个团队意识好的组织里的每一名员工作都会感到很轻松。看过大雁南飞吧，为什么大雁会排出“人”字型去飞，因为每一只大雁都会利用前一只的空气浮力要省70%的力气，所以当一只大雁掉队了，那飞行将会十分痛苦，它会很快的跟上队伍。而领飞的大雁则轮流替换。貌似这种空气动力原理也被用在了奥运会的团队战术赛中。
我呆过好几个团队，对于各种情况深有体会。
6、关于用人
公司的环境是怎样的，容不得哪类人的存在，这些硬性条件必须列举出来，并在面试的时候一一核实，采用否决项的形式，遇到即封杀。比如说第四条的，有些公司需要有分享的意识，那面试的时候必须说清楚，如果你来上班就要遵守，你做不到，就不要来。
在我们公司，我觉得有几点必须卡死在面试环节。第一个就是硬性能力问题，尤其是技术类岗位，比如说设计，它的设计风格是否能满足你的项目要求，他擅长的是什么，比如说页面设计，有没有其他的其次一点的技术，比如说还会一点点图标设计，那OK，这可是你面试时候自己说的，试用期间，会安排相应的工作给你，达不到要求就over，设定试用期的意义就在此。
第二个就是团队意识，要投入项目之中，尤其是在项目中起到承上启下环节的，比如前端，设计做好效果图没有告诉你，最后等负责人注意到了才去跟进，影响了项目进度。最好的解决办法就是在面试的时候告诉他们，我们的项目流程是怎么一个模式：“设计在规定时间做好效果，差不多到限定日期了，下一个环节的前端就要盯了，不然你自己的项目进度不能再规定时间内完成，影响到下面的进度。当然，从全局来讲，给设计的要求就是做好之后要及时交付给前端，不得延误。”有关纪律性的问题详见8
7、关于工作主动性
这点我的感悟太深了，之前做生活，又比如前端，所有的bug都是产品找到后提交给他，他做好之后产品再告知技术。以至于后来我都感觉这样是天经地义的了，直到有一天我遇到了周晓兰，她做事情很负责，自己做的页面bug比较少之外，给她提的bug改完之后他都会主动和技术沟通，要达到什么样才算合格，这就省了产品人员好多时间，而且上下环节直接沟通效率又高。
再比如设计，不是设计好了效果图交付给前端就没事了，前端切好了静态页，设计应该拿出来看看，哪里的效果少了，哪里不是这个样子，哪里还需要设计上调整一下更美观······这样才是一个好设设计师该做的。
我对团队的主动性提出一个要求“好的产品绝不是靠产品从头到尾参与得来的，而是需要没一个环节的每一个人参与，用他的专业角度来审视他的那部分是否完美了，只有每个细节都完美了，产品整体上才能完美！”
8、关于纪律性
以前一直崇尚人性化工作，其实一味的强调人性化只会使团队变得懒散。在书中我知道，有的地方该出规章制度的，甚至设为“高压线”的一定要存在。
管理靠流程，这是科学的一面，可以少走很多弯路，但绝不可以搞“大跃进”。
9、关于外语的学习
学习一门外语很重要，只是我们从小就被灌输的思想。以前一直以为自己根本用不着，直到自己上个月底去了趟上海，遇到了几个老外，几个人用手用笔比划了半天才知道问我们附近哪里有比较好吃的小吃，我们几个傻傻的看着他们手舞足蹈的，直到最后在纸上画出一个类似三明治的图我们才知道他们的意思。这个时候多渴望自己能跟他们多聊聊啊。一个人想学一个新东西还是要有一定目的，要不然你一点动力也不会有，另外，要有这样一个交流的语言环境。
10、培养团队骨干的重要性
善于发现团队中暗藏能力的人，并适当的给他一些发挥的机会和空间，尽快的成长起来对团队的建设和项目的把控都会有促进作用。
11、职业的立场
我发现自己和作者有类似的地方，那就是对工作太负责。每天下班了还在想这个页面怎么改，那个东西什么时候能出来，回去查资料，学新知识。所以一直有同事说我“工作和生活不分”。我自己也搞不清楚是怎么回事，可能就是个人的职业习惯吧。喜欢尝试自己的没干过的事情，但对于未知的事情又常常很忐忑，怕自己干不好，就像昨天上午开完会，我突然觉得后面的工作不知道该怎么进展下去了，于是想了一中午，最后想到了，原来根源在于自己对运营这块不是很擅长。然后就在小本子上记录下来，要狠补运营的知识，也许就是这样的习惯，让我一次一次的进步吧···
12、勇于承认自己的不足，不狡辩
不为自己做错的事情狡辩，就像自己对事不对人一样，既然有错就应该勇于承认，因为你的承认，你开始变得自信，会让大家觉得你好沟通，这样对于工作的继续开展会很有好处。
《UCD火花集》
UCD火花集
以下是我在2011年阅读此书时的一些感悟：
在写这篇读书笔记之前，我很隆重的向大家宣布，山贼的阅读时代已经开始。这是我在“青番茄”借的第一本书。咱不打广告啊，就先说一下我对“青番茄”用户体验的一些看法:
1、对网站模式表示认同。这是一个良好的开始，无形中已经赢得一批用户（比如我自己）。
2、对于网站界面设计和web兼容性表示抱怨。不知道是人才难觅还是不被重视····
3、对于配送时间表示无语。不知道是物流的原因还是怎么的，从下单到送达竟然花了8天，还好哥是那种比较执着的人，没有耍性子，依然的签收了···
4、随书寄来的麻布小口袋“精神食粮”的出现算是比较花心思的。另外一封快递单和使用说明乍看上去是比较温馨的，但是等到要还书的时候却有地方看不懂，比如说要求“在快递单上填写会员账号”，但却没有指明填写在哪里，弄的我一头雾水。（也许是笨人的烦恼吧）
5、“续借”的按钮交互设计的不太合理。我原来不想续借，只是想试试能不能续借，谁知点上去没有任何提示直接续接成功，有点接受不了。
希望“青番茄”能越做越完美吧，谢谢····
很抱歉，《UED火花集2》都出了，我猜刚刚看完《UED火花集1》。看这本书花的时间不长，一周时间。这是一本UCD大社区牵头，由业内同学合编的一本介绍“用户体验”的书。看完整体感觉有些东西讲得太枯燥，似懂非懂，太理论化<白鸦的部分文章写得倒是有点“声情并茂”>。当然啦，还是有些许收获的，要不然那些个大好青春的夜晚岂不白白浪费了。
下面请看大屏幕：
*如果想加入UCD行列，有两句话希望你能记住
1、你不是用户（不是很懂）
2、产品的意义，是为用户创造价值
*充分发挥设计师的专业，在界面上让Ta做主（个人觉得执行的力度得看团队的成熟程度）
*在设计前，你的产品管理者是否能让你完全了解产品的思路/方向以及产品要表现出的感觉和气质。（个人一直强调的让设计/程序人员尽早的参与进来，但是目前的部门分开使得该方法执行起来缩手缩脚）
*当给需求的人已经确定需要N套设计方案才能最终确定时，他已经把设计师当做廉价的劳动力了，设计不好是很自然的事情。（对设计说声抱歉，我们的确干过这件事）
如果PM是父母，那么UED应该是老师：（这个比喻十分恰当，但是还是那句话：执行的力度得看团队的成熟程度）
*产品是一个孩子,孩子要学习钢琴，舞蹈，体操还是绘画，可以由父母做主；如何教会教好则需要老师的专业指导。
1、如果父母不告诉老师他需要让孩子学习钢琴还是绘画，就让老师去教，那是做父母的失职。同时也在耽误老师和孩子。
2、也有许多父母，自己会谈一些钢琴，往往他们会在确定了让孩子学习钢琴后，还自以为是的指挥老师“先教莫斯科夫斯基练习曲，然后再教小奏鸣曲”。那么孩子最后十本父母耽误的。
3、如老师给了孩子专业的弹奏方法，回到家后父母又交给孩子另外的弹奏方法，然后让孩子用自己教的方法，那么这个父母最终会毁掉孩子。
*画流程图时先画主干再画枝蔓。
*最好的画流程图工具就是纸和笔。
*关于画流程图的一些建议：
1、不要因为时间来不及而偷懒，事前准备充分以免事后补救。（这就是三期要吸取二期的一个经验）
2、不要因为画不好而放弃，如果你不试，你永远都不知道自己能做到多好。（鼓励大家尝试）
3、不要考虑太多的细节和逻辑关系，画流程图要关心的是线路而不是交互或界面。（在我们公司没法做到，因为我们就是传说中的“万金油”：产品，交互甚至美工等身份随时转换）
*产品设计中的角色设计（其实我们的工作中或多或少在用，但是使用的方法还没有达到正规的标准）
*建议不要先设计首页再去设计二级或三级页面。（这个习惯我们已经有了）
*一个项目前期需求的嬗变是极其可怕的事情，定义下来的需求应该是严密论证过的经得起啊考验的。我们可以随着项目的推进进行修正和完善，但对于大体方向要坚持下来，否则会陷入无休无止的返工和轮回中去。（大家心里都有数）
*一种典型极端现象（要避免发生）（这个例子十分恰当，但是还是那句话：执行的力度得看团队的成熟程度）
当要发起一个项目时，产品部从来不会和任何其它部门同事商量，他们只会在自己部门内部讨论并直接形成“结论”，然后他们成立小组，所有小组成员分工撰写详细的PRD（Product Rrequirement Document）。PRD的详细程度甚至具体到“界面上某个按钮应该放在什么位置，应该多大”。等PRD写完之后，回去找UE的同事进行“设计”，
并要求每个设计细节必须严格按照PRD。
这种现象造成的后果是：对于设计并不擅长的产品人员在做设计，而真正的设计师则成了摆设，成了“界面”的制作者。很少能真正的参与到设计中。
*产品经理和交互设计师的分工：（阐述了产品经理和交互设计师的本质区别：产品部/UED部）
1、产品经理结局产品从无到有（骨骼结构）
2、交互设计师解决产品的从有到优（血肉，皮肤，其中视觉好比是穿衣打扮）
*产品经理只要控制好底线，把握最基本的战略层，结构层。要相信对于导航的设计，交互设计师更专业，对于用红色还是黄色，视觉设计师的感觉更权威。
*交互在改变产品（确实，硬道理）
从用户角度来看，首次接触产品时，往往来不及完整体验功能和全面浏览。最后容易留下深刻印象的便是交互模式，很可能因为交互创意而保留对整个产品的良好印象，进而影响到传播。
*注意网站文字的措辞和应用。（细节决定成败）
*关于界面文字语言的基本规范，大体包含如下几点：
1、一致性：在相同使用场景中不出现两个或多个词汇描述同一种操作或同一件事物。
2、准确性：不适用易混淆的文字描述常见事物，使用常见通俗的语言，不罗嗦。
3、情感化：结合人物角色，使用易记，与产品传达体验一致的语言（白鸦常称为产品的气质）。
4、节奏感：主要是文字一般需要注意的大小和颜色的限定。
*“帐户”“登录”等用词的准确性。
*规范最大的作用就是便于分享减轻沟通压力。
*规范的目的不是约束，而是如何提高工作效率。
*规范的内容：
1、概念文档。固化产品架构和业务大流程。
2、页面设计。固化界面布局和表现。
3、模块控件。固化功能落实和操作。
*写给设计师的几点建议：
1、善于表达与沟通。
2、了解你的团队现状/学会在理解中适应团队。
3、学会坚持好的视觉理念，学会说不。
4、多涉猎各方面信息与知识。
《结网》
结网
以下是我在2011年阅读此书时的一些感悟：
山贼：2011年4月5日入手《结网》，正赶上网站即将上线的关键时期，工作强度比较的大。时间挤啊挤，历时1个月又18天，第一轮结果了本书，囫囵吞枣中略带些收获，整理如下。
产品经理的职业修养：
◎ 诚实：对投资者，同事，用户诚实
◎ 有所长有所短：不要过于盲目自大
◎ 对产品有信心并做好了长期吃苦的思想准备
◎ 愿意倾听用户的意见和他人善意的建议
◎ 不推卸责任
◎ 不会认为理论上可行就等于彻底搞定
◎ 不回去浪费时间重新发明轮子
◎ 不要将“还没想清楚”，“如果发布之后再调整对用户伤害太大”等借口挂在嘴边。事情是做出来的而不是想出来的，投资者和用户的耐心是有限的，像是不够的，产品都是在做的过程中不断完善的。（山贼：动作要快，先上线，再更新）
用户调查/反馈方法（使用焦点小组）：
组织6-9名用户参与调查。6-9名用户的调查结果具有普遍性，需要一名专业主持人，确保讨论不偏题，协调气氛。
A/B测试：用于更大规模的用户测试。
A用于维持现有版面/功能，B提供系版本/功能。
网站作出重要决策的时候，有时候是要依赖数据的，不能全凭想当然。（山贼：数据的客观性和理智性）
一个非常棒的网站优化工具，可以帮助产品经理进行A/B测试：www.google.com/websiteoptimizer
墨菲定律网站版：
◎ 凡是输入框，都会遭遇灌水，SPAM，脚本注入
◎ 凡是积分都会被刷
◎ 凡是上了网站首页的内容，都会出现色情，政治
◎ 凡是用户间沟通的渠道，都会被广告机器人利用
产品经理在自己的职业生涯中，会经历类似的几个阶段：“少年爱绮丽，壮年爱豪放，中年爱简炼，老年爱淡远”
作为一名产品经理，应该积极地想方设法缩短这个过程，尽快把注意力从花哨的细节转移到服务于产品核心概念的细节上，建议把产品核心概念打印出来贴在自己每天都能看到的地方，不断提醒自己应该专注什么。（山贼：个人觉得这个和做设计的阶段一样）
产品经理关注要向用户传递什么信息
交互设计师关注如何更好的将信息传递给用户（山贼：这个就是所谓的交互设计）
研发团队喜欢什么样的产品设计文档？
◎ 给我一些简短，目标明确，最新的东西
◎ 短而精确，容易找到编码位置
◎ 我就要一个做事的列表
错误的文档会浪费研发团队大量的时间，这是他们最痛恨的事情之一。
撰写需求文档的时候，产品团队应对与产品逻辑进行充分的讨论和测试。
推荐使用wiki来写文档，而不是word（山贼：突出在线与同步的优势）
使用肯定的语言，不要出现“也许”“可能”这类词，提交给开发的内容应该都是确切的，可执行的。
用户行为：
Attention 关注 >> Interest兴趣 >> Search 搜索 >> Action 行动 >> Share 口碑传播
用户最初从哪里开始关注一款互联网产品：
◎ 看到朋友在用
◎ 网络广告
◎ 朋友告诉我
用户体验三要素：
◎ 别让我等！（时间）
◎ 别让我想！（模式）
◎ 别让我烦！（简化操作步骤）（山贼：就依据这三点，网站的bug就可以改个底朝天了。）
Google Chrome OS 的设计目标：
我们要设计一个快速，轻盈的操作系统，几秒钟内就可以启动，把你带入网络。（山贼：产品的目标要每个产品人都应该铭记于心，我们现在的产品核心和目标是什么？）
研究表明，用户最面议的网页打开时间是在2秒以下。如果等待12秒以上网页还是没有载入，那么99%以上的用户会关闭这个网页。
用户体验真是投射法：
◎ 电梯的交互：按一下，灯亮，告诉用户已响应
◎ 双击的响应问题：在0.1秒内让用户知道他响应了，不至于做无谓的等待。
网页包装三要素：
LOGO，是什么，带来什么好处
关注用户及其任务：
在做产品的时候，由于投入了太多的精力去做设计，研发，有时候会发生关注产品本身多余关注用的现象。（山贼：这个的确是现实工作中活生生的例子）
尽可能的降低用户学习的成本。
为什么hao123让所有IT人士大跌眼镜，为什么很多中国用户不喜欢官方版本的XP，非要换成番茄花园。作为产品经理，外卖需要发丝以下我们是否真的了解我们的用户。（山贼：外卖对于苏州用户是否真正的了解呢？）
注意观察身边的用户体验。
对于提示文字过对的提示，可以合理的引导到帮助中心。
用户喜欢消灭数字。（QQ，邮箱）
数字量不能太大，用户会有压力。
产品经理要对团队成员的能力进行评估，可与预期项目是否能够完成。
产品经理要正确的掌握每个人最想从项目中得到什么。比如完美的简历，个人能力提升等等，合理引导对产品经理的进度起到推动作用。
Google Calendar 可能进行简单的项目可视化管理。（山贼：很直观的一款项目可视化管理产品）
产品经理的万精油身份只是候补角色，如果已有同事在相应岗位上工作，千万不要越俎代庖。（山贼：自己经常性的犯这样的错误，其实应该引导相关人员按照你的意思来做，这才是你工作的核心。）
产品经理要真心地接受同事的工作，并容忍其偏差，不能容忍就意味着所有工作都得有自己独立完成，你真的可以负担吗？（山贼：这个是真的得有一定的偏差容忍度，都则会扛不住的。）
会议发起人在会议召开前应做好充分的准备，带有明确目的去组织会议，不要耽误他人时间。（山贼：这个东西真的是这样，会前做好准备不仅是自己的思路更清晰，而且节约了别人的时间。）
文字信息要比图片信息多花好几倍时间去理解。
频繁的使用自己的产品是一名产品经理应该养成的职业习惯之一，产品经理需要做到春江水暖鸭先知。（山贼：后面一段很长的时间，我们都将在做这件事。）
Clicktale.com------Clixpy.com-----两个可以记录用户操作的网站（山贼：还未操作过）
制作一分公司内部平台和公共平台的资源地图，列出各个平台的名称和有效的展示位置
如果允许一个新手一次走两步，那他就可以在击败象棋大师------说明了产品更新的威力（山贼：鉴于前面的频繁使用，然后就是不断更新，包括消灭bug，增强用户体验等）
◎ 没有取舍的思考是不够深入的
◎ 注重同时出现任务的优先级排列
◎ 在倾听用户意见的同时，一定要清楚自己的底线在哪里，哪些地方可以有弹性，哪些地方要死守。前往那不要把产品的核心弄得支离破碎
◎ 正反馈有助于提升团队兴奋度，保持激情。
（山贼：下面一段话摘自tencent创始人，原腾讯CTO，Tony（张志东QQ:10002），在一次会议上的讲话，每个人读后都会产生些许自己的想法：）
每个岗位都有可以学习的地方，都有优秀的同事值得我们学习，值得我们用心投入去体验。无论我们今后的职业生涯如何发展，这种全力投入的过程，都是有意义的积累。
有的朋友很心急，对一个岗位，一个公司，一个行业，一遇到困难的问题就浅尝辄止，还未体会到精髓所在，就急于换岗，换公司，换行业。尤为艺术大师曾经说过，“不精一艺莫谈艺”。Tony个人建议，年轻的朋友可以更耐心一些，尝试用心投入去发现工作之美，尝试去体会工作本身的快乐。
当我们经受住极大的压力，在重重危机和困难中，经过不懈的努力，终于找到可行的解决之道的时候，那种豁然开朗的感觉，难以言传，是未经历极限挑战的人所不能理解的，只有用心投入，才能体会这种工作的快乐。
一直很欣赏华为公司的一句话，“胜则举杯相庆，败则拼死相救”。在工作中，能解释一群志同道合的同时，能相互信任和相互欣赏彼此的激情，大家一起并肩作战，创造价值，是一件很开心的事情。
一个人是否是绝顶高手，是否绝顶聪明，并不是最重要的。最重要的是，你是否对团队有激情。你是否学会欣赏团队成员的努力。你是否愿意建设性的帮助他人成功，只有对团队有激情的人，才能引得团队的尊重。
《设计网事》
设计网事
以下是我在2011年阅读此书时的一些感悟：
千鸟的这本书写得不错，都是写自己在业内接触到的方方面面。一些例子举得不错，看完之后很有感触。整体符合本土设计师的口味。具体就请看下面的一些书摘吧：
设计兴国
最初是由日本在工业设计里提出，与此同时，韩国提出了“科技兴国”。结果日本在很快的二三十年间成为世界强国（我一直认为日本的工业设计超过欧美），而韩国也很快发现科技兴国很难真正改变现状，而改提“设计兴国”，于是之后才得以出现很多众所周知的品牌（现代、三星、LG...）。
立足于传统行业设计
知识的不对称，不会构成产业。
设计如果不服务于传统行业，而穷于应付各种互联网概念和专业术语，永远得不到提高。
传统行业里，缺做互联网资深的人，互联网行业里，缺玩传统业务资深的人。于是会造成很多问题，比如两边难沟通。在传统行业者心目中，网络营销e-marketing是神秘的事物。欺负人家不懂，互联网从业者学会了玩概念唬人，总质量方面很难结合见效果。
任何产品做好了必然会社区化，早期的论坛就是最好的证明。往后互联网产品的发展方向会更垂直，能否做好的关键，取决于对传统业务（比如吃喝玩乐）的资深，而不是对SNS概念如何精通。
在生意场合，没人怀疑“永远为顾客着想”这条千古不变的真理，历史上也没有人来呼吁这件事。但是到了互联网，一切变得神秘而朦胧起来，以至于还需要本《别让我思考》来阐述为什么。当我们打出一面UCD旗帜时，我一直很担心，会不会有人认为很幼稚，因为对优秀的设计师来说，这根本不需要解释。
社会中总有喜欢钻空子的人，转轴政策上的漏洞，玩好可以发一笔，社会不提倡但也无法抵制，谁有能力谁都可以做，这种成功案例极少，而且几乎不可复制。不少做SEO的老艺人、老艺术家们还在不断努力，但事实证明，知识的不对称，不会构成产业。
互联网严格意义上只是更利于传统行业信息传播的新渠道，比如图书出版，网络购书利用了信息技术更好地问哦顾客服务，地摊虽然一样是卖书，但显然不会有地摊行业，同理，互联网设计的突破不会再互联网技术领域，SNS不会，UCD不会，SEO更不可能。
作图是设计，策划是设计，写代码也是设计，过日子也可以设计。设计如果不服务于传统行业，而穷于应付各种互联网概念和专业术语，永远得不到提高。
自己设计自己用
如果我是创业者，首先不会操作自己不熟悉的行业，否则不好管理。任何职位也不会选择没有相关业务经验的同事，因为无法准确理解需求，引导创新。
最好的Producter是，有人可以带领，大家可以做得更好；没人自己也能扛下来。
所谓的SEM只能是做市场和销售（网络营销）
所谓的SEF只能是做设计的和工程（搜索引擎友好）
真正的SEO只能是做研究
做设计还是做产品
前不久与某门户网站的同行聊天，也提到类似话题。“设计中心”与“网站部”并列，而不是在“网站部”之下，同时“网站部”负责全部网站产品。也就是说，设计与产品是完全分开的，这样的组织构架冗余，并且容易出现沟通障碍和降低工作效率，或者各自为政。常见的是根据大产品体系划分事业部，个子有独立的设计部门，平时沟通互相学习，分享知识，共同促进发展。
体验也讲究拒绝
做好用户体验有两个方面，迎合用户和拒绝用户，通常被忽略的是后者。
以用户为中心
产品忽悠用户的感情，用户就降低对产品的期望。
需求不是研究出来的，感念也不是讨论出来的。
用户习惯的力量无穷大，设计师可以干扰，但永远都不能改变。
Yahoo！的项目工作流程
（1）产品制作人，写产品计划书
（2）用户体验研究员，做调查分析
（3）信息建构师，设计产品结构
（4）交互设计师，做出交互流程
（5）视觉设计师和用户界面设计师，作出页面视觉设计
（6）前端工程师，前台开发
（7）后台工程师，后台开发
（8）用户体验研究员，做用户测试确保质量
这应该算是一个比较完善成熟的流程，信息构建和交互设计明显处于很重要的位置。而国内项目普遍流程是“策划+设计+制作+开发”，普遍忽略的是2.3.4.
互联网设计敏捷迭代
以前我也常抱怨做互联网设计没谱，一是资源紧，二是变化快。项目周期和人手似乎永远都无法满足，来自内部考虑不周，外部竞争压力双方的需求变更频繁。其实这就是互联网设计的常态，接下来提到的方法，分为三大步骤，版本仅供参考。
Alpha快速完成核心功能开发
“蓝图”只是代名词，也许只有些蓝图片段或规划片段。曾经我们在老板办公室开会，根据头脑风暴结果、会议记录直接做原型。这么说可能有点一觉回到解放前的感觉事实如此，第一步很关键，但质量不重要。
因为开始就期望得到完善想法是不可能的。比如，你开会描述个东西，让同事提意见，可能大家什么都说不出来。但只要你动手做出具体的原型，同事亲自测试体验之后，意见噼里啪啦一大堆就来了，在这层意义上，绝大多数原型是炮灰也应该。
最初工作用自己最熟悉，最快速的手法完成，别让开发团队等。当然，这部分代码质量将直接影响以后的迭代工作量，根据时间灵活安排。不要考虑得过于复杂，总结起来有三点：
1、尽早用web原型评估设计质量
2、制作避免过早陷入web结构和表现细节。
3、设计避免过早陷入功能细节。
每个业务又会有核心功能，也就是用户的核心需求，基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块，意思就是逐步提炼，找准关键点下手，这样才能搭好框架。也许经过几次迭代后，这部分工作已经是个可以跑起来的低保真产品，颇具Alpha版本规模。
Beta迭代完成固化需求功能开发
大框架不要下手太狠，别自以为经验丰富把盘子搞大。因为刚才说了，互联网产品灵活很重要，虽然需求变化时经常的事，但我们要把风险控制在最低点。接下来在已有框架内，用通信员放大的模式，按优先级实现辅助功能迭代，直至需求固化。
与此同时，产品设计团队除了对低保真原型的继续支持，还应并行完善和提炼高保真原型，并且着手对产品规范中复用模块的持续化整理，主要分为三部分：
web呈现效果迭代。先作图再切效率太低，因此我市直接用css美化低保真原型，通常这一步可以把效果做得很得体。是在有必要，最后再截屏用ps处理细节完善css。
1、web结构和表现迭代。我自己可以完成html framwork，css framwork两大块。
2、web行为迭代。需要工程师协助完成javascript framwork。
也就是说，在包括Beta版本以及之前，中总值中是实现功能需求层的良好用户体验。可访问性，兼容性、可用性、标准化、搜索引擎有好这些具体指标不要过早引入到应用开发中。，让他们都在高保真原型的迭代内准备就绪。
比如可用性，做低保真原型时尽量用最容易的方式解决问题，不要过早追求用户体验玩花样。大量JS互动效果和Ajax异步加载会给原型维护，迭代测试带来大麻烦。
再比如标准化，良好结构的web页面，很受应用开发工程师的花影，样式表则无伤大雅。因此我们可以多花功夫处理html结构，节省时间让css样式表也功能开发并行迭代优化。
Release模块话迭代提升用户体验
至此如果一切顺利的话，应用程序已经模块化并通过测试，设计规范也已经模块化，并有针对性的给出了高保真原型界面标准。用户体验的具体指标，已经在高保真原型的迭代中测试通过。
经验丰富的Producter可能都了解，成熟网站真正模块化后的内容其实不多，无非头，尾，导航，页签，表格，列表，搜索等。传统方法流程没有把操作体验与功能体验割裂开来，以至于来回折腾，反复做了大量工作擦让产品模块化，根据设计规范迭代提升用户体验有两步：
1、先处理界面视觉效果，比如分情况美化数据表格，文章列表等。
2、在处理界面交互效果，比如可以把某些跨页流程改为层异步加载等。
永远记住不可能一步到位，花本钱的创意设计要用保守方案，用户体验是奢侈的。对多数应用开发工程师来说，试用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子，加上css马上就能放光起来，并且还不影响已经开发出来的程序，有点不可思议。
模拟高效团队
人多嘴杂，经验是不完全靠谱的，一旦说话的人多过了做事的人，项目精度就会受影响。事实证明，产品需求之所以迟迟定不下来，往往不是讨论的不够彻底，而是参与的人太多了。
1、产品设计
多个流程可以由同一个人完成，少开点会，减少不必要的沟通，先把东西做出来。既然谁也说服不了谁，那我妈就用事实来证明，尽量多给大家自信的空间。
尤其是团队，提高效率的根本办法是减少参与人数，大家又应该有独立承担责任的能力和心态。十个人的团队，亮亮负责一个模块，在固定结构里并行推荐的速度，必然比十个人共同解决五个模块的串行速度快。
我的做事方式，自己能搞定，绝不会找第二个人，高手多了不一定是好事。我做不到最好，但是有自己的底线，有学习的能力。完美不是目标，完美只存在与每位用户的心里。
产品经理的责任
产品经理的特质：
1、基础业务能力，熟悉所做行业特点和玩法，自己得亲自用。
2、对互联网有一定认识，最好是网虫，并且知道如何把业务模式嫁接到互联网。
3、能精确传达市场需求和描绘蓝图，让设计团队充分理解你的宏伟目标。
4、非凡的沟通协调能力，保证不管发生什么事，进度都能顺利推进。
也就是说，如果有好产品经理独当一面，大家可以安身地静下心来做设计，而不会担心各种缺失和跑偏，更不会懂不懂得被拖出去讨论需求（喜欢开会的肯定不是好设计师）。同时，如果有这样的产品经理，不管多么牛的设计团队，都能镇得住。
传达并推动
设计师设计出来是A，经过产品评估后可做的是B，经过项目评估后可做的是C，经过周期压缩后可做的是D，最后工程师做出来的是E，可能Alpha，Beta版调整后出来的只剩F。
选择性阅读书籍
《用户体验的要素》
用户体验的要素
以下是我在2011年阅读此书时的一些感悟：
话说业内一直流传着这么有些书，美其名曰“做产品必看书目”。这段时间有幸拜读了Jesse的这本被汉化过的书籍。带着万分抱歉的心情向大家简单阐述一下个人对这本书的看法：用户体验是有一些比较重要的部分，但书中总喜欢把一个概念反过来掉过去的讲，是在强调吗？还是汉化版本不同的缘故呢，使得像我这样的读者读的越发枯燥无味。
整本书产生共鸣的地方有如下几块，请看：
* 有时候哪些用户不回来是因为你的竞争对手展开了一场声势浩大的广告造势，或因为你的公司目前负面新闻缠身。因此，任何断章取义的彼岸准都有可能造成误导，请务必后退一步看看除了网站之外还发生了什么事，以确定你了解到了事情的全貌。
* 我们很容易落入这样的陷阱，即以为我们正在为理想用户而设计网站，理想用户就是“某些与我们完全一样的用户”，但我们并不是为自己设计；而是为他人设计的，如果想要其他人喜欢你并使用我们创建的东西，那么就必须要了解他们是谁，以及他们的需求是什么。通过投入时间去研究这些需求，外卖才能抛弃自己立场的局限，真正从用户的角度来重新审视网站。
* 作者在书中描述了用户体验的五要素：战略层，范围层，结构层，框架层，表现层。
* 创建并使用人物角色的好处在于可以让产品设计人员脱离“以自己为中心”，更好的“以用户为中心”做设计。在设计的前忠厚都要不停的问你所创建的角色用户满不满意，会不会使用。
* 让一个工程师，一个客服人员，一个营销人员坐到一间会议室中谈论同一个网站，这会对大家都有启发意义。听取各方从自己熟悉的角度出发来考虑的，对于网站的观点并给予反馈，可以鼓励人们从不同角度来思考开发中的网站遇到的问题以及解决办法。
《火花集2》
UCD火花集2
以下是我在2011年阅读此书时的一些感悟：
这段时间忙于三期产品的构架与设计，闲暇中把《UED火花集2》大致扫了一遍。今天把读书笔记整理公布出来，虽然比预期晚了些，但还是出来了。先说说我对这本书的整体感知。或许是web用户体验这个概念包含的范围太广的缘故吧，2延续了1--涉猎的范围很广的特点。包含了排序，地图，浏览器，相册等在内的方方面面，给我的唯一感觉正如我的QQ签名所写“《UCD火花集2》概念性太深，无法使人浅入浅出”，当然收获固然是有的，就像每个人在看这本书的时候都会有所收获，只不过每个人的收获点不一样，以下就是我整理出来与大家分享的部分内容。
* 数据固然重要，但是不能完全依赖数据对产品做出调整。
* 用户反馈了5个新功能，但是当你满足了用户所说的5个功能的时候，用户可能法尔不要了。
* 一个交互在听到或看到这方案是一般会考虑这么几个基本问题：
1、确实需要这个东西么？
2、这个东西是什么，用什么最合适？
3、这个东西该长什么样子？
4、交互方式是怎样的？
* 交互设计师要弄清楚产品的本质，不盲目设计原型。消灭老鼠未必需要捕鼠夹，也可以养猫啊。
* 一个产品的成功需要有5大团队支撑：
1、Design Team：那些把各种需求转化为实现产品的人。
2、Engineer Team：那些把产品开发出来的人。
3、Business Team：那些确保财务报表蒸蒸日上的人。
4、Marketing Team：那些知道怎么把产品卖出去的人。
5、Management Team：那些什么事都做的人。
* 设计产品时，我们经常想破头的去描述某个产品功能。要么为了更准确，要么为了更好的理解。其前提都是紧紧围绕咱们的核心用户群。如果产品主要针对高级用户，那么需要准确专业的描述，需要强化术语；如果针对初级用户，需要简要清晰和民间的描述，尽量避免术语。
* 一个新的产品，早期应该是越简单越好。
* 产品经理需不需要为商业利益背负压力？
从产品的特质分析中不难发现，产品经理貌似是不需要对商业负责的，他们只需要实现产品的价值-满足用户需求就OK了；这就好比掌勺师傅只要炒出让食客满意的菜肴，而根本不必关心他们是否赚钱。而真正情况是，产品经理往往因为产品销售的不利二背负巨大压力。
* 产品经理（Product Manager）的定位：
1、Manage不是Create：产品经理是不能决定是否创建一个产品的。
2、Manage不是Marketing：产品营销不应该是产品经理的任务。
3、Manage不是Maintenance（注：维修，保养）：生产流程不应该是产品经理的任务（项目经理/QA）。
4、Manage不是Desgin：产品设计不应该是产品经理的任务（产品设计师，交互设计师）。
* 产品设计师更多的被称为交互设计师
* 产品设计师是一个新型综合体，应该具备几种能力
1、设计（各个设计领域）
2、创造力（挖掘产品的新体验）
3、规则（产品的预期/发展思考）
4、逻辑（清晰的产品流程分析思考）
5、细节（产品的质感）
6、数据分析（产品改进的支撑）
7、执行力
* 支付宝产品设计师在做设计之前，必须要做的工作，即写一份“设计概要”（可迭代）
1、你理解到的：为什么要做这个产品设计？出发点和目的是什么？重点的体验目标是什么？
2、这个产品要满足用户什么/哪些需求，用什么/哪些功能来满足，先满足什么在满足什么。
3、在解决需求的众多功能中，设计重点有哪些，重要性顺序是什么？
4、这个产品在系统中与其它产品的关联点有哪些，需要其他产品什么配合？
5、该产品中需要做好哪些数据统计点，这些数据可以说明些么？
6、设计时间表和计划。
* 电子商务网站的目标是卖东西挣钱，而不是靠人气和话语权正广告费。
* 电子商务网站的会员只适用于经常重复购买的用户，也要照顾到不经常光顾的用户。
* "购买按钮"和"加入购物车"的重要性
* 在线订餐可以统计每个菜被点得次数，分析与价格，季节等因素（商户中心后期可以家分析图等，参考淘宝直通车）
《硝烟中的SCRUM和XP》
硝烟中的Scrum和XP
以下是我在2011年阅读此书时的一些感悟：
半年前同事极力推荐了这本书而且谢了一篇对他来说茅塞顿开的读后感。春节期间看完了这本仅仅有着100多页的书，这也是今年看完的第一本书。看完给我的感觉就是“这是一个令我不是完全明白的好方法”。书中很多观点和方法对于产品开发都是很好的，不过正如作者所说，这种方法目前也是还在不断尝试和改进中，至于是不是最好的方法，当然取决于各个公司的“国情”。
依稀记得2011年公司曾经采用过类似的产品开发模式：评估项目工作量、确定开发进度和交付日期，采用白板更新进度等等。后来因为各种执行上的困难和弊端不了了之了。看完这本书结合公司之前的失败经验，我做一些关于产品开发管理和敏捷开发的个人认识和总结，希望能与大家一起探讨好的开发进度和管理模式。
1、产品开发/项目开发就像个人的职业规划和工作计划一样，必须有长线和短线。长线规划公司产品的未来发展及主要节点；短线要具体分解每一步具体要执行的步骤及模块，甚至要细分到每一周，每一天的工作安排。只有让所有人明白了项目的目标和需要做的事情，大家才能拧成一股绳一起去努力。我所理解的每一个sprint（我理解为“发布周期”）流程为：
理清工作思路→确定工作量（全体会议）→确定交付日期（全体会议）→分配工作内容（技术团队内部会议）→公布工作量及目标（对外公布）→及时更新工作进度（对外公布）
这样做的好处：
可以让团队都清楚大家接下来一段时间的目标是什么，拧成一股绳。
可以让每个人都清楚别人每天都在干什么，这样才会在内部形成竞争力。
可以让公司的领导及其他部门都知道团队都在干什么并且知道每天都完成了哪些内容减少了不必要的谈话，会议和质疑。
对项目的把控性增强了，知道什么时候需要催一催进度，什么时候可以让大家稍微放松。
难点：如何准确预估（评估）工作量，如何避免过多预估工作量导致产品失去竞争力？
2、合理使用“燃尽图”。它能够帮助团队及时判断项目进展是否在计划之中，避免产品开发进度过快或者过慢。
3、多做有用的事。去掉花里胡哨的东西。也不要把时间花在会议PPT的美化上，传达出报表大的信息即可。
4、下一个sprint中如何做得更好，需要总结上一个sprint中存在的问题和需要改进的地方。
5、制定一个大的产品发布规划大plan（plan1,plan2···）包括大致的发布日期。这中间牵扯到版本发布计划，除了正在进行的sprint需要确定精确的发布日期和发布内容外，后面的都可以根据实际需求的变更做出灵活调整。
6、上一个sprint和下一个sprint之间设立一个“缓冲日”，用于给团队成员调整状态。
7、我的疑惑：
拆分功能点（模块）的方法。
测试bug的修复安排是否占用下一个sprint时间，如果占用，如何来保证下一个sprint进度？
有一点是我在读书过程中发现的：书中一些自己经历过的事情读起来会很有味道，也很能揣测一些当时存在的不足和经验。而还有一些自己不是很熟悉的部分则比较拗口难懂，一扫而过有一个印象即可，随着经历也会慢慢深入并得到启发。
这些书也可以选择性阅读
《6点准时下班》
《在你身边，为你设计》
《体验度》
《参与感》
《没有梦想，何必远方》
结尾
看书除了能见见世面，更重要的是验证自己的想法...只有不断的输入，才能厚积薄发，源源不断的输出。
