互联网产品中的邀请机制交互设计

由Zzhao 分享时间：2022-03-25 07:25:23 收藏本文

【简介】感谢网友“Zzhao”参与投稿，以下是小编为大家准备了互联网产品中的邀请机制交互设计（共5篇），欢迎参阅。

篇1：互联网产品中的邀请机制交互设计

邀请机制？我的第一反应就是Gmail，最早拥有Gmail帐户的同学都是在焦急和期待中过来的，渐渐，这种方式被互联网产品延续开来，进而形成一种模式。这种看似“朴实”的方法背后，隐含着的却是一整套周密的商业模式。在吊足用户胃口同时，大赚口碑和关注度，名利兼收。可邀请不是谁都能发的，你得先确认自己有那个范儿。

什么样的网站适合利用邀请机制

首先有一定得品牌影响力，再利用邀请机制吸引用户就等同于广告，而这种广告是用户的口碑传播，转化率很高。

如果是新入行的网站，使用邀请要慎重，本来就啥也没有呢，再给自己加个门槛，当心自己把自己玩死。

垂直型、内容足够有吸引力的网站除外。这种网站不重用户数量，重质量。

互联网产品中的邀请

邀请使用新产品，

通过邀请码、邀请信等，让新用户获得使用新产品的机会。

邀请使用产品功能、参与互动。如SNS中邀请好友加入某游戏一起使用。

从邀请机制中得到了什么

普通用户。一来是虚荣心驱使，先体验了某个抢手产品后心理上的优越，有炫耀的成分；二来是利益驱使，邀请好友加入社交网站游戏以获得更多游戏币。

网站。获得了口碑、知名度和关注度等。得到更多用户才是网站盈利的基础。

邀请机制也是一种营销手段，在产品设计初期就有一个配套的营销运营方案，会让产品更有计划的展现给用户，在生命周期中良性迭代。

本文来自：blog.b3inside.com/essay/invitation-mechanism-for-internet-products/

篇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：互联网产品设计师职业生涯交互设计

其实这个话题已经在侧面写了好几篇深刻反思，用我自己几年工作实践的体会来看，性格决定了将来的发展，某些特质虽然可以掩饰，但在这之上必然不可能有大作为。

我是典型极简主义（包括沟通），而且对事物相当有耐性的极端完美主义性格，擅长追本溯源。当我真正意识到自己性格特质的时候，便开始在工作中有意做取舍。很多事情不是做不到，而是成本太高，性价比又太低。

产品经理不是唯一选择

个人认为不管软件领域还是互联网领域，产品做不好的根源，主要是缺乏Senior专业技术人员，但更重要的是业余管理人员泛滥。这也许是任何行业、技术高速发展中，不可避免的问题。

曾在产品经理的责任中提到“设计做的再好不一定能胜任产品经理，因为两者的职业素质和职责不同。”在软件领域还有个说法“国内软件做不好，是因为很多人刚在技术、业务上小有积累、小有成就，就忙不迭去做管理、开公司，觉得那才是提升。”

归根结底，前不久鲍鹏山老师点评武松的那个观点也许值得我们认真反思“中国文化中很不好的一面，就是人人都特别看重体制里面的位置，把这些东西看成是自我的最高价值。”

管理与专业是两条路

最早接触这个概念来自外企，当时觉得工程师薪水比VP高，在国内是件挺稀罕的事情。这里有篇由Sun员工创作技术人员的晋升路线，在软件技术领域具体有一定代表性。文中提到：

Technical

Individual 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

篇4：互联网产品经理和原型设计交互设计

一个合格的互联网产品经理在向技术部提交产品策划方案时，除了详尽的需求说明外，还必须提供清晰易懂的产品原型设计(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, 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