在SCRM系统中，线索管理是不可忽视的功能之一，而线索管理还可以分为线索收集、清洗、流转等步骤。而在线索流转步骤中，公海模块是不容忽视的模块，企业往往可以结合这一模块来提升线索利用效率。那么，SCRM中的公海模块应该怎么设计呢？一起来看看作者的分析。

SCRM系统中最重要的功能可能就是线索管理了，按照先后顺序主要分为如下几步：

• 线索收集，如广告投放、excel导入、手动添加等；
• 线索清洗：把不符合要求的线索过滤掉，重复的合并、缺失的字段补齐；
• 线索评估：量化线索价值或找出线索特征，为其打分、打标签、分类等；
• 线索流转：将线索按照一定规则下发及回收。

对于线索流转来说，最重要的模块就是公海了。

01

公海能干啥？

对于销售来说，可以从公海中获取自己想要的线索，也可以将自己不需要的线索扔到公海。

对于管理者来说，公海可作为一种压力型的管理工具。

对于企业来说，公海可以提升线索的利用效率。

举一个不恰当的比喻，如果把线索比作麻将，公海就是桌子中间那块区域，玩家可以从桌子中间的牌墙抓牌到自己手里（私人库存），也可将其他玩家打出的牌拿到自己手里，当然也可将自己的牌打出。

总之，公海是线索流转的中间站。

02

如何建立一个公海呢？

不妨先思考一下公海这个客观主体，会和哪些主体产生关联：

• 线索：公海和线索之间，涉及到线索的进入和流出、线索信息的维护；
• 管理者：管理者创建公海并制定公海规则；
• 销售：从公海领取线索或将线索扔回公海。

具体到公海如何关联主体，就是产品功能了。

推断公海的功能模块可能有：

1. 公海信息

管理员创建公海，需要设置公海基础信息，如公海名称和备注等。

公海中需要有线索，管理员需要考虑线索从哪里来，所以必须为管理员提供上传数据的功能，如果必要，公海还需有承接通过广告投放获取到的线索的功能；当公海中线索过多或有太多垃圾线索时，需要管理员有删除线索的功能。

公海中的线索肯定不能面向所有的员工，所以管理员需要设置权限即哪些人是公海成员。

由此我们可以获得一个大致的功能列表：

2. 分配线索

分配线索，就是将线索从公海移到销售的私人库存里。

主要考虑：什么时候分、怎么分、分什么：

• （when）什么时候分：也就是员工主动领取、管理员手工分配、系统自动分配；
• （how）怎么分：分配顺序、什么线索分给什么样的销售；
• （what）分什么：需要圈定线索进行分配，或者全部线索分配。

3. 线索回收

线索回收的目的主要有2个：

1. 给销售压力，让销售在某一时间段内完成某个有效行为，如果完不成则会把线索回收；
2. 活水线索资源，让销售去跟踪与其相符合的线索；如，将价值更高的新资源分给销售经验丰富的销售，将跟踪过的旧资源回收到公海，分给新入职的销售。

“时间段内”与“有效行为”可以组合成多个回收的规则，同时也要确定线索回收的目的地：

4. 总

与其他模块一样，都需要有数据记录、数据统计、异常情况、权限的考虑，将其与之前的内容汇总到一起，可得到一个公海的功能列表：

在产品设计的工作流程中，设计师有时也需要参与到需求评审、需求设计等阶段中，这个时候，设计师要怎么避开需求评审或需求对接中的“坑”？本文作者便结合自身经验进行了总结分享，一起来看看吧。

通常设计师会参与到需求评审、需求设计、设计评审、研发跟进、设计验收几个阶段。在每一个阶段，设计师应该都踩过“坑”，本文主要复盘作者在需求评审（需求对接）里遇到的典型问题，并分享解决办法。

需求评审时需要思考哪一些内容：

1. 需求背景是什么（用户是谁、遇到什么问题、怎么解决问题）。
2. 需求上线想要达成什么样的目标（量化指标）。
3. （产品介绍方案后）初步思考功能能不能实际解决背景里阐述的问题，有疑惑及时提出。
4. 初步思考实现方式，若产品方案和设计师的认知有很大偏差的情况下，及时提出，避免设计师按照自己的想法修改后方案被pass，因为产品可能基于某方面考量，不得已选择此实现方案。
5. 确定交付日期，避免产品经理疯狂催稿（因为设计师可能不止对接一个产品，但是有的产品会想当然你接下需求就马上开始做，并且给你主观预估交稿时间）。若交付时间比较紧，来不及完成，可以和设计师商量先完成一部分交付进行开发，后续在补交未完成部分。

一、需求价值不明确

背景：每个季度员工需要填写KPI和KPI完成情况，季度末领导对员工绩效完成情况进行评定，若员工对评定结果不满意，可以发起绩效申诉，然后由HR邀约员工和领导进行面谈，并填写通知申诉结果。

问题：绩效申诉在整个公司一年大约0-3起，使用率非常低，值得做吗？

方法：针对此类型的需求，思考3个方面。

1. 该功能能帮助用户解决什么样的问题，是否符合产品目标（降本增效）。
2. 用户量有多少？使用是否频繁？
3. 需求投入人力和实际功能上线后带来的价值是否成正比。

*当然一切的方法都敌不过领导或者需求方的我就是要这个功能，如果需求不合理但是非做不可的情况，可以根据紧急程度适当调整优先级。

应用：

• 该功能能帮助用户解决什么样的问题，是否符合产品目标（降本增效）——该功能能够帮助员工更便捷申诉、HR更快的查看申诉资料。
• 用户量有多少——申诉的用户是全公司，处理HR是固定的几个人之一。
• 需求投入人力和实际功能上线后带来的价值是否成正比——需求投入人力约48h+ 但是用户实际使用一年几分钟。

结论：1次申诉节约时间成本约4分钟（根据打字和手写速度估算，正常人手写每分钟25+字，电脑打字每分钟120+字），研发投入2880分钟需要处理720件申诉，花费约240年才能大概回本。

当然这个只是大概的估算，一方面HR团队和研发团队的薪资不同，无法直接对比时间成本，另一方面过程中可能有别的突发事情是不可预料的，比如申诉资料查找在电脑可能2分钟找到，但是纸质的可能丢失，又会带来一系列的问题，需要时间人力处理。

二、产品方案不合理，不考虑实际场景

背景：货运司机会根据车辆调度员的计划进行发车，也会有不在计划内的发车任务，因此设置了加班车&临时发车的入口，方便快捷登记。

问题：加班车和临时车都是在常规班车以外的特殊发车，是两个字段相似且不同性质的两个登记流程。但是产品经理的方案里只外露了加班车登记的入口，然后点击默认进入加班车登记，然后通过提交后校验，决定是否再转入临时车的流程。站在申请临时发车用户角度，没有直接入口操作非常不便。

方法：很多时候产品经理给的方案是未经探索和调研，只是功能层面的思考，功能走通即可。因此在对接产品需求的时候设计师需要有自己独立思考，学会不断提问（可以采用5WHY分析法）。

应用：

• 为什么要隐藏临时发车入口——因为加班车和临时车之间有逻辑需要校验。
• 这个逻辑是用户自己能判断，还是必须系统来校验——用户可以自己判断。
• 那用户想要直接申请临时发车的时候怎么办——只能先提交加班车，再提醒转入临时发车。
• 为什么不可以直接申请临时车——（支支吾吾……）。
• 临时发车申请的使用频率高吗——占场景的80%。

*在和产品对接的过程中，产品不清楚场景是一方面，可能还会基于不愿意承认自己错误这一心理要素，给你错误引导，所以设计师要学会根据业务理解、竞品、参考资料等独立思考，分析需求。

结论：B端是以效率为本，突出显示高频的操作按钮，可以帮助用户节省操作成本，提升产品满意度。

三、场景考虑不全面

背景：连续两次绩效不合格的人会被HR邀约面谈，制定接下来的改进计划，并在绩效改进中实时跟进改进结果。

问题：产品经理直接将线下的绩效改进表格发过来，然后告诉填写入口在哪里，就让设计师开始设计。表面看起来就是一个绩效改进填写的页面，但是其实流程涉及三类角色，每个角色入口，做的事情都不一样。

方法：可能基于时间关系和产品做事的风格不一样，有的需求拿到手里其实是非常表面的，需要设计师先梳理流程和角色，然后基于业务目标进行设计。

应用：

梳理流程：

梳理查看页面不同角色操作：

结论：这不是一个页面的设计，入口页、编辑页、查看页、通知，是一个闭环的流程的设计。

四、不清楚要什么

背景：财务总监想要做一个工作台，方便财务各个角色的人员可以快捷的通过工作台处理日常工作事项，财务管理者可以通过工作台直观的看数据，辅助管理。

问题：需求是财务总监传达给产品，但是并没有说明需要哪一些数据和内容，于是产品让设计除出了一版初稿给到财务总监，然后总监再找到对应角色去询问使用意见，设计再进行修改，然后再拿给财务总监确认。反复修改，设计成本高。

方法：业务不等于用户，有条件的情况下可以直接接触用户了解真实场景，没有条件的情况下可以通过业务代问用户拿到二手资料，大框架一定要提前制定，细节可以逐步完善。

应用：首先梳理工作台的角色有哪一些，综合考量角色的共性以及差异进行工作台草图绘制，然后拿着草图找到对应的角色去咨询意见并针对遇到的问题适当询问用户解决方案并修改，再找业务确认。

结论：如果产品或者需求方不清楚要什么的情况下，一定要找到真实用户询问场景和探讨解决方案。

五、简单视觉优化就可以

背景：产品经理因为上线时间紧，提前按照原型上线了看板内容，然后才截图发给设计师说就简单做下视觉优化。

问题：视觉优化只是好看就行吗？

方法：任何产品需求都建立在用户需求之上，设计要有理有据，不要脱离场景做设计。

结论：看板的需求其实和我们做其他需求一样，需要先了解背景，跟随业务目标进行信息的整理和布局，最后再做美化。如果你真的只是在现有界面基础上进行美化不考虑业务场景、交互逻辑，那么很有可能产出中看不中用的产品。

六、简单做，不考虑扩展性

背景：在一个项目中，功能会分期迭代，但是有的产品经理不管后续功能的扩展性，只考虑当前版本能够上线。

问题：后续功能上线后和前面的冲突，导致全部重新设计。新功能可能由于数据原因、流程原因、定位原因等，会导致页面的布局交互重新设计，重新开发，增加了人力成本。并且在时间紧急情况下，可能有的产品经理会选择不重构，错上加错，仅仅为了满足功能，忽视了体验。

方法：在接到需求设计时，我们应该充分考虑各种场景和产品后期规划，尽量保证产品扩展性，减少重新开发。

结论：不考虑拓展性很可能导致返工重新设计或者体验大打折扣，务必提前了解清楚规划，尽量避免。

如何去评判或衡量一个B端产品的架构方案设计是否合理？或许我们可以寻找适合B端产品的体验度量方案，并将B端产品使用体验作为评判依据之一。那么，常见的B端云产品常用的体验度量模型有哪些？来看看本文的总结分析。

B 端产品使用体验是衡量 B 端产品架构方案设计是否合理、产品是否好用的一个重要依据，也是提升产品竞争优势的重要因素。且 B 端产品具有链路冗长、操作复杂等特点，好的体验设计有助于降低用户上手门槛，提升用户体验。因此，度量 B 端产品的使用体验尤为重要。

但由于业务特征的差异，C 端产品较为成熟的体验度量方案很难直接搬用于 B 端产品，「寻找适合 B 端产品的体验度量方案」成为一个难点。

基于上述背景，本篇文章将介绍一些B 端云产品常用的体验度量模型，希望能为大家提供实践参考。

一、产品体验度量模型概览

行业中现有的 B 端产品体验度量方案有哪些呢？以指标数据的主客观属性为依据，可将体验度量方案划分为客观度量、主观度量和兼顾主客观度量三大类型。

客观度量主要是通过数据埋点监测用户行为数据，典型模型/指标如 PULSE 模型、活跃用户数、留存率、ARPU、LTV 等；

主观度量主要是收集用户对产品的主观评分，典型模型/指标包括 NPS、费力度、客户满意度指数、KANO 满意度模型等；

主客观兼顾度量则是结合用户行为数据和主观打分得到分值，并把分值划分成不同等级作为参考，典型模型包括 UES 模型、HEART 模型、GSM 模型、PTECH 模型等等。

图| 现有体验度量模型概览

从该分类可看出，互联网大厂目前使用的度量模型大多兼顾主客观数据，能够更全面地量化产品的使用体验。因此，本篇文章介绍的体验度量模型将聚焦于该类型，主要侧重于UES 模型的介绍，同时会简单地介绍下谷歌的HEART、GSM 模型和蚂蚁金服的 PTECH 模型。

二、UES理论模型介绍

1. UES 简介

UES（User Experience System）是阿里云设计中心通过多年设计实践沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系，由三大部分有机构成：

一是包含五大维度的 UES 体验度量模型；

二是包含易用性测试工具和数字化管理平台的体验工具集；

三是体验问题从发现到闭环的体验管理机制。

由此可见，除了确定模型指标，UES 还进一步完善了基于 UES 模型的数字化管理体系，包括工具化的度量产品、系统化的管理机制（本篇文章主要介绍的是理论化层面的 UES 体验度量模型）。

图| UES 构成

度量产品体验的指标有很多，但整体可分为三大类，分别是主观态度、客观行为和系统表现，如下图所示，从下至上，主观性会越来越强。

图| 体验指标类型

2. UES 五大度量维度

UES 模型为综合运用主观和客观、定性和定量分析的度量体系，包含易用性、一致性、满意度、任务效率和性能5个度量维度，适用于技术类B端（云）产品的体验度量场景。

图| UES 模型五大度量维度

首先，衡量主观态度的维度有三个：易用性、一致性和满意度。

• 易用性是衡量产品使用体验的核心维度，反映产品对用户而言是否易于学习和使用。
• 一致性指多款产品间通用范式部分的一致程度。
• 满意度反映用户对产品或服务的期望被满足的程度，且一定程度上反映用户再次使用和推荐产品的程度。

其次，衡量客观行为的维度为任务效率。任务效率反映用户使用产品完成任务的准确性、完备性及相应的资源消耗程度。针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。

最后，衡量系统表现的维度为性能。性能反映用户使用产品的流畅性和稳定性，影响用户感知。

从整体上看，这些指标间并非相互独立，而是相互影响、相互促进。比如说，易用性的提升可以促进任务效率的提升，降低学习成本，提升用户对产品的满意度；一致性的提高可以降低用户的操作时长及错误率，进而提升任务效率和用户的满意度。而任务效率和性能的提升也能正向影响满意度。

3. UES 指标体系

在五大度量维度的基础上，UES 模型的每个维度均细分了相应的二级指标，且运用了多种度量方法、度量工具来度量指标，整体框架如下：

图| UES 模型框架

易用性包含易操作性、易学性、易见性/清晰性三个子维度，主要通过易用性测试、启发式评估等方法来度量。

一致性包含整体样式一致性、通用框架一致性、常用场景组件一致性等三个子维度，主要通过启发式评估来度量。

满意度的度量方法主要有用户访谈、问卷调研，采用的度量工具为可用性度量表、满意度问卷。

任务效率包含功能使用率、任务完成率、任务完成时间、任务完成效率等子维度，需要通过用户行为数据采集的数据监控方法来度量。

性能包含首屏渲染时间、页面请求响应时间、API 请求响应时间、页面请求成功率等维度，需要通过应用实时监控服务的性能监控方法来度量。

对于每一个细分指标的定义，下表给出了相应的解释。但这些仅是比较普遍、通用的解释，在应用中，应根据实际情况进行调整。比如说，对于满意度的度量，SaaS 和 PaaS 产品考量的维度会有些许不同。衡量 SaaS 产品满意度时可能会考量产品的智能化程度，衡量 PaaS 产品满意度时可能还会考量产品的开发效率、开放能力等。

图| UES 模型指标定义

4. UES 度量方法及工具

首先是易用性度量，UES 模型的易用性度量运作机制如下图。度量方法主要分为面向专家的启发式评估和面向真实用户的易用性测试。这个过程中，需要由易用性专业建设组和业务线设计师、产品团队共同参与。整体可分为三步走：

一是统一易用性度量的标准、行动指南，以指导易用性度量的全流程；

二是输出专业的易用性度量报告；

三是通过系统化监控和专项改进进行闭环管理。

图| 易用性度量运作机制

下表是启发式评估和易用性测试过程中会运用到的易用性度量量表工具，主要是让专家和用户反馈使用这款产品的真实感受，对易用性的每个细分指标：易操作性、易学性、易见性的表现进行评分。

表｜易用性度量表

接着是一致性度量，一致性的常用度量方法为专家评估法，其具体实施步骤如下：

第一步是组织评测人员：招募3~5人组成专家组。需注意的是，被评测产品的设计师需回避；

第二步是制定评测计划：划定评估的范围，建议一次性评估的功能不要太多；

第三步则是实施具体评测：在评估过程中，各位专家需独立完成，避免讨论沟通；

第四步为召开评测会议：让评估人员依次讲述评估发现并进行互动讨论；

最后是总结评价结果：将所有评估结果进行去重和收敛，输出结论建议。

图| 专家评估法实施步骤

在运用专家评估法度量一致性的过程中，所运用的度量工具表为一致性度量量表，主要是让专家对产品整体样式、通用框架、常用场景及组件的细分指标的一致性表现进行评分。

表｜一致性度量表

然后是满意度度量。通用的满意度度量量表框架如下，主要是对产品功能的易学性、易操作性、费力度等进行评价，但实际应用过程中应根据所度量对象适当调整量表内容。

表｜满意度度量量表

任务效率为客观行为数据，需通过数据埋点与采集，进行用户行为分析得到相关原始数据，再根据指标定义公式计算相应的指标值。

性能度量指标为系统表现数据，可通过数据埋点或从系统后台拉取数据，借助性能监控系统实时监控性能指标。企业可结合实际业务场景自行搭建性能监控系统，也可应用市场上成熟的 APM 类监控产品，如阿里云的 ARMS( Application Real-Time Monitoring Service, 应用实时监控服务 )。

图 | ARMS 性能监控效果图

5. 体验评分

介绍完 UES 的指标体系及相应的度量方法及工具后，则到了最后一步：如何根据搭建好的指标体系及获取到的指标计算出产品或功能的体验得分呢？

整体的原理是：一级指标得分为其所包含的二级指标的加权平均值，而测评总分由一级指标得分加权平均得到。测评总分计算公式如下：

式中，S 为测评总分，ai为第 i 个一级指标的得分，Wi为第 i 个一级指标的权重，n 为一级指标的数量。

对于权重的确定，阿里对 UES 模型的权重设计为：易用性和一致性 0.3，任务效率和性能 0.1， 满意度 0.2。

但对于面向大企业的B端产品，该权重不一定适合照搬。那么如何根据实际的体验度量对象确定指标的权重呢？

表 | 指标权重计算方法

此处归纳了常见的指标权重计算方法，主要有三类：主观赋权法、客观赋权法和综合赋权法。

• 主观赋权法是基于决策者的经验或偏好，通过对各指标重要性进行比较来赋权，比如专家评分法、优序图法、层次分析法等；
• 客观赋权法是从实际数据出发，利用各指标值所反映的客观信息确定权重，比如熵权法、标准离差法等;
• 综合赋权法则是将主观赋权法和客观赋权法相结合。

这里简单介绍下实操性比较高的层次分析法和优序图法。

首先是层次分析法，该方法常被运用于多目标、多准则、多要素、多层次的非结构化的复杂决策问题，特别是战略决策问题。

其优点在于系统化、简洁实用，且所需定量数据信息较少，但也存在缺点，比如说指标过多时，数据统计量大，且权重难以确定；特征值和特征向量的精确求法比较复杂。

该方法整体可分为三步：

一是基于问卷数据构造判断矩阵。具体而言，由专家对同一层次内 n 个指标的相对重要性（两两因素之间）进行打分，标度范围取 1-9 之间：

1 表示两个指标具有相同重要性，3 表示两个因素中，前者比后者稍重要，标度越高表示前者比后者的重要性程度越高。另外，若因素 i 与因素 j 的重要性之比为 aij，则因素 j 与因素 i 的重要性之比为 aij 的倒数。

根据相对重要性打分，即可构建判断矩阵 A 。

第二步则是基于判断矩阵计算权重，将矩阵 A 的各行向量进行几何平均（方根法），然后进行归一化，得到各评价指标权重和特征向量 W 。

最后一步为一致性检验。所谓一致性是指判断思维的逻辑一致性（如当甲比丙是强烈重要，而乙比丙是稍微重要时，显然甲一定比乙重要。这就是判断思维的逻辑一致性，否则判断就会有矛盾）。一致性检验是指确定不一致的允许范围。通过一致性检验的权重值才是合理的。

可能层次分析法的权重计算和一致性检验原理比较复杂，但在实际应用过程中，可以利用市面上成熟的层次分析法工具来实现，如元决策的 yaahp 软件，导入问卷数据，系统即可自动计算出相应的权重并进行一致性检验。

然后是优序图法，该方法非常适合在参与评估指标数量较多（如需评估的指标超过5个）的情况下使用。当指标数量较多时，优序法的专家打分工作量相对较小，且简单易实操。但该方法也存在一定的弊端，如未进行一致性检验或多轮验证，权重数据的严谨性相对较差。

该方法整体可分为三步：

一是重要性打分，由每位专家独立对问卷内各指标进行重要性打分，并计算出各指标所有专家打分的平均分。

二是指标重要性比较，通过各指标的平均分，将不同指标间的平均分进行两两比较，其中，分数相同的计为 0.5，相对较大的记为 1，相对较小的记为 0，并将各指标比较的每行分数相加，得到各指标的优序数（TTL）。

最后则是对 TTL 值进行归一化处理，得到指标的权重值。

表｜层次分析法和优序图法优缺点比较

三、谷歌 HEART-GSM 模型介绍

HEART-GSM模型包括【5】+【3】两个部分：5个用户体验度量维度和3个确定数据指标的步骤。

首先，代表5个用户体验度量维度的 HEART 模型由 Google 于 2010 年发表，是以用户为中心的度量模型，涵盖了用户主客观数据以及可用性指标，可用于大范围的用户体验度量，五个维度分别为愉悦度、参与度、接受度、留存度和任务完成度。

• 愉悦度指的是用户在使用过程中的主观感受，主要包括可用性、易用性、视觉感受、满意度、推荐意愿等维度；
• 参与度衡量的是用户在产品/服务/功能中深度参与的表现，如访问频次、访问时长、互动深度或强度等；
• 接受度是针对新用户的维度，统计有多少新用户接受了产品、功能，如特定时期内核心页面的PV、UV，新功能的使用留存；
• 留存度是针对老用户的维度，衡量现有用户对产品的重复使用情况，常见指标如次日留存率、7日留存率等；
• 任务完成度指用户在使用产品/服务/功能中能否顺利完成目标任务的情况，包括任务完成率、任务完成效率、错误率等指标。

图｜HEART 模型五大维度

为了将这个抽象的度量标准应用于实践，Google 又提出以“目标（Goal）——信号（Signal）——指标（Metric）”的拆解流程来定义 HEART 指标数据，让使用该模型的产品团队，可以根据用户体验目标和业务目标，完成数据指标的选择，最终保证指标是服务于业务目标和用户体验的。

这三个大步骤又可细分为五个小步骤，首先是梳理业务流程，分析确定产品目标或者体验目标，接着，结合度量维度的定义和目标选取与实际业务流程贴合的度量维度，然后是选择可以显示目标成功或失败的信号，最后是从信号中提取适当选择的数据指标，并选取相应的度量方法进行追踪。

图｜GSM 拆解流程

整体而言，HEART 模型的C 端倾向较明显，并不完全适用于 B 端产品的体验度量，比如说，由于 B 端产品的业务性质，用户使用产品后较难因为个人使用的体验而在参与度、留存度及任务完成度上体现出差异。

图 | HEART-GSM 模型优劣势

可能会有小伙伴对信号跟指标的区别不太清晰，这里说下我的理解：

在 GSM 模型中，目标、信号、指标之间是承接的关系。确定目标从而判断目标对应的信号，然后拆解为可量化的指标。信号是目标的分解，一个目标可以分解为多个信号（信号也可理解为目标对应的表现，目标的成功或者失败，如何作用在用户的行为之中，哪些行为、感受可以说明目标已经成功)。指标是信号的衡量标准，一个信号可以由多个指标来衡量。

举个例子：

• 目标：智能搜索帮助用户查询结果；
• 信号：更多的用户使用智能搜索 、用户对搜索到的结果很满意；
• 指标：点击次数、满意度。

四、蚂蚁金服 PTECH 模型

以 HEART 度量模型为基础，蚂蚁金服根据企业级产品现状和特征做了部分的补充和修正，推出了适用于企业级产品的 PTECH 模型。PTECH 模型与 HEART 模型的主要区别在于：

1. 将 NPS 改成用户主观满意度：NPS 对 C 类产品是一个很有效的指标，对于企业级中后台来说，往往由于企业产品的封闭内环、用户基数等众多原因，可能还是满意度来的更加有效；
2. 不强调留存率：企业级产品用户往往没有太多的可选余地，因此留存率未必适合用来衡量用户对于产品的喜好；
3. 参与度和接受度指标合并：对于企业级中后台系统，用户使用的目标性更强，TA 就是来完成某个任务（或者说 TA 就是来完成工作的），因此活跃度基本和产品能否满足用户的需求强相关；
4. 增加了清晰度。

图| PTECH 模型框架

PTECH 模型通过马斯洛需求金字塔理论推导出用户体验需要满足的5个层次，分别对应度量框架的五个维度，做到了定量与定性全覆盖。生理-安全-归属-尊重-自我实现五个层次分别对应：

1. P——能用，这产品稳定、无故障、性能好；
2. T——有用，这产品能够确定性地完成某些任务；
3. E——常用，这产品满足的是一个会被反复使用的真实诉求；
4. C——好用，这是一个专业成熟、交互友好、功能清晰的产品；
5. H——爱用，这是一个能让用户获得满足、成就感的产品。

图 | PTECH 模型优劣势

以上就是本次文章的全部内容啦，篇幅有些长，划个重点回顾下吧~

五、划重点

1）综合主客观指标的产品体验度量模型主要包括：UES 模型、HEART-GSM 模型、PTECH 模型。

2）UES 模型为综合运用主观和客观、定性和定量分析的度量体系，包含易用性、一致性、满意度、任务效率和性能5个度量维度，适用于技术类 B 端（云）产品的体验度量场景。

3）HEART-GSM 模型包括【5】+【3】两个部分：5 个用户体验度量维度——愉悦度、参与度、接受度、留存度和任务完成度、3 个确定数据指标的步骤——目标（Goal）——信号（Signal）——指标（Metric）。

4）PTECH 模型是基于 HEART 模型修订的，主要度量维度如下图：

在产品经理的工作中，我们总能看到功能架构图，但它是怎么来的呢？本文介绍了功能架构图和信息架构图的区别，以及如何从业务出发构建功能架构图。希望对你理解和绘制架构图有所帮助。

在产品经理的工作中，我们总是会用到功能架构图，但是功能架构图是怎么来的呢，可能还是有很多伙伴不是非常清楚。

有可能是凭经验、看竞品等方式来做功能架构图，然后反反复复经过多次的来回折腾有一个输出，但可能有各种遗漏并传递到下一个环节，最终靠和研发各方调整撕逼多次最终完善。

那有没有能够比较彻底的方式方法来解决这种问题呢？

确实是有的，我们还是回到业务层面，因为功能也是为业务服务的。

我们在业务架构阶段得到商业模式，商业模式中拆分出价值链、价值链进一步细化就得到流程，流程逐层分解细化，我们得到多层级的流程，最终到任务活动这个不可再拆分的层级。各个业务的复杂度不同，拆分的层级不一样。

如下为生产制造类型的核心价值链，从商业模式梳理出核心价值链，还有辅助及职能部分。

对核心价值链逐层分解，则能有下一级的流程，流程节点步骤对应能力，也即是功能。以其中的加工制造环节的三个层级来分析，细化如下。

对流程节点进行一一映射，就能够得到功能架构图。在拆分的时候，做到端到端、逐层拆解，完全穷尽，不重不漏。

功能架构图与信息架构图

在日常工作中、书上、网络上经常能看到产品信息架构图、产品功能架构图等等。

信息架构和功能架构有何区别呢？为什么一个产品，会有两个不同的架构图出现？

估计很多人画的都是二合一的架构图，但总是画不全、想不周密、老觉得缺点啥似的，到后面原型设计、设置研发等环节再补，导致反反复复、不断的返工。

本质上是从不同的视角看问题的缘故：

A、功能架构图就是我需要哪些功能。就像是汽车发动机，需要有哪些零件一样，一个个的功能就是一个一个的零件。功能架构就是发动机所有零件的一个综合清单，不过这个清单进行了分类，按照不同的类别进行了多个层级的分类，能够方便清晰的识别出每个零件的归属及上下级关系，就像给图书进行分门别类编号一样。这样也便于检查功能是否齐备等。

B、信息架构是零件组装的一个指导，就类似于发动机的组装指导手册。要考虑如何组装零件最后占用的空间少，各个零件出现在该出现的位置，不会出现错装漏装。这样才能更好的使用，对用户友好，不能是简单的堆砌在一起，要考虑功能之间的交互。

就类似于下图，发动机的每个零件都出现在该出现的地方，发动机才能正常的运转，要不然即便有这个零部件，没有安装好，也发挥不了该有的作用。软件类似，如果一个功能出现在不合适的位置，就发挥不了本身应有的作用。

就一般来说，我们肯定是先有单个的零件，然后才能进行组装。

因此是先有功能，然后进行组装、也就是搭建交互及页面布局，最终形成信息架构图。

当我们有了信息结构图，我们再进行原型绘制，就非常简单，只需要将相关功能按照交互布局放上去，并创建交互，原型demo就出来了，这样能够极大的减少因为思考步骤导致的往复返工，特别是原型的往复返工。

下图为微信的功能架构图，在梳理功能架构图的时候，就不太会去管这些功能怎么样去交互，摆放位置等等，大概的知道他们的一个先后顺序。看这张图，能够比较清晰的看到微信有哪些功能，对其有一个概览。

下图为微信的信息架构图，也就是微信各种功能的组装图，看这张图就能够比较清晰的知道，微信一层一层有哪些东西，是怎么样分布的，你在哪个地方可以看到用到哪些功能。

功能架构图更便于研发或者是后台研发看，信息架构图便于UI、前端看。功能架构是功能的集合，信息架构图是功能的交互。

从产品设计、UI设计、视觉设计、交互设计等等一些列设计，其实都是做了一个事：站在用户角度，用户如何使用这个产品（用户体验），以及我们希望用户如何使用这个产品。

功能架构图的作用是；快速的梳理功能，辅助研发人员来进行开发的，

信息架构图的作用是：是表达信息及信息之间的相互关系，用于交互设计相关人员使用，约束其设计思路，进而让所有人聚焦，从产品到视觉设计人员，整体一致的为“用户更好的使用这个产品完成目标”而设计。

通过从业务中的价值链》流程》功能》功能架构图》信息架构图，我们整个产品需要什么样的功能，功能应该如何布局也就很清楚了，那么下一步，我们就可以使用原型来做一个最终的demo呈现。

在樊登读书改名后，下一步策略是大力扶持【非凡精读馆】和【李蕾讲经典】两个栏目，来实现线上流量的第二增长曲线。那么后续还会有哪些变化？本文从三个方面深入分析，一起来看看吧。

六月份，我们共同揭秘了樊登读书更名的秘密——创始人的影响力，下一步策略是大力扶持【非凡精读馆】和【李蕾讲经典】两个栏目，来实现线上流量的第二增长曲线。很巧合的是，上两周我更新了app，发现他们就在上面的策略下，做了两个功能优化：首页功能设计将非凡精读馆和李蕾讲经典放到首页明显的C位。

推出了樊登读书会员兑换李蕾将经典会员的服务。

那可能很多人就会好奇了，那接下来还会有哪些变动呢？我们从三个方面来深入了解：

1. 行业、公司和产品现状分析
2. 帆书app遇到的关键问题
3. 下一步产品迭代路线图

一、现状分析

1. 行业现状

帆书app作为知识付费行业-新阅读领域的超级ip，占据了举足轻重的位置。应用PEST工具来做详细分析：

从政策导向层面来看，教育部办公厅在6月16日发布《关于广泛开展全民终身学习活动的通知》，教育部决定广泛开展全民终身学习活动，其中重要指出需要各地组织开展全民阅读活动，举办全民终身学习活动周，营造全民阅读氛围、打造全民阅读生态。基于此知识付费-新阅读赛道处于一个上升的红利期。

从经济发展层面来看，自2020以来，疫情对于整体经济的发展有阻碍作用，2年内很多店铺关门，造成大量的人员失业，从而到底消费欲急剧降低，但22年开放后，有所复苏，整体来看，经济相对于疫情前增速放缓。

从社会变化层面，因为不可预见的黑天鹅事件频频发生，人们更加勒紧裤腰带，不愿更多的消费并更多的存款。并且当前知识付费多种多样，造成品类参差不齐，很多人被欺骗后不愿再做“韭菜”，消费意愿度不高。

从技术革新层面，自从22年底Ai技术爆火之后，各类平台都在接大模型，且AI技术的能力远超常人，它不仅具备人类所有历史书籍的知识储备，且能更好的帮助用户提炼知识点，对改赛道的企业有冲击作用，当然有部分企业与AI深度链接，取得了很好的长远发展，可作为下一个增长点。

2. 公司现状

帆书app由上海黄豆网络科技有限公司开发，目前已发展10年。在前10年，主要由樊登老师作为大IP获取用户，进行付费订阅，从近三年的数据发觉用户增长放缓，已处于瓶颈期。

为此公司大力扶持其他两个品类的读书栏目，并弱化课程的曝光量，回归新阅读赛道。

3. 产品现状

近期其APP刚进行改版，策略都是为了迎合改版帆书名做的功能调整：

1. 【非凡精读馆】【李蕾讲经典】两个栏目放置首页最关键的位置，以此来吸引用户关注。
2. 原有的分类调整到讲书栏目的列表页中，使得整体页面表现的很清爽。
3. 【课程/训练营】等非读书类的学习，整合到【进阶】栏目，以此来与阅读区分，代表其回归阅读赛道的表现

二、帆书app遇到的关键问题

基于以上的现状分析，整体能发现三个关键问题：

1. 如何提升【非凡精读馆】【李蕾讲经典】的播放量和会员订阅量
2. 如何招引更多的优质讲师，丰富精读馆的师资力量
3. 如何通过AI赋能帆书APP，让用户更好的学到和用到书本知识

从问题可以推导出下一步产品的战略目标为：孵化【非凡精读馆】【李蕾讲经典】两个爆款栏目，提升会员月订阅增量30%，用户播放增量50%（数字仅供参考）。

三、下一步迭代路线图

为达成该战略目标，以两个季度为迭代周期，从产品和运营两个方面同步开展，分为三个阶段：

第一阶段

里程碑：推出两个专栏-会员兑换服务

事件轴：2023-07-27~2023-08-27

主要任务：

1. 新增闪屏推广页，推广兑换活动

2. 通过樊登读书的画像推荐两个专栏的相关书籍

3. 以1：2的形式兑换配额

主要是为了放大会员兑换服务的力度与刺激感，以占据4000万的樊登会员来说，更多的是认可樊登老师的讲书质量，如果以1：1的形式，可能还不足以刺激用户来进行兑换，所以将其设计为1：2更符合人性的预期（贪婪）。

第二阶段

里程碑：推出名师与你相约，线上/线下联动免费活动

事件轴：2023-08-27~2023-10-27

主要任务：

1. 制定宣传海报并发布平台宣传

2. 樊登线上推荐，并联名推广

3. 推出会员折扣活动，拉动即兴消费

在这里主要是为了增加名师的曝光量，不知道各位在用帆书APP对樊登老师以外的老师认可度或者认知度如何，从目前数据来说，樊登会员对其他人的知识厚度和认知程度还是稍显薄弱，为此以最大的IP樊登老师为引线，来增大观众对其他老师的认知程度。

目前来讲【樊登读书】和【李蕾讲经典】属于相同的服务策略，就是以孵化个人IP的形式来增加用户粘性，不知道是不是巧合，也正好逢迎了当下社会的女性主义，男女搭配，两个超级形式呈现，挖掘下沉女性用户。而【非凡精读馆】是一个【讲师包】的形式来孵化【讲馆】的策略，等于是给优秀讲师一个发挥平台，这也有助于其讲师团的丰富，给用户不同的听书体验。

综合来讲，2 * X的策略对讲书人和听书人来说，都是双赢策略。

第三阶段

里程碑：AI赋能讲书听书环节，实现降本增效

事件轴：2023-10-27~2023-12-27

主要任务：

1. 同文心一言或星火等国产大模型合作，制作樊登讲书模型

2. 利用AI写作，降低人工写稿、审稿成本

在23年AI引爆全网的时代，当下有很多企业都在尝试赋能本领域，其中以自媒体最为明显，并且很多以媒体赚钱的公司日益增多。如果你今年一直有持续关注AI领域，可以发现，三个期望已经完全实现：

1. 真人思维模型
2. 虚拟数字人
3. AI文字提炼与图片生成

在真人思维模型，给模型“投喂”这个人的材料，完全可以复刻一个思想几乎一模一样，甚至超过真人的机器模型。

分享一个实际案例：

外国研究人员研发了一个名为“DeepBach” （深度巴赫）的神经网络，使用了巴赫创作的352部曲目进行变调。最终，DeepBach能够创作出与巴赫风格高度相近的作品。在对包括了400多位音乐家和音乐系的学生的1600多人的测试中，超过一半的人认为这些作品就是巴赫本人的作品，而巴赫本人的作品也仅被75%的人正确识别。

可见这已经是真实可行的路线，如果以此为下一步迭代方向，加上虚拟数字人的技术，完全可以由虚拟人“樊登”来每周分享一本书，甚至可以每天一篇。

最后的话

作为一个樊登老师的粉丝和一名互联网产品从业者，我观察到他们慢慢地寻求下一波增长突破口——推出多元化IP，回归新阅读领域，这对于全民的文化素质提升有着非常好的促进作用。

同年5月，我参加了他们线下翻转师的培训，能看到他们的另一面——为他人赋能讲书的能力，而翻转课堂作为当代新型的课堂模式，核心理念就是“翻书为课，以轻松、有效的课堂设计，让学员们学到用到”， 不得不佩服他们的发心：听书可以熏陶自己，成就自我；讲书可以点亮他人，引领他人。

这也是我们共同愿意付费，认可他们的重要因素，在此由衷给他们祝福。

希望对你有一点启发，加油。

JTBD即“Jobs-to-be-Done”，这一方法论框架可以帮助我们快速地理解并明确用户目标。那么，产品经理可以如何借助“JTBD”理论来完成需求拆分、竞品调研等环节？一起来看看本文的解读和分析。

首先，我们来快速回顾一下什么是“JTBD”（Jobs-to-be-Done）。

直接用例子回顾，人有出行的需求，他的Job就是从A点到B点，而完成这个Job，他需要Hire【某种工具】让他从A点到B点。因此人要的不是更快的马，而是更快的【某种工具】，可以是车，是高铁，是飞机。JTBD的意义在于，快速明确用户的目标，而到达目标的方法可以有很多种，这样你就不会局限于一个具体的功能。

接下来我们来讲“JTBD”的细分和应用。

一、拆解需求之Main Job（主要任务）和 Related Job（相关任务）

还是同样的例子，人有出行的需求。我们来细分人实际出行的场景，比方用户A，我要去拜访亲戚。

现在给你5秒钟，站在【地图App的视角】先来拆一下这句话中“我要去拜访亲戚”用户可能有的Job。

好的，我先拆分下：1. 首先我要从自己家去到亲戚家 2. 你去亲戚家不得带点礼品呀，所以我可能还有买礼品的需求。

那么作为【地图App】，用户的Main Job=从自己家到亲戚家，用户Related Job=买礼品。针对Main Job我要提供什么服务呢？——提供从自己家到亲戚家的路线。针对Related Job呢？——OK，「顺路搜」的功能就出来了。

现在留一个课题作业：请你分析高德地图情人节的顺路买花功能对应的需求场景和Job。

二、满足需求之Functional Aspect（功能方面） 和Emotional Aspect（情感方面）

上面说的是如何拆分需求，接下来我们就来考虑如何满足用户的需求。

这时候我们就会把需求改写成这种格式：I want [XX] in a [XX]way。

前半句你用来对应的Functional Aspect，后半句你来对应Emotional Aspect。

比如，用户出行：我想要（安全地/舒适地）到达目的地。那作为【网约车】App，你打算怎么满足这个需求呢？

Functional Aspect：1. 我要提供车辆——有车可打 2. 我要确保能接到和送到乘客——定位要准，等等。这里提供思路，小伙伴可以继续扩写。

Emotional Aspect：1. 安全——司机驾龄要满足X年？要有监控语言系统？2. 舒适——要求车在X年以内？限制车型？高档车？等等。

三、拓展思考之Personal Dimension（个人维度） 和 Social Dimension（社交维度）

刚刚我们说了，满足用户的需求可以思考Emotional Aspect，Emotional Aspect还可以拓展思考Personal Dimension（个人维度） 和 Social Dimension（社交维度）。

比如我的个人维度——我要（安全地/舒适地）到达目的地，那我有没有可能有社交维度的需求？我要拉风地到，我要坐在奔驰发朋友圈。

这个细化维度属于拓展思考，并不是所有的Emotional Aspect都要有Social Dimension，但是这个是一个思考的方向。

四、优雅运用“抄”并「超越」竞品

最后把上面讲的全部汇总起来，就可以用这个图表示。

这部分理论完全可以用在竞品调研里面，因为你的App和竞品的用户是用一批，Job就是一样的，你可以直接看看竞品是怎么满足用户需求的。

他的Functional Aspect是怎样的？（PS：Functional Aspect往往是可以直接“抄”的地方）

他有Emotional Aspect么？Emotional Aspect，往往就是你可以破圈出彩的思考点了。

下期预告：

我要为互联网黑话Painpoint（痛点）正名！这个理论在外企产品里可好用了！！！旨在识别用户的Problem并且减少用户的Friction。期待下期见！

各行各业都有着自己的规范，那么我们在做设计规范的时候，常常会面临着一些问题。本文大致总结了两个问题：规划缺乏生长性和可复用性。那么该如何解决这两个问题呢？作者对此进行总结，希望对你有所帮助。

最近一段时间笔者正好在梳理设计规范，在做设计规范的时候，经常面临如下几个问题：

（1）由于业务发展，规范不断在更迭，今天做的设计组件却并不适合1个月之后客户的需求。

简而言之，规范缺乏对未来的规划，缺少生长性。

（2）规范主要集中在业务组件上的思考，但是缺乏对业务流程的梳理，导致流程上复用率低。

（3）缺乏对整体信息架构的梳理，缺少全局上对产品的思考。这个优势在于避免重复造车轮，有利于合并同类项，让产品更轻量，更易用。

简而言之，规划缺乏生长性和可复用性。

一、应该如何预留生长性

大部分做中后台系统的同学，大抵都会站在“巨人的肩膀”上重新规划、设计组件。“巨人的肩膀”例如ANT DESIGN，大而全，在列表和表单组件引用时非常丝滑，但是却缺少精细化和对业务诉求的承载。

因此，大部分的同学都会结合业务诉求，形成一套对公司业务有强支撑和专业化的组件，做到小而精。问题是，设计同学在设计规范时，心里的那杆秤始终摆不平。定的太严谨，未来业务变化后，组件又需要重新开发，不可预期的提高了开发成本，定的太松弛，前端引用时会bug频出。

其实导致“秤不平”，最重要是缺少了生长性的砝码。那么什么是生长性，生长性的边界又在哪里，该怎样预留生长性呢？

1. 什么是生长性

生长性指的是产品方向变更时，设计组件仍能支撑业务诉求。比如原有组件设计时只考虑静态交互，而业务变化后需要新增可拖拽功能，方便用户快速处理信息。如果在设计组件时，就预留了生长性和空间，后期改动就只需要往上加，而不需要大改动。

再比如规范建立初期，业务是以国内为主，但由于疫情之后，国内僧多粥少，企业考虑未来出海，走差异化竞争。此时，国际化最直观的变化在文字和行高规范，多门语言，多种文字在相同场景下会出现承载空间不够或过于富余等问题。不同国家对部分结果页指示也会有文化禁忌，此时就需要尽量避免引起语意冲突的部分。如果规范预留了足够的生长性，业务迅速调整时，设计和开发也能无缝跟上，节约时间，抢占市场。

2. 生长性的边界在哪里

规范总体来说，是设计和开发共同的指引。生长性的边界在于“是否能做到清晰的指引”：开发在引用时，能否应对各种报错、能否处理极端场景，能否应对产品经理临时的小需求等等。这些都是判断生长性区间范围的衡量标准。

3. 如何在组件中预留生长性？

（1）通盘考虑报错

在设计报错提示组件时，需要整合多个业务场景下，除了需要通盘考虑样式之外，也需要和前端同学讨论是否会影响性能的变化。

大部分的报错可以分为：表单报错、列表报错、全局报错、业务场景新组件报错。报错提示如若不能同时适应这四种场景，就需要将组件做样式微调，分成四种报错样式，整合到规范中。

（2）定义极端场景

比如由于很多场景下，业务诉求很可能会在原有组件中加内容、加层级，而增加的工作量往往产品会直接交付前端同学实现，因此如果定义好了极端场景，设计同学就不必每个需求下都需要做微调，前端同学对极端场景做判断，即可轻松实现效果。（涉及到工作流程的问题）

（3）提前预留承载空间

首先，就需要厘清现有业务控件承载，比如页面区域工具栏，工具栏本身区域有限，而业务方在不停加工具，在设计初期就需要规划好，页面承载空间不够时，应如何处理，这样利于后期的延展。

（4）多端视觉和交互规范，确保品牌延展性

比如中台产品支持PC端、Pad端，就需要考虑同样组件在Pad下可点击区域大小、Pad交互习惯等。

比如，医疗SaaS产品，大部分私人医院都会要求产品支持Pad端。私人医院相对公立医院，更重视医疗体验，以及微营销。患者在候诊或者做康复医疗时，需要做健康宣导或者活动营销等。

因此在设计组件时，如果我们通盘考虑了该组件在PC端和移动端、Pad端的可承载性，便可以让品牌得到了最大化延展。

（5）无障碍设计

规范建立初期，服务的是大多数身心健康人士。随着业务拓展，企业品牌建立，对于残障人士的无障碍设计、老年人关爱模式，是否需要考虑其中。需要同时结合公司品牌定位，为产品预留生长性。而无障碍设计的规范，国内外很多知名企业已经根据残障人士的特点，有一套该如何搭建的引导，设计同学只需要顺延，结合业务，搭建自有的无障碍规范即可。

二、应该如何最大化规范的可复用性

流程上复用率低、产品过重缺乏全局思考根本原因在于，过度重视原子组件搭建，而忽略了整体架构和流程的梳理。

（1）引入共性流程规范

往往我们在工作中搭建规范时，会过度重视原子组件搭建，而忽略了流程梳理。规范上忽略了流程梳理，设计稿中也会难免遗漏一些场景，导致实际上线时用户体验不佳或者流程不丝滑。

举个例子：

例如在金融软件中，涉及到贷款流程，小微贷，企业贷，消费贷等，由于属性的不同，各个贷款流程在细微上有差异，也有共性。在梳理设计规范时，就可以提炼共性的贷款流程，封装组件。在前端开发时就可以节省不少人力。

再比如医疗SaaS软件中，会诊流程和日程流程：

• 日程：发起日程-邀约日程-再次邀约（未及时加入提醒）-记录日程。
• 会诊：发起会诊-邀约会诊-再次邀约（未及时同意提醒）-线上视频会诊（线下记录会诊内容）-上传会诊记录-跟进会诊后患者状况。

本质上，会诊也是日程的一个分类，但由于会诊涉及到多个角色的协同，分为普通会诊和多学科会诊，比普通日程更加复杂，是属于长期的工作流，因为会诊除了会诊之外，同时需要关注会诊后患者的治疗，以便下次会诊复盘。

将日程和会诊的共性流程进行封装，将为开发带来诸多便利。

（2）梳理信息架构

Z轴分布包含平面内部的分布和空间上的排序。平面的分布可以梳理各个一级页面、二级页面的框架层，便于设计组内同学在设计新页面时参照规范快速出稿。而Z轴上的空间分布，包含浮层、弹窗、提示等的出现次序和排列。提前规划好排列顺序，有利于组件冲突时，有可供参考的规范引导。

（3）文案规范

文案往往体现产品气质。梳理文案规范，有利于从产品上提升企业气质和形象。可以将文案分为引导类文案、描述类文案、报错类文案等。而文案规范梳理应该放在成熟期的产品使用。业务在蓬勃发展期间，还是应探索业务组件为主，文案规范可以往后延展。

以上是笔者结合项目经验的一点心得，希望能帮助到大家。

在产品设计和推广的一系列过程中，我们应该如何提升用户体验和改进产品功能，从而提高用户满意率，提高市场占有率呢？本文从四个步骤进行分析，希望能帮助到你的工作。

成熟的产品需要不断地迭代打磨，在进行充分的前期调研后，通过提前对整个设计过程系统的设计，按计划执行设计活动，可以使产品设计更加聚焦产品目标的实现，使用PDCA循环开发产品功能，保证产品更好的实现商业目标。

一、概念介绍

PDCA循环是美国质量管理专家沃特阿曼德·休哈特(Walter A. Shewhart)首先提出的，由戴明采纳宣传获得普及，所以又称戴明环。

• P(Plan)——计划：确定方针和目标，确定活动计划
• D(Do)—执行：实地去做，实现计划中的内容
• C(Check)——检查：总结执行计划的结果，注意效果，找出问题
• A(Action)——行动：对总结检查的结果进行处理，成功的经验加以肯定并适当推广、标准化；失败的教训加以总结，以免重现，未解决的问题放到下一个PDCA循环。

一个完整的PDCA循环包括4个阶段，8大步骤，下面进行详细介绍：

二、四个阶段

四个阶段分别是：计划、执行、检查、行动。

1. 计划阶段 (Plan)

制定目标，活动计划、管理项目和措施方案。主要包括下列工作内容：

• 分析现状，找出存在的问题
• 分析产生问题的各种原因利影响因素
• 从各种原因中找出影响的主要原因
• 针对影响成果的主要原因，制定措施方案，提出措施执行计划和预计效果，并具体落实到执行者、时间进度、地点、部门和完成方法等方面

2. 执行阶段（Do）

将制订的计划和措施，具体组织实施和执行，采取行动以确保对策的有效性和执行的效力。

3. 检查阶段（Check）

将执行的结果与预定目标对比，检查计划执行的情况是否达到预期的效果，哪些做对了，哪些做错了，成功的经验是什么，失败的教训是什么，原因在哪里。

4. 处理阶段（Action）

• 总结经验教训，巩固成绩，处理差错。把成功的经验沉淀下来，形成标准范式，以便之后参考，失败的教训也要加以总结整理记录，作为借鉴，防止以后再度发生
• 把没有解决的遗留问题，转入下一个管理循环，作为下一阶段的计划目标

这4个过程不是运行一次就完结，而是要周而复始地进行。一个循环完了，解决了一部分的问题，可能还有其他问题尚未解决，或者又出现了新的问题，再进行下一次循环，这样阶梯式的上升。

三、八大步骤

1. 计划阶段（Plan）

步骤一：分析现状，找出问题

强调的是对现状的把握和发现问题的意识、能力，发现问题是解决问题的第一步，是分析问题的前提。

要点：调查内容。其包括4个要点：时间、地点、类型和症状。调查的对象应是广泛和随机的，以保证调查的客观性。

步骤二：分析各种问题的因素或原因

找准问题后分析问题的原因至关重要，运用头脑风暴等多种集思广益的科学方法，把导致问题产生的所有原因统统找出来。

要点：原因分析必须做到集思广益和科学验证，缺一不可。常用的分析工具有线状图、排列图、直方图、正态概率图、散布图、控制图等。不论采用什么工具，重要的是分析过程是否正确。

步骤三：要因确认

区分主因和次因是最有效解决问题的关键。

要点：最终确认的主要问题，其数量越少越好，关键是要确认准确。

步骤四：拟定措施、制定计划

措施和计划是执行力的基础，尽可能使其具有可操作性。

要点：所制订的对策要形成一个计划书。计划书应包括改进的必要性、应实现的目标、采取的措施、执行部分及人员、执行地点、完成日期等内容，即“5W1H”原则。

2. 执行阶段（Do）

步骤五：执行措施、执行计划

高效的执行力是组织完成目标的重要一环。

要点：实施阶段并不是简单的执行，应包括执行、控制、调整3个部分的内容。调整是对工作计划进行调整，不是调整预定目标值。

3. 检查阶段（Check）

步骤六：检查验证、评估效果

“下属只做你检查的工作，不做你希望的工作。”IBM的前CEO郭士纳这句话将检查验证、评估效果的重要性一语道破。

要点：检查阶段要把所有的相关效果不论大小都罗列出来，运用统计技术，用大量可靠的数据说明问题。

4. 处理阶段（Action）

步骤七：标准化，固定成绩

标准化是维持企业管理现状不下滑，积累、沉淀经验的最好方法，也是企业管理水平不断提升的基础。

要点：将有效的措施纳入正式文件，实现标准化管理，组织相关人员培训，并建立责任制，保证措施的有效实施。

步骤八：处理遗留问题

所有的问题不可能在一个PDCA循环中全部解决，遗留的问题自动转入下一个PDCA循环，如此，周而复始，螺旋上升。

要点：对解决问题的本身进行反射性思考，总结前面的工作，寻找遗留问题。

四、PDCA循环在开发产品功能中的运用

1. 计划阶段（Plan）

确定目标：开发一个新产品功能，提高用户体验和产品竞争力。

分析现状：对现有产品进行调查和分析，发现存在一些问题，如操作复杂、界面不友好等。

找到问题：制定措施，包括设计更简洁的操作界面、增加用户友好的提示和引导等。

2. 执行阶段（Do）

按照计划要求，进行产品功能的设计和开发，注重用户体验和界面设计。

进行单元测试和集成测试，确保功能正常运作和满足需求。

将新功能集成到产品中，并进行用户测试，确保用户能够顺利使用。

3. 检查阶段（Check）

对产品功能进行测试和验证，确保其质量达到预期要求。

对用户使用情况进行跟踪和了解，收集用户反馈和意见。

发现存在的问题和不足，如操作不够简洁、提示不够明确等。

4. 处理阶段（Action）

对成功的措施进行标准化，如将新功能正式上线到产品中。

对存在的问题进行总结和反馈，如优化操作流程、增加更多的提示等。

制定新的改进措施，如定期对产品功能进行评估和优化，以提高产品竞争力。

通过以上PDCA循环，我们可以不断开发和改进产品功能，提高用户体验和产品竞争力，从而满足用户需求和市场变化。

作为设计师，在设计一款产品的过程中你是否会站在用户的角度关注到不同的细节？本文作者从五个部分分析了微交互的好处，希望能帮助到你的工作。

一、什么是微交互？

微交互就像是你和朋友打招呼时，微笑、眨眼、点头这些小动作。它们很简单，但可以让交流更自然更愉快，让你感到对方友好而且有反应。

在设计中，微交互就是一些小按钮、小提示或小动画，它们虽小，但可以让用户的操作更流畅更顺手，让用户感到产品或服务更加友好和人性化。所以，设计中不要小看微交互，小小的交互可以带来大大的好处！

1. 设计微交互时的考虑因素

微交互是用户在界面上与系统交互时发生的小动作，例如点击按钮、拖动滑块等。它们能够给予用户反馈，传达系统的状态或者帮助用户避免错误。因此在设计微交互时，需要考虑以下四个方面：

1. 触发器：微交互是由用户触发还是由系统状态变化触发的，例如点击按钮或者系统自动更新。
2. 规则：一旦微交互被触发，需要遵循什么规则进行响应，例如打开一个页面或者显示一个错误提示。
3. 响应：微交互通过视觉或听觉反馈来传达信息，例如页面的变化或声音提示。
4. 循环和模式：当条件发生变化时，微交互应该如何响应，例如再次触发或者进入另一个模式。

微交互涉及多种组件，但并非所有组件都被视为微交互的一部分。微交互是指那些在用户界面中针对单个操作或事件而设计的小型交互式元素。它们具有特定的触发器，一旦被触发，会有相应的规则和响应。

然而，屏幕上始终存在的静态元素通常不被视为微交互，因为它们缺乏特定的触发器。同样，多步骤操作也不符合微交互的条件，因为微交互强调简洁和即时的反馈。

因此，微交互着重于处理独立的小交互，而不是复杂的多步骤过程。

二、使用微交互的好处

微交互可以传达系统状态，促进复杂任务的理解和完成。在Instagram上，用户可以通过双击照片来查看其操作的结果：帖子上会出现一颗跳动的心，点赞数会发生变化，并且心形按钮会变满，表明操作已完成。

微交互不仅限于应用程序或网站，它还可以应用在其他设备和系统上。

举例来说，当HomePod和Siri等待用户的命令时，它们使用微交互来传达待机模式。一旦用户说出“嘿 Siri”，HomePod会展示平滑的模糊动画，并通过声音反馈提示用户它正在倾听。通过这种视觉和听觉反馈，用户能够知道设备处于待命状态，并且准备好接受指令。

微交互在这里的作用就是通过简单而愉悦的动画和声音告诉用户“我在这里，我在倾听你的话”，让用户感觉与设备之间的交互更加自然和无缝。

1. 注意：不要过度使用它

微交互不好会对用户体验造成负面影响，降低用户满意度，丧失用户忠诚度，甚至引发安全问题。因此，在设计产品或服务时，务必重视微交互的质量，确保它们简单、直观、有效，以提供优秀的用户体验。

微交互的问题也可能导致用户不愿意继续使用产品或服务，因为他们觉得交互过于复杂或不直观。一旦用户遇到这种情况，他们很可能会寻找替代品，转而选择竞争对手的产品，从而丧失了忠诚用户。

三、何时使用它们？

微交互只是小小的交互元素，但它们在用户体验中的作用却是不可小觑的。正确利用微交互的力量，可以为用户提供更好的体验，提高产品或服务的竞争力，并赢得用户的青睐。

当前系统状态对于用户来说是至关重要的，因为它让他们了解网站或应用程序上正在发生的情况。如果用户对当前状态一无所知，很可能会感到愤怒并选择关闭网站或应用程序。

有效的微交互应该能够及时响应用户的输入，并提供即时的反馈。通过直接操作屏幕内容，可以吸引观众并促进学习过程。举例来说，Pinterest的设计允许用户操纵媒体，通过简单的拖放元素，根据需要移动和排序它们。这种直观的交互方式让用户感到更加亲近和参与。

微交互的设计应该注重在内容的基础上进行，使得用户可以更加专注地与内容互动，而不会因为繁琐的操作或过度花哨的界面而分散注意力。因此，微交互的力量在于为用户提供一个无缝、轻松的交互过程，以增强内容的吸引力和传达效果，这一点爱彼迎就诠释了。

四、如何设计微交互？

制作微交互对于设计师来说是令人欣喜的，因为它提供了尝试新设计解决方案和给用户带来惊喜的机会。

然而，在实现这一目标时，设计师需要记住以下几点：

• 设身处地为用户着想：要深入了解用户如何使用您的应用程序，通过各种手段了解他们的需求和行为习惯。
• 创建功能动画：动画不仅美观，还能增强用户体验，帮助用户更好地理解界面和操作。
• 提供乐趣和娱乐：用户体验是吸引用户持续使用应用程序的关键。如果用户享受使用应用程序并感到愉悦，他们会更愿意回来使用。
• 避免过度烦扰：过多的动画或干扰会适得其反，可能让用户感到厌烦，并导致用户流失。
• 使用人性化的语言：使用有趣和亲切的文案，可以让用户忘记应用程序中的不足，并增强用户与应用程序的互动。

总之，微交互的设计要考虑用户体验和用户需求，借助动画和有趣的文案，创造愉悦的交互体验，从而提高应用程序的吸引力和用户留存率。

五、最后我想说

在设计中，始终将可用性置于美观之上，这意味着用户友好性和易用性比纯粹的视觉吸引力更为重要。

因此，需要谨慎使用微交互，并进行测试和迭代，以确保其在实际使用中的有效性。

通过理解用户需求和行为，结合精心设计的微交互，可以提供更流畅、愉悦且有意义的用户体验，从而增强产品或应用的吸引力和成功度。