“ppppppink”通过精心收集，向本站投稿了7篇互联网产品过程设计控制流程图，下面是小编为大家整理后的互联网产品过程设计控制流程图，仅供大家参考借鉴，希望大家喜欢!
- 目录
篇1：互联网产品过程设计控制流程图
文章描述：初拟一份控制流程图，给自己之后可能介入项目过程时提供一份指导说明，当然这是这几天围观其他项目时的一些心得汇总，然后根据公司目前的部门和小组配置设计的。可能随着日后了解的深入，思路会有所改变，应该说是一定会改变的。
初拟一份控制流程图，给自己之后可能介入项目过程时提供一份指导说明。当然这是这几天围观其他项目时的一些心得汇总，然后根据公司目前的部门和小组配置设计的，可能随着日后了解的深入，思路会有所改变，应该说是一定会改变的。特此记录。
————————————————————————
篇2：产品领域探讨(互联网领域)交互设计
探讨1：产品与业务的关系是什么？平常大家常说这2个词，使用的频率那是非常高的，有时候甚至会混用，认为产品就是业务，说到业务自然就指产品，从面向角度分析这些讲法都是正确的，业务是接口，产品是对象，因而：产品 instanceof 业务 = true，业务 = new 产品。业务，通常指从事的事务（外部人员看，称为从事；内部人员看，称为开展；都一个意思），它的目的是定性；产品，通常指是一种资源，是对能力（也即业务）的实现，它的目的是定物。一种业务，可以有多种玩法，多类人群，那么就会产生多种产品，有时候，一个业务可以产生一条产品线，甚至产品平台。
探讨2：用事物本质来理解互联网产品。组织内一群人在讲产品，但大家讲的是一个东西吗？我看未必。从上图，定义了产品的三个阶段，概念阶段，本体阶段，运行体阶段，每个阶段都有产品的概念，但实际上不是一个东西，大家关注的视点，做的事情也是完全不同的。概念阶段以客户需求为核心，确定要提供的服务；本体阶段以服务为核心，生产产品；运行体阶段，产品需要企业内的资源、参与者、知识组成的环境来输入能量，把产品实际运行起来。下面再引入参与者角色，进一步理解产品的事物本质：在概念阶段，用户提出需求，这个需求怎么传递到企业？需求获取途径千百种，各显神通。最终这个需求要落在产品经理手里，执行产品设计过程，处理上图所列的5件事情，其中确定业务是定根本，确定风格是定原则；其它如交互、用户体验、规则等事情，都是在这2个根本的指引下进行，最终完成产品设计（我称之为定义产品概念）。在这个阶段，用户说的产品大多是需求，公司说的产品大多指业务能力，产品经理说的产品是“确定了的产品概念”，业务分析师、技术分析师、用户体验设计师所说的产品与产品经理是一直的，但不同的角色关注重点不同：（A)业务分析师，关注产品在企业内部的能力模型，从业务逻辑上清晰绘制产品的内部体系；（B)技术分析师，关注产品在技术上的可实现性和产品风格中的部分质量属性；（C)用户体验设计师，关注产品风格的实现，完全以客户的体验为中心进行设计（《用户体验设计？——是什么不是什么》）。
本体阶段，这个阶段是对概念阶段产品的生产，生产的最后阶段有一个产品验收，验收的基本指标也是“是否匹配业务，是否匹配风格”。
运行体阶段，对于不同的角色所执行的操作不同，其看产品的视点也不同，但大家在“业务，风格”的认同点是相同的。
传统软件产品卖的是产品的本体，按照个数计算价格，客户拿到后自己运行；互联网产品卖的是运行体提供的服务，按照流量计算价格，产品的核心价值点在网络公司这儿运行。
探讨3：产品风格与产品品质是啥关系？产品品质是指产品的质量属性，例如美观，易用，高贵，轻盈，高效，耐用，高技术，人文领域等；产品风格是指一组产品品质的组合和搭配，例如将易用、高效、耐用组合在一起，搭配出一款产品风格，再用高贵、轻盈搭配出一款产品风格，用2中风格设计手表，最终生产出来的产品就不同，面对的人群也不一样。品质很像文化，具有高度的认同感，因而，不同的产品风格其面对的认同群体是不同的，我们常说的品牌就是能一直保持某中产品风格的东西。Yahoo与Google的搜索，其产品风格不同，所产生的品牌效果也不同。
探讨4：产品服务质量和产品品质是啥关系？产品品质是产品固有的，客观存在的。产品服务质量是客户在使用产品的过程中，对产品品质的评价，具有很强的主观性，要分析产品服务质量与产品品质的匹配度，就得科学采样，科学分析；此外是否每一个产品品质都必然在动态期间产生随机性哪？不是的，有些品质是终生不变的，
探讨5：产品风格与用户需求。用户需求、用户群特征、业务特征是决定产品风格的充分条件。为什么加入业务特征哪？举个例子，信息类网站（论坛，门户等）、支付、SAAS、C2C交易类网站等，能共用一种产品风格吗？恐怕不行，业务复杂度不一样，业务过程不一样，业务诉求不一样，这设计出来的产品风格，也自然是不一样的。
探讨6：产品品质转换为产品需求。产品品质可以转换为具体的产品需求，例如，稳定性，就可以转换为一个关键产品需求；易用性，也可以分解为多个产品需求：操作简单，流程简单，实时交互等。在探讨4中，讲到品质动态波动的问题，这些东西可以转换为风险需求，波动的幅度可以作为风险优先级的评定原则之一，对于产品经理来说，这些风险属于固有风险，或称之为系统风险，它是无论如何管理，都无法避免的，只能想办法降低这种风险波动的幅度和尽可能减少诱因。
探讨6：业务分析师的价值。既然有了产品经理，为啥还需要业务分析师？传统的一些互联网软件都是比较简单的，什么论坛，社区，信息发布，视频，MP3等偏向信息类的应用，产品经理一个人全搞定。到了今天，商业逐步加大在互联网的占用地位，其对产品经理的要求有所差别，商业自身是复杂的，商业对数据的要求是不同的，商业对企业内部能力的要求是不同的，商业对协作的要求是不同的。根本原因是产品复杂性对组织提出了更高的要求，这点，我认为与电信类业务有所相似，用户看到的一个简单产品，在企业内部需要一系列的内部能力体系建设，在这种情况下，就需要有业务专家（未必是产品创新专家或产品经理）使用专业的分析方法进行业务分析，通过这个过程，降低产品系统风险、降低整个企业业务的结构性风险、减少业务模型变更引起的企业级风险、增加业务敏捷性、缩短产品研发周期、鼓励资产重用、从业务层面开始SOA，而不是技术层面。
探讨7：产品风格与架构风格。产品风格是贯穿产品的整个生命周期的，它是产品在概念、本体、运行体三个阶段共享的基本法。产品风格是架构风格的重要输入，架构风格是产品风格的实现。
探讨8：产品分类和产品标识。产品分类和产品标识的目的是为了产品管理、产品销售、产品营销、产品计费、产品分析、用户研究等提供标准化体系。产品分类的指标是业务域，产品切分的指标是产品风格。
探讨9：产品与产品模型。产品模型是指一套标准化的产品研发模型，它的核心业务目的还是为了更好的圈定产品风格，避免你中有我，我中有你，乱状横生。只有建立了产品模型，才能建立产品线，也才能建立产品平台【参考《开发者对平台-产品平台-产品线架构的探讨》一文】,也只有建立了产品模型，通用业务模型的建设才能事半功倍，例如，安全，客户服务，运营，客户引导，产品依赖，过程等，也只有建立了产品模型，多渠道策略才能以最低的成本实现。
探讨10：产品与信息架构。待定。
探讨11：产品与商品。互联网公司最终卖的是解决方案，是服务，这与电信是一样的。那些固化的解决方案，我们封装为商品，标记一定的价格，销售给用户。解决方案是由一组产品或单个产品构成，由于包装的差异，形成不同的商品。
本文来自：www.esbzone.net/product_model/
篇3：互联网产品经理是什么？
本人说的产品经理是指互联网产品经理，非传统行业。产品经理是个外来的和尚，据说第一次出现是在宝洁公司。
产品这个东西，互联网上一般就是指网站，软件，虽然不光是这些，不过这样比较好理解，毕竟是看的见的东西。
一个网站要通过不同部门，不同职位，甚至不同公司的努力，生产出来的，是一项工程的结果。产品的价值是满足人们的需要。
去百度一下，产品经理的英文是Product Manager。再搜搜互联网产品经理，就发现，说啥的都有，五花八门……目前互联网产品经理正视被热炒的时候，到处都在招聘产品经理，好像有了产品经理你的公司才叫互联网公司，没有产品经理都不好意思跟人说你们在开发网站。
产品经理具体都干啥？
一款产品做还是不做？最后会做成什么样子？老板决定。
产品最后赚钱还是不赚钱？市场部决定。
开发流程和工作进度？技术经理和项目经理决定。
产品设计？产品设计师决定的。
查下词典，manage的含义有“经营, 管理; 控制, 操纵”。一般互联网公司，有这个权限的就一个人Big Boss。
这个时候产品经理就悲剧了，根本就是个多余的角色，除非抢人饭碗，不然在公司里根本就没地位。
不能抢人饭碗怎么办呢？就去协助别人工作，甚至是替人工作，体现自己微弱的重要性。
在北京叫一百个产品经理出来，估计这一百人做的事情都不会完全一样，负责的事情更是稀奇古怪。明明就是产品设计，项目经理，销售经理，用户体验分析师……为嘛顶个产品经理的帽子？
本人腹黑一下，顶着这个帽子就是替人背黑锅的，替老板，替不知道什么时候出现的各种问题。
经过慎重思考，本人决定，再有人唧唧歪歪说，你是产品经理……
三秒之内，直接回复，你全家都产品经理。老子是产品专员。
[互联网产品经理是什么？]
篇4：互联网产品策划书模版
一． 产品描述
1.是什么样的产品？
2.产品特色是什么？
3.和市场上的产品有什么不同？
4.生命周期如和何延续？
二．市场分析
1.市场上现有产品分析
2.目标消费群分析
3.潜在目标消费群
4.产品资费分析
5.用户操作习惯分析
三． 产品定位
四．市场推广
阶段一
2.阶段二
3.阶段三
4.阶段四
五．效益估算
1.产品资费
2.产品用户群数量
3.产品潜在用户数量
4.每月产品收益
六．产品内容介绍
1.产品规则
2.用户属性
3.体系介绍
4.用户等级
5.主要功能介绍
七. 产品开发进度
产品提案
2.产品思路整合
3.再次提案
4.产品内容再次整合
5.产品流程编写
6. 产品流程修改
7.产品流程提交
8.产品工单
9. 技术开发
10.内部测试
八.产品人员列表和职责
1.产品经理（项目经理） 2.产品策划3.编辑人员 4.技术人员 5.测试人员wap版本
一份完整的产品策划方案应包含的内容：
1、引言
描述导致产品创意产生的用户需求、市场需求、市场前景等概述性文字。
2、产品简介
关于产品的简单介绍，包括内容、功能、特点、与同类产品的比较等。
3、实现原理
产品内容的分块详细介绍已经实现的方式及原理。
4、业务流程
供技术实现的产品业务流程图、应对内容（语音业务中的应对语音、短信业务中的应对短信、WAP及KJAVA业务的用户操作反馈信息等）、业务菜单（WAP、KJAVA)等。
5、制作要求
对于产品技术实现过程中应达到的相应指标细节。
6、产品包装市场推广建议
产品的资费模式建议、用户操作流程、奖品设置、合作方式建议（涉及到合作方的产品）、市场推广方式建议、产品推广的后续服务内容建议等。
7、效益预测
效益预测的相关基础数据及原理、投入分析、收益分析、效益预测等。
8、结束语
废话几句，让人觉得有个结尾。
篇5：互联网产品策划书模版
目录
1.产品策划流程 ................................................................................................................................ 2
2.项目前期准备 ................................................................................................................................ 3
2.1市场调研............................................................................................................................. 3
2.2结点 .................................................................................................................................... 3
3.项目策划原则 ................................................................................................................................ 3
3.1盈利性原则 ......................................................................................................................... 3
3.2务实性原则 ......................................................................................................................... 3
3.3差异性原则 ......................................................................................................................... 3
3.4适度创新原则 ..................................................................................................................... 4
4.项目策划要点 ................................................................................................................................ 4
4.1明确网站项目需求 ............................................................................................................. 4
4.2整理网站信息架构 ............................................................................................................. 4
4.3制作原型界面 ..................................................................................................................... 4
4.4技术实施方案 ..................................................................................................................... 4
4.5清晰的项目需求文档 ......................................................................................................... 4
4.6用户体验优化 ..................................................................................................................... 4
5.原型的要义.................................................................................................................................... 5
5.1原型的意义 ......................................................................................................................... 5
5.2原型的使用 ......................................................................................................................... 5
6.axure原型制作规范 ...................................................................................................................... 5
6.1基本规范............................................................................................................................. 5
6.2构件规范............................................................................................................................. 6
6.3母版制作规范（参考） ..................................................................................................... 6
6.4站点地图制作规范 ............................................................................................................. 6
6.5Annotations注释规范（参考） ......................................................................................... 7
6.6整体制作要求 ..................................................................................................................... 7
7.axure操作小技巧 .......................................................................................................................... 8
7.1解决中文输入的问题 ......................................................................................................... 8
7.2超快速移动工作区 ............................................................................................................. 8
7.3快速放大缩小页面 ............................................................................................................. 9
7.4规范化地平移组件 ............................................................................................................. 9
7.5穿透控件选取下层的组件。 ............................................................................................. 9
8.结语 ............................................................................................................................................... 9
1.产品策划流程
2.项目前期准备
2.1市场调研
⑴网络调研
从互联网了解熟悉项目市场情况是比较便捷的方法，一方面可通过行业市场专家的文章首先从宏观上把握项目发展趋势；另一方面观察研究同业竞争者进一步明确项目的性质以及策划过程中需要着重顾及的要点。
⑵市场访谈
通过客户访谈、销售部门同事座谈会验证网络调研的结果，根本访谈映像去调整前一阶段的ID，使项目框架出具雏形。有条件的可以组织焦点小组访谈和市场调查。
2.2结点
这个阶段需要明确：
⑴项目定位
项目的用户对象是谁，项目的市场价值所在。
⑵项目前景
项目的盈利模式，今后公司所能采取的运营模式。
⑶全局观念
培育对整个项目的宏观认识，从整体上对整个项目的策划制作以及后期运营要点都了然于胸。
3.项目策划原则
3.1盈利性原则
需要有明确的盈利性途径，尤其在产品设计上需要首先将商业利益摆在第一位，项目上市之后需要以几何级倍数回报公司的人力物力投入。
3.2务实性原则
策划阶段的每一个步骤都需要考虑今后运营的着手点，从公司运营的实际出发，避免一味追求天马行空式的想象。
3.3差异性原则
新项目必须和目前市场上现存的竞品有明显的不同，客户从项目本身就能区分彼此。
3.4适度创新原则
遵循互联网日新月异的市场需求动态，追逐互联网产品发展趋势，但具体落实到策划阶段则需要把握好创新的幅度，步子迈大了容易扯着蛋。
4.项目策划要点
4.1明确网站项目需求
包括客户需求和市场价值所在，勾画清晰的产品和服务。
4.2整理网站信息架构
网站的'频道设置、栏目设置，如果是定位于某一行业的，则需要第一时间整理出合理的分类目录。
4.3制作原型界面
从频道——栏目——列表——内容单页——功能的思路出发，制作一目了然的原型界面，需要精确到每一个细节。
4.4技术实施方案
各个栏目的数据调用、频道和栏目推荐位子的信息调用、主要功能模块的技术实现、辅助性功能涉及到的关键词和字段，都需要我们在策划的时候考虑到。
4.5清晰的项目需求文档
这相当于整个项目的蓝图，需要凭借我们自身的积累写作深入浅出的需求文档，标准是让每一个阅读过文档的人都能对本项目有一个较为全面的认识。
4.6用户体验优化
遵循品牌建设规则的网站项目的实名、域名，协助制作人员和技术人员进行操作体验上的优化，精致、细致是这一阶段的目标。
5.原型的要义
5.1原型的意义
原型是一个有价值的设计工具。在项目开发的整个过程中，有利于评估设计的可行性。在初步设计阶段，能够探究和测试用户。在实际设计布局和更详细的交互问题，能够评估和测试。之后的高保真模型，可以用来提供一个最终软件的演示。
原型可以有多种实现方法。目前本司采用行业内流行的axure原型设计软件制作，采用该工具制作的原型特别适合web应用程序和屏幕序列的探讨。其他诸如visio、mockups等软件虽也可实现原型制作，但非经公司上级要求不可用于替代axure。
5.2原型的使用
5.2.1高保真原型
高保真原型可用于向上级管理者或同事展示，因为它传递了最终产品的许多特点，比如视觉设计。它们也适合于正式的可用性测试：
①给予用户/同事书面任务完成所需数据
②要求用户/同事边想边说出
5.2.2工具
①所见即所得的编辑器（或你选择的任何其他编辑——不过所见即所得更快）
②一个或多个浏览器测试原型
③图形工具
④设计元素库（一旦设计元素库建立，有助于形成一致的外观和加快开发速度）
⑤图形库或其他屏幕元素（有助于在其他事情重复利用屏幕元素（screen elements））
5.2.3优势
更好的交互，尤其是有益于评价屏幕变化
很好展现软件的设计或者可能的设计
测试和最终编码之间，还有时间来作出改进
6.axure原型制作规范
6.1基本规范
6.1.1交互设计模式
篇6：互联网产品设计师职业生涯交互设计
其实这个话题已经在侧面写了好几篇深刻反思，用我自己几年工作实践的体会来看，性格决定了将来的发展，某些特质虽然可以掩饰，但在这之上必然不可能有大作为。
我是典型极简主义（包括沟通），而且对事物相当有耐性的极端完美主义性格，擅长追本溯源。当我真正意识到自己性格特质的时候，便开始在工作中有意做取舍。很多事情不是做不到，而是成本太高，性价比又太低。
产品经理不是唯一选择
个人认为不管软件领域还是互联网领域，产品做不好的根源，主要是缺乏Senior专业技术人员，但更重要的是业余管理人员泛滥。这也许是任何行业、技术高速发展中，不可避免的问题。
曾在产品经理的责任中提到“设计做的再好不一定能胜任产品经理，因为两者的职业素质和职责不同。”在软件领域还有个说法“国内软件做不好，是因为很多人刚在技术、业务上小有积累、小有成就，就忙不迭去做管理、开公司，觉得那才是提升。”
归根结底，前不久鲍鹏山老师点评武松的那个观点也许值得我们认真反思“中国文化中很不好的一面，就是人人都特别看重体制里面的位置，把这些东西看成是自我的最高价值。”
管理与专业是两条路
最早接触这个概念来自外企，当时觉得工程师薪水比VP高，在国内是件挺稀罕的事情。这里有篇由Sun员工创作技术人员的晋升路线，在软件技术领域具体有一定代表性。文中提到：
TechnicalIndividual Contributor(Professional)People ManagmentMember Technical Staff (1,2,3,4)Staff EngineerEngineering Manager 1Senior Staff EngineerEngineering Manager 2Distinguished Engineer (1,2,3)
Principal Engineer (1,2,3)DirectorFellow (1,2)Vice President (1,2)
严格基础训练到MTS4后开始做选择，继续做Engineer？还是换口味做Manager？基本经过之前的考验后，我们对自己都能有清醒认识，
两套体系都分别有对应层级，但再往后的进阶几乎已不是技术含量问题，而是我们的天份决定能走多远，说白了就是“性格决定命运。”并且在Senior位置上退休也不是什么丢人的事情。
给雅虎干活时，了解到雇员也有P和M两套晋升体系，P代表professional，M代表managment。分别用数字代表level高低，涵盖了做设计和工程的两类技术雇员。相比Sun不够细致，但也许更适合互联网公司的高速发展。结合Sun的经验，个人认为合理的产品团队组织结构如下：
ProductProfessionalManagmentMember Design Staff (1,2,3,4)Staff DesignerProduct ManagerSenior Staff DesignerSenior Product ManagerChief DesignerDirectorArtistVice President产品专业管理设计专员 (1,2,3,4)高级设计师产品经理资深设计师资深产品经理首席设计师产品总监艺术家产品副总裁设计“师”不是随便说的，产品设计师里再细分职能的信息架构师、交互设计师、界面设计师、视觉设计师根据团队，以及产品要求制定。也就是个名片上的title问题，通常不建议划入组织体系。因为强大而灵活的团队中，设计师职能可能会变，而且兼多个职能也正常。
现实中最常见的问题是专业人员不服管，有两种可能：一是M的管理手段太弱，喜欢对P发号施令而无法协调，经常被顶撞；二是M的理论基础太菜，与P没有共同语言而无法沟通，经常被鄙视。要知道在团队里，只有英雄之间才可能惺惺相惜，中国传统文化更讲究“士为知己者死。”
比较崇拜的收藏家马未都先生在访谈中提到“我不大善于跟人复杂的交往，我希望单纯，但是人对人之间一定是复杂的，人都物之间就显得简单。”我想真正的设计师听了都会很有感触，因为只有与事和物打交道，拼的才全是我们自己的能量。
挺瞧不起这个“管理是一门艺术”的说法，好像做管理是个很牛的差事似的。这不废话嘛，任何事情做到高处都是艺术，中国古代经典类似说法多去了。真正的Professional应该懂得如何看无字书，如何弹无弦琴，理论和创新都值得一辈子去实践，积累和沉淀才是王道。
原文链接：blog.rexsong.com/?p=6054
篇7：互联网产品经理和原型设计交互设计
一个合格的互联网产品经理在向技术部提交产品策划方案时，除了详尽的需求说明外，还必须提供清晰易懂的产品原型设计(Prototype Design)方案，优秀的原型设计不仅方便在前期进行研讨，也可以更好的帮助美工和开发人员理解产品特性，从而节省时间，提高效率，以下简单聊几句产品经理和原型设计，希望和大家多多交流。
原型设计是什么
产品原型简单的说就是产品设计成形之前的一个简单框架，对网站来讲，就是将页面模块、元素进行粗放式的排版和布局，深入一些，还会加入一些交互性的元素，使其更加具体、形象和生动。
原型设计应该是UI、UE设计师的事情？
这是很多人的一个误解，UI、UE设计师是将原型做成实际页面效果的角色，他们的工作流程应该在原型设计之后展开。通常来讲，产品经理才是整个流程中最了解产品特性，最了解用户和市场需求的角色，设计师从设计的角度也许能做得很出色，但是对于产品、用户、市场、业务的理解远不如产品经理深入，准确的讲设计师做的是视觉设计，是将产品原型设计成产品经理的预期状态。如果产品经理只是有个idea，而让设计师去发挥的话，只会让产品经理和设计师反复纠缠，反复修改，举个例子：淘宝很炫耀的搬出了业务部主管折磨设计师的案例，实际上这是缺乏产品经理这个角色，或者说产品经理不称职和设计师沟通不够导致的后果。
原型设计如何体现？
纸质：很多人比较推崇纸质原型设计，就是用笔和纸进行产品原型描绘（白板也常常起到类似的作用），不过我认为这只是产品经理进行原型构思阶段使用的最佳方式，不过这才是原型设计的第一步，构思和框架基本确定之后，就需要将这个“纸上谈兵”的框架转移到更形象直观的电子文档上，便于后续的研讨、设计、开发和备案。
WORD：这是原型设计时常用的一种方式，在WORD文档建立一块画布，用文本框、图片、控件等等组合起来形成一个原型设计方案。WORD文档门槛低，使用方便，功能效果丰富，如果一个熟练者甚至可以达到一个很好的类似实际页面的表现力，我的同事做出来的原型连设计师都夸奖它好比PS设计图一般(不过原型设计不讲求美观，不推荐花费过多精力去修饰)。但是WORD文档的WEB控件不是太好用，交互性也较弱。
VISIO：这也是常用的原型设计工具，它的操作比WORD更加方便快捷，可以进行快速原型设计，但表现力弱一些，毕竟它不是专门的网页原型设计工具。
Photoshop：也有人使用，不过用PS进行原型设计，费时费力，改动很不方便，容易降低效率，PM还是不要抢了UI设计师的饭碗。
Dreamweaver：这是网页设计工具，但是对于功能复杂并且交互性很强的产品，可以通过DW去设计简单的HTML交互稿，这样更有说服力。
专业原型设计工具：iRise Studio、Axure RP Pro、Mockup Screens等都是不错的原型设计工具，不仅具有丰富的web控件，交互性也做得很好，其中Axure RP Pro算是其中的佼佼者，不过都是商业软件，都是E文，而且使用起来复杂一些。
不同的公司，不同的团队，对于互联网产品的原型设计可能采用的方式会大相径庭，不一定非得使用某种固定的方式，最适合自己的才是最好的。
产品经理需要具备什么样的素质：
产品经理应该是公司综合素质要求最高的一个角色，他必须具备一定的调研能力，也必须具备良好的洞察力、分析力、策划力；他需要懂得市场和用户，也需要懂得产品和内容，甚至还需要懂得公司的战略和运营；另外还要懂得一些设计和程序开发，最后也少不了优秀的组织、协调能力和团队管理能力。可以说产品经理绝不是每样都精通，但肯定应该是样样都懂，他集中了公司所有团队的才干于一身。
当然对于创业团队来讲，有时不可避免的会一个人身兼数职，原型设计也比较随意和主观，但是到公司成长到一定阶段，Product、UI、UE、Porgam都需要明确的分工。另外现在有一种倾向就是大家越来越重视UI、UE，却忽视了产品的源头：产品经理，对于中型公司来讲，产品经理才是公司的核心，一个优秀的产品经理会让产品设计开发事半功倍，但是一个蹩脚的产品经理也会让产品陷入困境。
最后简单总结几句：
产品经理也许不是专才，但一定是全才
产品经理不是万能的，他的策划文案和原型设计方案也需要经过多次的修改完善
原型设计注定是要用来修改和完善的，不要花费太多精力在原型的外观美化上，除非你本来就很擅长外观设计
不强制你使用某种工具，但需要找到适合自己的原型设计工具；
Comments on “互联网产品经理和原型设计”
fakejobs
01月 25th, 2008 at 1:28 pm
我也是产品经理，但完全不同意你的观点：
1.首先你对原型的解释就不够理解原型的意义，“就是将页面模块、元素进行粗放式的排版和布局”这里不过是原型的构思阶段罢了，很适合用纸质原型，但是如果你拿着这份东西交给视觉设计师，保证做出来的产品恐怕是失败的。因为视觉设计师不理解你为什么要这样设计，究竟要表达什么，也看不到整个产品的全貌。
2.“加入一些交互性的元素，使其更加具体、形象和生动”，这句话可见你对交互的理解有些片面，首先“交互性的元素”就是一个歧义词，“Getting input from users”、“Dealing with data”的元素是不是都算交互性元素？其次，交互元素不是应该后期加入的，你先画了框架，再画交互过程，这样的产品已经脱离了用户的使用的流，而是你头脑中设想的框架，仍不算交互产品。再次，加入你所谓的交互性元素，不是为了形象生动，你已经忘了用户的task，还口口声声说最了解用户有什么意义呢？你只能了解用户是谁，但对用户要做什么完全遗忘了。
3.“UI、UE设计师是将原型做成实际页面效果的角色，他们的工作流程应该在原型设计之后展开”如果是这样，那么这个产品必定失败。我以为好的产品经理应该尽早把自己的想法传递给项目中的每一个人，并尽最大努力完成自己的那部分职责，你应该知道UE知识、运营知识，但是不要以为自己是这方面的专家。每个人都不能集中了公司所有团队的才干于一身的，这是一个最基本的事实。
4.如果你想成为一个好的产品经理，起码先管理好这个blog，
比如，这个留言框如此之小，你自己有用过吗？这个细节就阻止了想留很多话的用户——如果你画原型图，你能注意到这个问题吗？
5.再比如，每篇文章的留言上面都有红色的链接“read more”，这个链接是做什么的？我已经打开了具体的post，为什么还要read more？点进去还是本篇文章——如果你画原型图的时候，为什么不考虑这样的细节？
6.结论：不要以为画原型图是一件很简单的事情，交给专业的人去做，不管这个人的头衔是产品经理也好、UE也好、PM也好，只要他具备专业的知识。
狂风
01月 25th, 2008 at 2:18 pm
fakejobs，有些误解，这里主要探讨的是原型设计部分，不涉及产品策划的其他流程，另外原型设计设计只是需求规划的第一步和UE设计师收到方案进行初稿设计完全是两个阶段。
1、原型设计只是产品策划方案里面的一部分，提交给设计师的当然不只是一份原型设计这么简单，这里没有谈论产品策划只是谈论其中的原型设计部分如何做。
2、加入交互性元素是在条件允许的情况下，加入原型设计的，例如使用axure就可以在原型设计里面加入交互功能，只是为了让原型设计可以表现更充分，而普通的WORD文档、图片等还不具备这个条件，实际上大部分原型设计是不便于表现交互性元素的。而要完全阐释产品的交互，是需要通过流程图、框架图、需求说明文档、甚至HTML页面、PPT、FLASH等其他形式和手段来实现。这里也不是讨论交互产品的完整设计过程，只是讨论“原型设计”部分能够充分表达出来的东西。
3、产品经理只是做简单的原型设计，可以说还只是一个框架图，直接点讲就是阐释一个需求，在前期需求规划部分，产品经理可以调查市场、发动公司其他部门进行研讨、方案决策，最后再形成产品策划方案提交给设计或开发部门。我讲过“原型设计注定是要用来修改和完善的”，这之后还需要同设计部、开发部进行不断的沟通、修正、完善。
我也说过产品经理需要有综合的素质，但不是说他每样都很精通，更需要的是广博而不是专业，他缺乏或者不擅长的地方，需要懂得如何组织、协调、调动其他资源来帮助自己完善产品方案。
4、5、这个blog不是我设计的模板，这些细节也不是我规划的，真的很忙，不想耗费太多时间在这些模板修改上面，不好用随时更换其他模板就好了，最近blog更新比较少，加上只是属于个人的地盘，更换模板后没有细致检查，改天再换一个，另外程序升级后blog分类都丢失了，现在还没有时间去找回来呢。
6、原型图是谁来做，是职位的归属问题，而不是专业问题，原型图不需要像实际页面那样美观，用visio、word作一些框架也同样是原型设计。也许有优秀的UEer，但是通常来讲UE设计师对市场、用户、产品的理解是没有产品经理或者PM强的，不要把产品需求部分的原型设计交给不属于他职能范围的设计师来做。只有在产品经理充分阐释并和设计师充分沟通后，UE做出来的产品才不会总是重复修改。
路人
01月 26th, 2008 at 2:26 pm
1) 我也曾是a品理，搞^0浮
2) 我比^J同「狂L」的{
3) u@ blog 的 UI 好不好用，有co聊
草香。
01月 27th, 2008 at 10:13 pm
同意一楼的观点
如果一定要说PM需要完成什么原型设计的话，那也是仅仅为了表达产品需求的一些概念图，对于设计团队来说仅将做参考意见，真正的原型设计，一定要按职能来分的话，绝对是设计团队的份内事~
PM的重点是将业务需求提炼，控制好整个产品的进度，协调统一好各方面有效率得做事，而不是去业余地做一些专业的事，导致文中提到的“一个蹩脚的产品经理也会让产品陷入困境”。
狂风
01月 28th, 2008 at 2:17 am
草香的观点没错啊，PM只是做原始的结构，不过原型设计的保真度越高，越有助于表达观点和让技术人员理解。
在海内有个产品经理的群组，里面讨论产品经理使用的工具时提到使用Axure RP Pro进行原型设计的比较多，并且呈上升趋势。
www.hainei.com/topic?r[0]=101194&r[1]=101936
另外也有延续本篇blog话题：产品经理和原型设计的讨论
www.hainei.com/topic?r[0]=101194&r[1]=111456
soune
01月 28th, 2008 at 10:06 am
产品经理通过word做出ue图，然后把产品理念和具体的功能需求给团队里的人详细讲解一遍，会后发个需求list足够了。哪里有那麽多闲工夫做这么详细的产品模型啊！一看就是一个低效率的做事方法，我对你的产品经验表示怀疑。其实，靠一个产品模型根本解决不了什么问题，再详细也不行，必须通过需求会议和开发过程中与工程师的不断沟通才能达到高效，保真的产品开发。高效啊！
同时你的blog体验确实不好，写了半天一提交全没了，原来网名和电邮是必填的。建议改为模式框提醒的方式。
Lunatic Sun
01月 30th, 2008 at 12:26 pm
互联网产品团队是需要视情况而定的，大产品需要大团队，小产品只需要小团队，如果资金量大，团队人手足够，那产品经理没有必要提供prototype，架构prototype应该是information architect的事情，但是如果你只是一个小团队，资金量小，产品规模小，那么产品经理要做的事情甚至可能牵涉到后台开发。因为广义的经理是个非常宽泛的概念，而狭义的产品经理我觉得不应该去关注太多技术细节，他是一个掌舵者，而不是一个水手。
斤斤
02月 14th, 2008 at 12:27 pm
个人感觉讨论到了最后变成 工具讨论了。先做好产品经理应该有的基本功比较好。工具嘛，是纸，是文档，是图都没有什麽关系，只要能够让别人了解就可以了。更重要的是产品本身的应有和运营。
来自：www.kuangfeng.cn/blog/?p=1460
★ 教学设计过程
★ 教学过程设计
★ 产品分享范文
★ 互联网演讲稿
★ 互联网语录
★ 互联网简历范文
互联网产品过程设计控制流程图（共7篇）
