名称下面的网站介绍内容怎么改(与产品经理的工作密切相关的3种*敏*感*词*：功能*敏*感*词*、信息*敏*感*词*)

　　名称下面的网站介绍内容怎么改(与产品经理的工作密切相关的3种*敏*感*词*：功能*敏*感*词*、信息*敏*感*词*)

　　功能设计是原型设计之前的关键步骤。这一步需要对功能进行拆解，梳理其逻辑和流程，梳理功能结构和产品逻辑。其中，除了常用的流程图，各种*敏*感*词*也是产品经理需要经常绘制的图表之一。在本期文章中，作者分享了三种绘制*敏*感*词*的方法，希望对大家有所帮助。

　　

　　分析、整理、沟通、讨论和表达需求，是产品经理每天都在做的事情，而且消耗大量精力。如何更有效、更准确地完成这些任务，是产品经理的必修课。

　　图表作为比文字更直观、更真实的表达方式，具有很强的感知性，在产品经理的工具箱中占有重要地位。

　　俗话说：一张图抵千言。

　　今天我们来看看与产品经理工作密切相关的三种*敏*感*词*：功能*敏*感*词*、信息*敏*感*词*、产品*敏*感*词*。

　　一、功能*敏*感*词*

　　百度对功能*敏*感*词*的定义是：功能*敏*感*词*是按照功能从属关系绘制的图，图中的每个方框称为一个功能模块。功能模块可根据具体情况分为更大或更小。分解出来的最小的功能模块可以是程序中的各个处理过程，而较大的功能模块可以是完成某项任务的一组程序。

　　通俗地讲，功能*敏*感*词*就是以功能模块为类别，介绍模块下各个功能的组成部分的图。功能*敏*感*词*一般不涉及具体的领域信息，只强调功能的逻辑关系。

　　

　　功能*敏*感*词*主要用于新产品/新功能的概念创意阶段或绘制竞品拆解/整理现有产品。主要帮助产品经理根据对业务的理解梳理功能，为下一步产品架构设计、编写需求文档、绘制产品原型提供依据。

　　具体来说，功能*敏*感*词*的功能有：

　　产品概念设计中使用的工具之一。在绘图的过程中，可以帮助产品经理思考和明确产品的功能模块和功能组件。梳理需求。对整个产品的功能结构形成鸟瞰的直观认识，防止在将业务需求转化为功能需求的过程中出现功能模块和功能点缺失的现象。

　　绘制功能*敏*感*词*最重要的前提是对业务有深刻的理解。只有对业务有足够清晰的了解，才有可能绘制出合适的功能*敏*感*词*。

　　有人说功能*敏*感*词*主要看有哪些Tabs，然后逐渐深入展开，最终组织形成功能*敏*感*词*。

　　进一步补充说，当一个辅助功能模块在不同的Tab功能模块中重复出现时，我们可以考虑将其拆分为主要功能模块。

　　但实际上，无论是做新产品/新功能，还是拆解分析竞品/功能，首先要明白一件事：功能*敏*感*词*是从产品角度的鸟瞰图从上帝的角度来看经理。产品功能系统的机会。

　　这里要关注的重要一点是“业务视角”。

　　产品/功能来自业务，是实现业务逻辑/业务规则的媒介。作为体现这种媒介的全球性文档，绘制功能*敏*感*词*当然是从业务角度来梳理，而不是从产品角度来梳理，所以上述功能*敏*感*词*以Tab为主，其他说法不妥。方向颠倒了，或者因果颠倒了。

　　鸟瞰图是基于业务的功能系统的鸟瞰图，而不是产品系统的鸟瞰图。在这一点上，我们经常会在不经意间犯错。

　　当你拿到一个新产品/新功能产品的工作时，你不会从整理业务开始，而是经常一起床就开始标签。这样做会导致返回修改工作量，增加延迟时间，最坏的情况下会导致产品的方向，以至于产品找不到目标用户。

　　对于新产品/新功能相关的工作，我们还是照做，但是当需要绘制功能*敏*感*词*拆解竞品/现有产品的组织时，从现有产品入手会更容易一些。

　　其实对于竞品的拆解/现有产品的组织，我们可以从现有产品入手了解产品，根据产品结构梳理产品功能了解业务，最后要全面把握业务逻辑/业务规则。从业务角度，梳理功能*敏*感*词*。

　　在这个过程中，从产品结构入手只是帮助我们快速了解业务的一种方式，绝不能作为最终结果。

　　前面我们提到了“合适”的功能*敏*感*词*，那么如何判断绘制的功能*敏*感*词*是否合适呢？

　　一般来说，除非公司和产品有重大的战略调整，其主要功能模块不会发生变化，往往是一些分支机构的增删。这样的功能*敏*感*词*具有很强的可扩展性，可以适应较长时期内的开发需要。

　　但是，如果是不合适的功能*敏*感*词*，遇到的最大问题是主功能模块或子级重要功能模块的大调整，往往会感觉功能结构框架经过一个相对的调整后还没有适应。很短的时间。发展需要。

　　在这种情况下，实际上从一开始就不清楚业务重点和优先级是什么。

　　绘制功能*敏*感*词*时如何把握粒度？

　　一般主要功能模块不宜过多，以免区分主次，5到9个为佳。

　　无论一个产品多么复杂，都可以提取出最重要的部分来指导我们把最重要的时间和精力放在哪里，告诉用户我们提供的最重要的产品和服务是什么。

　　从主要功能模块，有经验的产品经理可以一目了然地看到这款产品的调性、方向和主旋律。在级别上，2-3级为宜。

　　功能*敏*感*词*的绘制是产品经理的思维从发散趋于收敛的过程。一开始的粒度一般比较大，可能只涉及到某个功能模块。随着工作的进行，功能*敏*感*词*的粒度会不断细化，最终可以拆分成具体的功能操作。等级最好控制在3级以内，再细分也没有意义。功能*敏*感*词*的主要目的是将整个功能系统描述为一个整体。

　　二、信息*敏*感*词*

　　在我们生活的信息社会中，存在着强烈的信息爆炸感。对于一个互联网产品来说，它也收录了很多信息。

　　互联网产品大致可以分为工具类和内容类（一个产品并不绝对属于某一类，比如微信，即时通讯可以看成是一种交流工具，朋友圈可以看成是社交内容）。对于基于内容的产品，信息将更加多样化和复杂。但不管是哪一种，互联网产品本质上都是“信息”产品。

　　并且信息是结构化的。

　　大家写简历的时候，其实就是将个人相关信息整理成结构化信息的过程。

　　每个人的简历一般都会包括姓名、性别、民族、籍贯、出生日期、*敏*感*词*号码、*敏*感*词*、工作单位、工作时间、职位、收入、离职原因、*敏*感*词**敏*感*词*、学习时间、学习情况。专业、证书等信息

　　信息量这么多，如果在这里一一列出来就很复杂了。

　　但是我们可以把它整理成以下几组，看起来就容易多了：

　　基本信息（姓名、性别、种族、原籍地、出生日期、*敏*感*词*号码、*敏*感*词*）；*敏*感*词*（工作单位、工作时间、职位、收入、离职原因）；教育经历（毕业院校、学习时间）、学习的专业、获得的证书）。

　　当信息被结构化和整理后，它会更清晰，更有条理。

　　从中我们可以看出，上述信息是对对象“人”的结构化信息描述。

　　信息*敏*感*词*是按照上述方法对业务中的对象进行整理形成的结构化信息图：

　　

　　在绘制信息*敏*感*词*时，我们需要注意：信息*敏*感*词*与页面和交互无关。

　　有些产品经理在绘制信息*敏*感*词*的时候，会按照页面结构逐级列出信息，这是完全错误的。正如前面的功能*敏*感*词*是从业务角度对功能系统的鸟瞰图一样，信息*敏*感*词*也是从业务角度对信息系统的鸟瞰图。

　　信息*敏*感*词*中同一对象的信息出现在多个页面上是很常见的。

　　如上所述，招聘人员在使用 Recruit网站 时，姓名、性别、年龄、职位、工作时间等关键信息会同时出现在候选人列表页面和候选人列表页面上。详情页，也会出现在搜索结果页等。实际上，与该对象相关的所有页面都会在信息*敏*感*词*中使用有关该对象的部分/全部信息。

　　所以，我们可以看到信息是跨页面、跨功能的。

　　信息*敏*感*词*有点类似于编程中的数据表结构设计，它揭示了需要哪些数据，这些数据需要具备哪些元素，才能实现各个功能模块需要展现的内容表达。如果说功能*敏*感*词*是产品的功能抽象，那么信息*敏*感*词*就是产品的数据抽象。

　　俗话说，聪明女人没有饭很难做饭，“做饭”是功能，“饭”是信息。如果你有米饭，你可以做饭。用户每次使用产品，都是功能和信息的结合。用户浏览信息后执行动作，或执行某个动作后获取信息后浏览。

　　那么我们为什么要画信息*敏*感*词*呢？

　　这是因为我们的大脑容量是有限的，信息是跨页面、跨功能的。

　　如果一个对象只关联一页，那么我们可以轻松完成方案设计，不会出现信息遗漏和混乱。

　　但是，这种情况很少见。在大多数情况下，一个对象与多个页面相关联。此时，对象的信息往往是丰富的。

　　在脑容量有限的情况下，如果仅凭记忆逐页绘制原型，最终很可能会出现信息遗漏和混乱，由此产生的产品方案自然会漏洞百出。

　　这时，信息*敏*感*词*是产品经理的重要工具。

　　有了它，在设计具体的页面、交互、功能时，我们只需要对比信息*敏*感*词*，通过对用户使用场景的分析，从信息*敏*感*词*中，选择每个页面和交互需要用到的信息，并在完成详细的原型设计后，可以高效、合乎逻辑、不遗漏地完成产品方案设计。

　　信息*敏*感*词*除了对产品经理自身的工作有所帮助外，还可以为开发人员设计数据库表结构提供参考。

　　在信息方面，产品经理关注业务涉及哪些对象，每个对象有哪些信息。开发者重点关注实现方式，需要设计什么样的技术架构，有哪些数据表，表结构是什么，后续字段是否需要扩展等等。

　　如果没有信息*敏*感*词*，当开发者得到一个完整的产品方案时，需要从功能、页面、交互中抽象出几个“对象”，然后将这些对象所涉及的信息域穷尽。根据数据表设计的要求，添加一些独特的字段，完成数据表的设计。

　　如果有信息*敏*感*词*，那么开发者可以很快的了解以上信息。

　　当然，信息*敏*感*词*的意义是顺带的。产品经理绝对没有必要为了开发者而画信息*敏*感*词*。毕竟开发者非常擅长数据抽取，效率可能会更高。

　　三、产品结构

　　在开始讲产品*敏*感*词*之前，我们必须清楚地认识到一件事：前面的所有内容还没有涉及到产品设计，也就是说，从业务的角度来看，它仍然是一系列的工作。这时候，连产品的影子都还没有看到。从产品*敏*感*词*开始，产品经理的产品设计之旅就开始了。

　　产品*敏*感*词*是综合展示产品信息和功能逻辑的图表。是功能和信息按照一定的层次和逻辑关系有机组合而成的产品原型。

　　之所以说是原型机，也是因为此时还无法看到所有的细节。

　　简单地说，产品*敏*感*词*是产品原型的简化表示。

　　产品*敏*感*词*是将功能和信息以合理、自然的逻辑放入产品每一页的结果，是产品概念设计最后阶段的产物。

　　

　　有人认为产品*敏*感*词*是在功能*敏*感*词*的基础上，在信息*敏*感*词*中添加信息，认为产品*敏*感*词*=功能*敏*感*词*+信息*敏*感*词*。

　　我不同意这种说法。

　　既然是产品原型的简化表达，肯定是已经经过产品设计的，而且功能*敏*感*词*和信息*敏*感*词*都还停留在业务层面，简单的叠加并不能直接生成产品*敏*感*词*。

　　事实上，产品*敏*感*词*是产品经理从业务层面落地到产品层面的重要流程。经过这个过程，可以看到产品的主页面结构和基本信息，可以看到产品的基本轮廓。

　　既然未来需要做产品原型，而且看起来产品原型是必不可少的，那么产品*敏*感*词*的作用是什么呢？

　　产品*敏*感*词*可以在早期需求评审或其他类似场景中作为产品原型的替代品——因为产品*敏*感*词*的实现成本比产品原型低，并且可以快速添加、删除、修改产品功能结构。，降低产品经理在此过程中的变现成本；同时可以指导产品原型的制作，以产品*敏*感*词*作为绘制产品原型的依据，可以避免我们在绘制产品设计的同时进行改动，跳入只能看细节，但看不到森林。陷阱。

　　此外，产品*敏*感*词*也是产品与研发沟通的桥梁，便于研发前期评估发展计划。

　　现在总结一下：

　　很多产品经理说这三个是*敏*感*词*，容易混淆。怎样才能更容易区分和加深理解？

　　事实上，这很简单。由于后面的“*敏*感*词*”三个字是一样的，所以重点一定要放在前两个字上。

　　函数*敏*感*词*，关键词是函数，是函数的结构化表达；信息*敏*感*词*，关键词是信息，是信息的结构化表达；产品*敏*感*词*，关键词是产品，是产品的结构化表达。这里的产品就是产品经理每天说的产品。

　　想一想，是不是一下子就明白了？

　　四、怎么画

　　细心的读者会发现，上面说了这么多，却没有说这些图是怎么画出来的。以下为统一说明。之所以把它们放在一起，是因为它们之间的相关性比较强。实际上，它们的绘制顺序是：功能*敏*感*词*->信息*敏*感*词*->产品*敏*感*词*。

　　先画一个功能*敏*感*词*。

　　要绘制功能*敏*感*词*，我们必须知道有哪些功能。而且因为功能是承载业务的方式，所以我们必须详细了解业务。针对每个场景，通过抽象关键业务节点或操作，梳理业务流程，划分功能模块。

　　列出业务闭环所需的功能点，找出从属关系和层次结构，从粗到细的粒度绘制功能*敏*感*词*。命名可以采用“动词+名词”的形式。

　　功能*敏*感*词*的最小粒子要根据实际情况来把握。如果功能很复杂，可以划分为一定的粒度，不一定是最小的粒子。往上看。

　　绘制功能*敏*感*词*后，绘制信息*敏*感*词*。

　　在绘制信息*敏*感*词*时，有一个问题需要思考：在所有场景中，都涉及到哪些对象？

　　信息*敏*感*词*描述了对象。首先，我们需要对对象进行分析和抽象。

　　一个函数可能涉及多个对象，也可能涉及多个对象。这些对象是构成功能的信息内容。

　　指定对象后，接下来就是梳理需要哪些字段来描述对象。

　　这里需要注意的是，描述一个对象的字段可能很多，但并不是所有的字段都需要绘制到信息*敏*感*词*中，只需要收录业务和功能需要的字段即可。

　　梳理字段时，既不能遗漏某些字段，也不能收录冗余字段。

　　对于当前未使用但将来需要的字段，需要收录它们。

　　有了功能*敏*感*词*和信息*敏*感*词*，我们就可以在此基础上画出产品*敏*感*词*。绘制产品*敏*感*词*，需要从全局的角度对功能进行分类和分层，抽象出产品框架。

　　这个产品框架很重要，一个好的产品框架是高度可扩展的。如果你观察微信，你会发现，经过这么多年的发展和这么多版本的迭代，它的产品框架基本没有太大变化。

　　明确产品框架后，可以在每个需要体现内容数据的节点上添加所需的数据描述。

　　至于交互动作的细节，不需要在产品*敏*感*词*中体现，比如页面布局细节、交互手势、*敏*感*词*效果等，属于交互设计的范畴。

　　在画产品*敏*感*词*的时候，你要想象这是你产品的最终形态，每个页面应该有什么功能和数据，类似于开发开发的不同的静态页面，展现在你面前的是产品的原型。

　　一个产品/需求从构思、构思到最终输出再到设计和开发，不一定会用到上述所有类型的图表，你可以根据情况选择使用。如果产品比较简单或者是有经验的产品经理，如果高层没有提出相关的汇报要求，往往可以省略一些图表。

　　另外，有些图是产品经理工作流程本身的中间产物，一般不输出。为了节省时间和提高效率，产品经理经常使用白纸和钢笔在没有工具的情况下进行手绘。整理成文档。

　　所有图表都只是工具。它们应该灵活使用。只要它们可以对您的工作产生积极影响，就可以使用它们。您不必为了保留而保留它们。不要被工具框住或限制。