做什么、怎么做
千鸟最近写了一篇《互联网设计操作参考》，私下跟他简单聊过一些意见和看法，文中提到：
《用户体验的要素》所提的战略、范围、结构、框架、表现五层对理解帮助很大，但不适合走操作流程。
这本书在流程的概念上意义很重要，但运用到实际的团队流程中，往往很难执行和分工。
所以千鸟提出这样一个结构：
蓝图——产品经理——网站目标、用户需求、功能规格、内容说明
文档——产品设计师——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计
原型——产品工程师——原型制作、客户端编程
同事在跟我聊这个话题的时候，他说：流程往往是被逼无奈的选择，并且在流程精细的情况下，抛开速度和效率不说，信息在流程中传递的时候往往容易失真。
相信在大公司待过的都会有这个体会，产品周期长，效率低，很多简单的问题其实一个人可以解决的却因为部门、流程的标准问题，不得不交给别人来做。
而对于一些1-5人的产品小团队来说，往往是看UCD流程的细腻程度而望洋兴叹。以至于千鸟在文章结尾说“最好的Producer，有人可以带领大家做的更好，没人自己也能抗下来。”
所谓爷爷都是从孙子走过来的，所有的大公司都是从小作坊模式起来的，不乏一个人从产品构思到原型设计、到后台代码全部包办的情况。虽然这些牛人当初根本不知道UCD的概念，但他们往往是最牛的实战者，他们理解UCD流程也最透彻。
所以建议很多初入行的设计者别拿你刚刚听来、读来的一些概念和流程，跑leader那去吹胡子瞪眼要优化流程，如果没有找到现状所存在的问题和漏洞，也许你的leader更明白团队需要什么样的流程。
白鸦提出取消“用户体验设计部”，其目的就在于避免流程跨越部门，导致不必要的争斗。如果非要给产品团队分块，分成两块：
一：负责产品做什么
二：负责产品怎么做
一负责需要什么样的东西，二负责这东西长成什么样子。
这样分工的好处在于，节约流程但大权又不至于被一方独揽，双方可以相互牵制并改进产品。
对于产品怎么做，对于很多公司来说相对不是问题，因为现在UCD流程和理念中，这一块讲的很多。但在产品做什么的问题上，很大的比重上是依赖个人经验，一方面有些方法的验证成本高，比如用户研究、数据分析。另一方面，大部分人更加关注怎么做，结果如何。
相信不久，对于怎么做产品决策的方法和研究，会慢慢进入大家的视线。
不止一次听过聊“产品经理”有几种类型的话题：强调市场、强调设计、强调工程。事实如此，其实也正暗合我给《web信息架构》书评里提到的“业务架构、信息架构、技术架构”。
在上述操作参考中，根据《用户体验的要素》总结限制产品经理“网站目标、用户需求、功能规格、内容说明”职责，其实就是明确指出平衡信息架构的三个关键点“情境、内容、用户”。
“信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计”只是不同设计突出点，产品设计师们对之肯定都有起码的认识，不然无法干活，关键在于专业性，也就是基于不同背景、经验、兴趣所造成的强项差异。
所以我认为，根据专业方法制定角色，或走设计流程，我觉得都不可取。
“根据专业方法制定角色，或走设计流程，我觉得都不可取。”
非常同意，团队角色应该跟产品特征和需求分配，有些产品在某些环节的任务量，不足以让一个人抗下来。
用常规的分法，又会导致一边的任务决定产品命运，导致大权独揽。所以，信息架构是设计师的事，而不是产品经理。
很赞同隽辰说的“重要的不在于叫什么名字，而在于是什么人在做什么事”，这对一个公司来说，确实是这样。但对于整个行业来说，如果产品经理更多的关注产品怎么做，而不是做什么，那么设计师就很容易的定位成“美工”。
倒不是担心产品经理做不好设计，而是产品“做什么”这个问题搞得不是很清晰的话，问题更大。
“相信不久，对于怎么做产品决策的方法和研究，会慢慢进入大家的视线。”
热切期待！
做什么样的产品，决策产品的某个功能做与不做的标准是什么？如何做决策，这是我更关心的…
看来平时还是需要多行善啊
“现在在产品做什么的问题上，很大的比重上是依赖个人经验…
相信不久，对于怎么做产品决策的方法和研究，会慢慢进入大家的视线。”
其实做用户体验的也可以考虑采用团队的 Knowledge Base 知识库的管理方法，将当前UED的效果及时积累和存储下来。积少成多就成了团队及企业的经验，而不仅仅个人的经验。
您好！请问您使用的WP主题可以共享么
tony什么时候再设计几个wp theme！
蓝图——产品经理——网站目标、用户需求、功能规格、内容说明(这个同意）
文档——产品设计师——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计（视觉设计。应该不是放进文档里面）
原型——产品工程师——原型制作、客户端编程（产品工程师有时候也不是包括原型制作。原型的制作应该是美术开始做的事情）。开发工程师应该顶多能包括CSS。
引用此文章的博客