前言折腾了飞书日历，发现飞书待办任务不能同步到苹果提醒事项，后来想了想，飞书是通过CalDav服务的，那我是不是直接部署一个就可以了，然后就找到了Radicale轻量化服务，再编写一个auth插件，不就能接入agent了吗。Radicale CalDAV Server基于 Radicale 的 CalDAV/CardDAV 服务，配合自定义 API Key 认证插件，支持 iPhone/Mac 原生同步。功能CalDAV/CardDAV：标准日历和联系人数据存储API Key 认证：自定义插件，通过 HTTP Basic Auth 的 password 字段传 keyiOS/macOS 同步：原生支持，日历事件同步到"日历"，待办同步到"提醒事项"。安卓、鸿蒙也支持。Agent 集成：包含 OpenClaw/Hermes skill，支持通过自然语言管理日程和待办部署方式Clone项目：Radicale-CalDavAgentSkill方式一：Docker 一键部署（推荐）有 Docker 环境的直接用这个，最省事。前提Docker 和 Docker Compose 已安装步骤配置 API Keys# apikeys sk-your-api-key = your-username启动docker-compose up -d访问CalDAV 地址：http://127.0.0.1:5232停止docker-compose down方式二：宝塔面板部署（无 Docker 环境）服务器无法使用 Docker 时，用 宝塔面板 + Supervisor + Nginx 反向代理 + HTTPS。前提CentOS/Ubuntu 服务器Python 3.7+（推荐 3.7~3.11，Radicale 3.1.x 兼容性好）域名和 SSL 证书步骤创建站点和目录mkdir -p /www/wwwroot/your-domain.com cd /www/wwwroot/your-domain.com创建虚拟环境并安装python3 -m venv venv source venv/bin/activate pip install radicale==3.1.9复制文件到服务器config → /www/wwwroot/your-domain.com/configradicale_auth_apikey.py → venv/lib/python3.x/site-packages/radicale_auth_apikey.pyapikeys → /www/wwwroot/your-domain.com/apikeys编辑 config[server] hosts = 127.0.0.1:5232 [auth] type = radicale_auth_apikey apikey_filename = /www/wwwroot/your-domain.com/apikeys [rights] type = owner_only [storage] type = multifilesystem filesystem_folder = /www/wwwroot/your-domain.com/data/collections [web] type = none [logging] level = info编辑 apikeys# format: apikey = username sk-your-api-key = your-username宝塔 Supervisor 管理器添加守护进程启动命令：/www/wwwroot/your-domain.com/venv/bin/python -m radicale --config /www/wwwroot/your-domain.com/config运行目录：/www/wwwroot/your-domain.comNginx 反向代理server { listen 443 ssl; server_name your-domain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://127.0.0.1:5232; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # CalDAV 方法透传（关键！） proxy_method $request_method; } }⚠️ Nginx 默认会拦截 PROPFIND/REPORT/MKCALENDAR 等方法，确保没有 limit_except GET POST 之类的限制。API Key 认证HTTP Basic Auth：Username：apikeys 文件里配置的 usernamePassword：API Key示例（curl）：curl -u "your-username:sk-your-api-key" \ -X PROPFIND \ https://your-domain.com/iPhone/macOS 同步设置 → 日历/提醒事项 → 账户 → 添加账户 → 其他 → 添加 CalDAV 账户服务器：your-domain.com用户名：your-username密码：你的 API Key描述：Radicale日历事件进"日历"，待办（TODO）进"提醒事项"。安卓、鸿蒙同理配置。Agent 集成（Skill）skill/ 目录包含 OpenClaw/Hermes skill：scripts/caldav_client.py：完整的 CalDAV 客户端（增删改查）SKILL.md：使用文档直接说："添加日程：周五下午3点开周会""添加待办：买牛奶，明天截止"文件说明文件说明configRadicale 配置文件radicale_auth_apikey.py自定义 API Key 认证插件apikeysAPI Key 映射文件DockerfileDocker 镜像构建docker-compose.ymlDocker Compose 配置skill/Agent 集成 skill数据备份Radicale 使用纯文件存储，备份直接复制 data/ 目录即可：cp -r ./data /backup/radicale-data致谢Kozea/Radicale
最近工作中，总是会遇到一些在需求理解、UI设计上和开发产生分歧的地方，有的东西可能产品经理认为是常规设计，都能理解，不一定需要标注出来，但实际过程中并不一定所有的开发会这样思考，对于需求的理解也可能存在差异。这个时候就需要对产品或项目进行标准化规范，以解决需求设计、UI设计、开发流程上容易被忽视的问题。产品规范的存在，就是为了让设计更容易也更方便，团队之间步调一致、配合默契。产品规范就是队伍里的队规，让团队成员遵循一致标准，这样才能打造成风格统一、易用性强的优秀产品。大家可以根据实际工作流程来编写自己内部的产品规范，下面我根据我的工作流程整理了一份产品规范文档，仅供参考。1. 项目流程规范1.1. 产品开发流程1.2. Bug提出与处理流程Bug提出与修复Bug及时上报。评估严重程度、优先级、受影响的范围、时间范围、影响用户量，同步测试同学复现 bug。Bug 处理方案的决策。根据 bug 的严重程度和优先级来做第一轮判断。不严重的 bug、低优 bug 可以先进 backlog；未来版本可能改版或者废弃的模块产生的 bug，可放弃修复。处理需要修复的 bug。第一步是复现 bug，第二步是分析产生原因；第三步是给出修复方案。根据优先级和开发成本，在有了修复方案之后，需要在决策重新对 bug 进行修复的优先级排序。因为可能一个中优的 bug，需要巨大的修复成本。这种时候我们可能就需要将优先级稍稍往后，同时选择从产品或者流程上规避这个 bug。所以这个是对 bug 的再次梳理，给出新的方案。（可能涉及到跨部门协同）复盘先从 bug 的影响上开始分析，再从解决方案的决策上给出解释复盘研发链路上是否有疏漏整体上分析和回顾大的流程上是否存在问题，再从细节出深挖问题的根结给出避免的方案，不论是加强沟通还是统一编码风格，还是 code review 的加强从整体到细节，给出完整的 bug 原因，以及完整的避免思路2. 需求输出规范2.1. 需求设计规范需求设计时，要考虑或遵守如下7个方面：需求背景与目标介绍该需求设计的业务背景、市场环境和目标用户群体。明确项目的业务目标和预期的用户收益。梳理需求背景与目标，便于讨论需求合理性、可行性，便于后续需求归档。用户需求详细列出目标用户群体的具体需求。对这些需求进行优先级排序，划分紧急度与优先级。功能需求基于用户需求，详细描述系统所需实现的功能。包括功能的交互行为、约束条件、权限要求和性能要求等。非功能需求安全性：包括用户数据保护和系统访问控制。性能：如系统响应时间、并发用户处理能力。可扩展性与可维护性。操作日志要求等。数据管理如何收集、存储、处理和显示数据。数据初始化、存量数据处理等要求。数据保护和隐私方面的要求。设计原则 需求设计时，需遵循如下原则：操作简便：确保所有功能易于访问和使用。一致性：维持整个系统的设计风格和操作逻辑一致性。容错性：系统应能妥善处理用户的错误操作。反馈：用户在操作中能得到适时的响应与反馈。修订历史记录文档的版本控制。2.2. 需求文档输出规范传统需求文档，常常以纯文档形式输出，交互图写在文档内，对于开发者来说总是晦涩难懂。采用新的形式来呈现：依托于Axure制作的原型图，需求说明和设计说明直接融合在原型交互中。Axure文档结构如下：需求概述概述：需求背景、需求价值、功能点竞品分析版本更新日志需求说明功能需求：在原型图进行标注（页面说明、功能说明、交互注释）非功能性需求可以根据自己业务需求，编写自己的需求文档模板，注意如下内容：功能说明：对于每个原型图，都应该有一个简短的文本说明，描述该图所代表的功能或用户故事，确保开发人员不看文字描述时也能理解。交云层注释：使用Axure的“注释”功能，在原型上标注更加详尽的说明，如功能逻辑、交互规则、异常处理等。版本控制：原型的迭代很快，需要有一个清晰的版本控制机制，有修改请及时更新到原型或及时备注出来，确保团队成员总是在查看最新版本的文档和原型。非功能需求：性能指标、安全策略、响应时间等不方便在原型上表达的内容，需要在文档中另行说明。数据字典：如果产品处理复杂的数据，应该有一个数据字典或数据模型的说明，方便开发人员理解并按需设计数据库。附件与链接：将相关的技术文档、市场研究报告或其他参考资料以附件形式提供，或在文档中插入链接。导航和目录结构：如果需求文档内容繁多，应该有清晰的导航和目录结构，便于团队快速找到对应的部分。反馈和修订历史：文档应允许团队成员提供反馈，并记录修订历史，让每个人都能看到需求的变更。2.3. 数据埋点规范数据分析当前使用的神策数据，数据埋点请遵守神策埋点要求：数据融合 (sensorsdata.cn)埋点及数据分析等相关名词及使用指南参考神策帮助中心：产品使用指南 (sensorsdata.cn)3. 开发基础规范3.1. 基础控件使用规范3.1.1. 移动端当前我公司的小程序、APP未使用固定框架或组件，功能设计时需遵循一致性原则。以下罗列了常用的一些移动端框架或组件：WeUI：微信官方设计团队专门为微信内网及小程序量身定制的、同微信原生视觉体验一致的基础样式库。Material Design：Google Material 推出的全球顶级 React 组件库。Taro UI：京东凹凸实验室发布的 React 移动端组件库。NutUI 3.0：京东发布的 Vue 3 移动端 UI 组件库。对移动端友好，特别针对移动端电商业务场景优化测试。Tdesign：腾讯内部近 300 名设计师与开发者共同打造，经由 500+ 项目使用和验证过的企业级设计体系。Cube UI：滴滴团队开源的 Cube UI 移动端 Vue UI 组件库，轻巧趁手、质量可靠，由滴滴内部组件库精简提炼而来。Vant 4：赞团队开源的移动端 UI 组件库，性能极佳，组件平均尺寸小于 1KB （min+gzip），内置 65 + 个高质量组件，覆盖了主流使用场景中的多数需求。3.1.2. PC端当前后台系统前端框架使用的是Ant Design 3.x版本，组件及功能设计需遵循一致性原则，避免重复开发和风格不一致问题。下面会对Ant Design组件、功能等增加设计规范，以解决功能设计过程中、开发过程中出现的常见问题：基础控件的使用规范：Ant Design基础控件使用规范，需求设计与开发时请遵循一致性原则，尽量使用统一风格的组件库，增加复用性，同时一些组件在使用时要注意使用规范。3.2 开发常见功能规范3.2.1. 表格表格可采用多种展示形式，根据需求选择，数据展示时注意如下几点问题：表格排序。数据查询时，若未规定默认排序方式，使用id正序，避免无查询条件造成数据展示每次顺序不一致。排序还需考虑全局排序还是当页排序，非特殊情况，均为全局排序。表格分页，数据查询后，考虑是否可以做分页，聚合内容较为复杂时，根据数据量、用户需求考虑是否需要分页。查询数据类表格，尽量少使用表格直接编辑，容易造成数据误操作。表格操作列，表格操作列，无特殊说明，操作按钮不进行换行，操作列冻结。若操作按钮过多时，根据重要性，使用更多下拉按钮操作。表格数据统计，表若增加统计展示，统计与筛选数据统一。3.2.2. 数据查询在需求设计和开发过程中，有几个关键方面需要仔细考虑，以确保数据查询既有效又直观：查询条件应当从用户的视角出发，确定哪些字段是用户最有可能用于搜索的。条件的筛选复杂度，能否进行多条件组合查询，如范围查询、精确匹配、模糊搜索等。查询条件的默认值或最常见值，以简化用户操作。下拉筛选框，非单选必填选项，增加全部筛选项，避免多条件搜索时，无法去除单个条件。条件的输入方式，例如下拉菜单、输入框、复选框、日期选择器等。查询效率数据索引策略，确保常用的查询条件都有合适的索引。查询算法优化，避免慢查询或者超时。如何处理大量数据的分页和加载，可能涉及前端分页或后端分页等技术。缓存机制的使用，特别是对于那些不经常改变的查询结果。搜索框提示文字应简明直观，告知用户可以搜索哪些内容。可以使用引导性语言或者示例来辅助用户理解。在用户输入时，提供实时的自动完成功能。用户体验（UX）方面查询响应时间和进度反馈，避免用户由于不知进度而感到迷茫。查询结果的呈现方式，如何使结果清晰易懂且信息层次分明。如何提供有效的排序、过滤和高级搜索功能。安全性和权限限制对敏感数据的搜索，确保遵守隐私和合规要求。用户权限的控制，不同级别的用户可见和可查询的数据可能不同。技术和资源限制根据现有的服务器资源和技术栈来调整查询系统的设计。考虑在不同的设备和平台上的查询性能和体验。数据产品的反馈与升级设定日志和监控系统以追踪查询功能的使用情况。根据用户反馈对查询功能进行持续的改进。每个方面都需要根据用户需求分析来具体化，制定出符合实际应用场景的设计方案，并结合UI/UX设计来提高用户满意度。在开发阶段，以上方面也需持续迭代和完善，以确保查询系统的性能和易用性。3.2.3. 权限规范数据权限命名规则数据权限的命名需体现数据的范围和关联的模块，格式为 “模块 - 数据范围 - 数据内容”。其中，数据范围包括 “个人”“部门（主管）”“全公司” 等，数据内容为具体的数据对象。示例：“订单 - 订单审核管理 - 个人申请数据”“订单 - 订单审核管理 - 所有申请数据”。管理方式个人只能查看自己的客户信息，经理可查看本部门的客户信息，公司高管可查看全公司的客户信息。控制方式可通过 SQL 过滤或数据视图的方式实现数据权限的控制。对于 “个人” 数据权限，在查询数据时通过用户 ID 进行过滤；对于 “部门” 数据权限，通过用户所属部门 ID 进行过滤；对于 “全公司” 数据权限，则不进行额外过滤。（当前系统只有个人、主管及所有数据控制，暂无部门控制）页面权限命名规则页面权限的命名应关联页面的 URL 或菜单路径，格式为 “菜单层级 - 页面名称 - 页面类型”。其中，菜单层级体现页面在系统菜单中的位置，页面类型可分为 “列表页”“详情页”“表单页” 等。示例：“系统管理 - 用户管理 - 用户列表页”“订单 - 订单查询 - 订单详情页”。管理方式权限层级：页面权限分为菜单级和页面级。菜单级权限控制用户是否能看到某个菜单，页面级权限控制用户是否能访问该菜单下的具体页面。只有拥有菜单级权限，才能拥有该菜单下相应页面的页面级权限。分配原则基于用户角色分配页面权限集合。例如，管理员角色拥有所有系统管理相关页面的权限，普通用户角色仅拥有与其业务相关的页面权限。操作权限命名规则操作权限的命名需结合所在页面和具体操作，格式为 “页面名称 - 操作对象 - 操作类型”。其中，操作类型包括 “新增”“编辑”“删除”“查询”“导出” 等。示例：“用户列表页 - 用户信息 - 新增”“订单详情页 - 订单状态 - 编辑”“商品管理 - 商品数据 - 导出”。管理方式与页面权限的关联：操作权限依赖于页面权限，只有用户拥有某页面的页面权限，才能拥有该页面内相应的操作权限。粒度控制：操作权限的粒度应适中，避免过粗或过细。过粗可能导致权限滥用，过细则会增加管理复杂度。例如，在用户管理页面，“用户信息 - 编辑” 权限可涵盖对用户基本信息的修改，无需再细分为修改姓名、修改电话等权限。分配方式：根据用户在页面中的具体职责分配操作权限。例如，数据录入员拥有 “新增” 和 “编辑” 权限，审核员拥有 “查询” 和 “审核” 权限。操作日志记录：系统应对所有操作权限的使用情况进行日志记录，包括操作人、操作时间、操作内容等，以便进行权限审计和问题追溯。3.2.4. 国际手机号规范国际手机号组成规范国际手机号通常由国家 / 地区代码、地区号（可选）和本地号码三部分组成，具体规则如下：国家 / 地区代码：以 “+” 号开头，后续为 1-3 位数字（遵循国际电信联盟 ITU 规定），例如中国为 “+86”、美国为 “+1”、英国为 “+44”。地区号：部分国家 / 地区的手机号包含地区号，用于区分不同城市或区域，例如美国手机号的地区号通常为 3 位数字（如纽约为 212）。本地号码：除去国家 / 地区代码和地区号后的部分，长度因国家 / 地区而异，一般为 5-10 位数字。示例：中国手机号：+86 138 0013 8000（国家代码 + 86，无地区号，本地号码 13800138000美国手机号：+1 212 555 1234（国家代码 + 1，地区号 212，本地号码 5551234）存储规范字段类型：采用字符串类型（VARCHAR） 存储国际手机号，禁止使用数字类型（避免因前导零丢失、超长数字截断等问题导致数据错误）。字段长度：设置为 20 位字符（满足全球最长手机号存储需求，如某些国家 / 地区手机号含国家代码可达 15-18 位）。存储格式：统一存储为 “+ 国家代码 + 号码本体” 的紧凑格式，不包含任何分隔符（如空格、连字符 “-” 等），例如：正确：+8613800138000、+12125551234错误：86-13800138000、+44 7911 123456（含分隔符）3.2.5. 脱敏规范系统内脱敏遵循相同脱敏规则，使用相同脱敏方法，避免多地方显示脱敏规则不一致。姓名脱敏脱敏原则默认脱敏显示，增加权限控制可查看明文，但不可明文显示保留姓氏和名字的首尾字，中间部分用*代替。脱敏规则对于两个字的名字，如“张三”，脱敏后显示为“张*”，总字数为 2 个字。对于三个字的名字，如“李四强”，脱敏后显示为“李*强”，总字数为 3 个字。对于四个字的名字，如“司马相如”，脱敏后显示为“司**如”，总字数为 4 个字。对于六个字符的名字，如“爱新觉罗·溥仪”，脱敏后显示为“爱**仪”，总字数为6个字符。以此类推手机号脱敏脱敏原则默认脱敏显示，增加权限控制可查看明文脱敏规则前三后四显示，中间用四个*代替例如：188**8888账号、ID类脱敏脱敏原则对于系统内有一定安全信息的ID，需进行脱敏显示，如果复制使用，则增加复制按钮脱敏规则前四后二显示，中间用四个*代替例如：U328**32发货、收货信息脱敏脱敏原则默认脱敏显示，增加权限控制可查看明文脱敏规则省市区三级地址不脱敏，详细地址脱敏后三分之一，后部分用四个*代替例如：广东省深圳市龙华区民治街道布龙公路南侧梅观高速公路**3.2.6. 导入导入功能看似简单，需要考虑的问题很多，涉及的交互也很多。下面针对如下问题进行规范：数据校验。 a. 数据校验方式采用校验完成后返回全部错误或处理完成后返回全部错误，根据实际业务场景采用报错方式。 b. 优先是必填项不能为空，单元格内容格式正确。 c. 然后才是核对数据是否存在于基础数据库中。 d. 最后检测本次导入与已存在数的冲突性校验，比如重复。数据处理结果，部分成功还是全部成功。处理数据支持部分成功，则需要考虑可能返回的错误数量，20条以下，可以在弹框说明错误原因。过多就需要使用返回错误文件，让用户进行下载。导入方式：同步导入还是异步导入。若数据量较大的导入，请尽量使用异步导入，且增加异步导入进度框或进度条。若对数据有严格要求，若数据量小或需要进行下一步操作时，请使用同步导入，且增加导入进度框或进度条。数据处理：考虑导入覆盖，还是更新。数据导入时按固定模板解析，还是按字段进行解析。3.2.7. 导出规范注意按钮页面布局，焦点按钮一般放在左侧，导出、导入、下载类可选择放在右侧。导出全部时，必须筛选条件导出遵循所见即所得规则，不要导出的内容和显示的内容不一致导出条件，导出全部：导出筛选条件下的全部，导出勾选，导出勾选的数据 操作反馈 当前系统内的操作提示没有统一规范，报错和提示当前是混用的，后续需求设计与开发时，请严格遵守操作反馈规范警告提示 Alert。常用于分步骤表单、页面顶部提示等。 全局提示 Message。常用于系统报错等。 通知提醒框 Notification。常用于系统通知、异步导入导出操作等。 其余操作反馈详见Ant Design基础控件使用规范4. UI 设计规范UI设计规范需结合系统使用框架与内部自有设计进行规范化，由UI同学主导输出一套完整的规范化的设计规范文档。设计原则配色元素字体元素按钮元素图标元素图片元素基础控件元素动效规范不同尺寸适配间距大小IOS、Android设计尺寸市场手机屏幕尺寸参考
第一章大概是介绍结构和为什么写这本书，我就不多加阐述了，直接从第二章开始。一、从商品说起1. 一个买家的淘宝之旅淘宝的网站框架：第一种，Detail页面，好比新浪的一篇新闻，相对静态，主要用于展示信息。第二种，List页面，比如Baidu（百度）的搜索结果，是一个引导性的过程页面。第三种，交互页面，需要用户填各种表单、需要互动的页面，比如各大网站的注册页面。第四种，综合页面，就是其他很难分类的，或者前三种混合的页面，呵呵，比如淘宝的购物车页面，就混合了List和交互。2. 产品经理都是分类控随着商品多起来以后，才牵扯到分类。因为我们有了很多商品以后，就需要管理，而管理首先需要将商品梳理清楚，分清楚，不能10亿商品一个个管，这样做没有意义。“分类”方法的变迁是整个商品系统变迁的核心。3. 看似完美的类目+属性淘宝小二对业务的理解有一个过程，商品管理的本质是分类（再深究一步，分类是为了更好地匹配供求关系）。一灯，提出了属性的概念，属性很好地解决了前面提到的两个问题。与类目相比，属性更离散、更灵活，类似 Tag，一个商品只能属于一个类目，但可以有多个属性。属性的本质还是为了分类。属性的本质还是为了分类？其实很简单，卖家发布商品的时候，先从根目录选到叶子类目，再选择这个叶子类目对应的类目属性的各种属性值。体现在前台则是，买家在挑选商品的时候，也能从类目和属性两个维度筛选。4. 解决问题，而不是做产品解决问题，或者说满足需求，通常有三种方法——提高现实、降低期望、转移需求，而最常用的“开发产品”只是第一种，也是最费劲的一种方法。二、“淘宝”就是导购1. 淘宝的由来fun、生活化、亲切、屌丝气质……的格调，淘和宝。变化很多，但产品经理要理解变化背后的目的，以及哪些东西是不变的。2. 导购到底是什么玩意儿一群买家，从某个购物需求出发，通过某个产品功能，最终到达一个商品详情页面的过程，或者说，都是“导购”。2009年，一级类目的频道首页开始TMS（小二使用的，淘宝内容管理系统）搭建。这个强大的TMS工具颇值得一提，它可以根据各种条件，筛选商品、配制出活动页面，甚至配置出垂直市场而无须技术人员介入。从另外一个角度来理解导购，那就是经济学上的“供求匹配平衡”。我们通过对淘宝供求关系所处的不同关系的分析，制定我们的经营策略与重点，并以此为根据为买家提供购物决策产品。具体说明如下：当商品供应量远小于买家需求量时，需要为有需求的买家提供预订服务、资讯服务、订阅提醒服务。对有相应能力的卖家提供相关的情报，以刺激市场发展。当商品供应量近似于买家需求量时，关注需求的满足率，通过细分人群，为不同人群提供不同的导购决策产品，来降低流失率。当商品供求量远大于买家需求量时，需要对有需求的买家做优质商品和卖家的推荐，以及促销活动的推荐，并且针对不同人群提供不同的决策树。对没需求但有可能购买的买家做信息推送，以扩大需求量。同时为卖家提供付费型的营销工具。需要说明的是，产品经理们将针对特定类目甚至热门搜索关键词来判断上述供求关系。分得越细提升越明显。针对淘宝大盘整体分析，意义不大。90%的产品经理，其实都是在守江山，在已有的产品上做优化，如果能摊上做一个天猫这样的挑战，虽说失败的概率很大，但无论成败，都为个人之幸。产品经理确实就是小部分打江山、大部分守江山，历史也是这样的。天猫初始商品体系：天猫与淘宝的异同：从模式上，一个是C2C平台，一个是B2C平台对卖家和淘宝来说，天猫和淘宝的区别还是很大的：天猫的主要盈利模式是收取销售佣金，按照类目不同，从货款的百分之零点几到百分之几不定；而淘宝的盈利模式主要是各种广告。我们深刻地认识到，任何一款产品、一个公司，甚至一种业态都是有生命周期的，要想长青，只能自己打败自己。基于同样的思考，后来，我们又做了“C2B平台”的聚划算，因为消费者的需求越来越个性化，各种商业基础设施也日趋完善，大家都看好消费驱动生产是一个趋势，B2C只是零售，B2C平台是商业地产，都是老东西，而C2B才是产业链、经济模式的再造。回头看看淘宝，也是阿里巴巴B2B业务为了防止被eBay打败而做的。3. 向超市学习，前后台类目拆分简单地说就是：卖家通过后台类目发布商品，买家通过前台类目选择商品。类目拆分为前后台的好处很明显，用相对固定的后台类目可以衍生出一个随时变化的前台类目，后台类目满足卖家，前台类目满足买家，皆大欢喜。后来，淘宝网、天猫、电器城等都是在同一套后台类目的基础上衍生出了不同的前台类目，以满足不同的需求。4. 旧的新概念：SPU/SKU及其他像服装的话，品牌和货号，这两个属性值组合起来，能够形成一个唯一确定的产品——SPU。SPU相当于标准化的产品，通过关键属性的确定，就确定一个SPU，苹果的iPhone5S就是一个SPU。SKU（Stock Keeping Unit，库存量单位），2007年的淘宝产品经理们，没有什么线下经验，所以当时想了一个叫“最小购买单位”的概念，后来我们发现，它跟线下的SKU——标准库存单位——其实是一回事。商品管理的核心就是分类，那么广义上讲，商家、垂直市场等也是区分维度。不过垂直市场不是简单的分类，它是基于商品的特征，在分类无法提供的信息上进行了区分，那就是服务。对整个淘宝商品体系最熟悉的产品经理们认为，商品体系最大的缺陷，就是非常僵化。一个体系太严谨了，不一定是好事，它会很难有新东西涌现出来，没法进化。三、“搜索”的启示1. 从通用搜索到淘宝搜索淘宝搜索发展的三个阶段：第一阶段，list时期；第二阶段，isearch时期；第三阶段，淘宝搜索时期。淘宝搜索的首要目标就是让用户尽可能快地找到适合自己需求的商品，它也是一种典型的导购产品。与传统搜索相比，淘宝搜索在很多方面有相同点，例如用户均需要输入关键词然后返回若干条搜索结果，在搜索框输入时的下拉提示以及相关搜索等，但也有不少区别，这里先说说产品层面突出的不同。导航。导航即类目属性体系，是淘宝搜索特有的，其根本在于商品类似线下货架一样分类陈列。通用搜索，比如百度的搜索结果页是没有这个区域的。多维度排序。例如，可以按照销量、价格、人气分别排序，这是通用搜索没有的。突出图片。这是由用户需求决定的，因为大多数行业（尤其是服饰类）的商品，用户的第一感受是外观，而通用搜索通常突出标题和文本摘要。商品信息和筛选。淘宝搜索有较多的筛选功能，这些筛选与商品的各种详细信息（价格、所在地、销量等）的披露组合在一起，降低了用户决策和购买的门槛，相对于线下购物，是一种进步，也部分弥补了看不到实物的劣势。2. 效率与公平，买家与卖家如何通过搜索赚钱？方法就是让自己的宝贝在搜索结果中排名靠前，获取更多流量，让更多的买家来到自己的店铺。我们熟悉的“下架时间”、“橱窗推荐”、“人气排序”和“阿基米德”等，背后都是利益的平衡、博弈的升级、思考的深入。淘宝初期的主要排序因素是下架时间，早期的淘宝，卖家数量还不像后来这么庞大，我们希望每个卖家的商品都有曝光的机会，按下架时间排序无疑是对所有卖家最公平（程序公平）的排序规则，充分考虑了卖家之间的平衡。很快便出现了一些投机取巧的工具，甚至组建了专业的重复上下架团队。另外，当时开始出现卖家作弊的现象，比如，有的卖家会发布一万件商品来恶意引流。之后，我们会看到，只要有新的规则，卖家就会想出新的对策，spam和anti-spam[插图]永远是一对好基友。早期的淘宝，卖家数量还不像后来这么庞大，我们希望每个卖家的商品都有曝光的机会，按下架时间排序无疑是对所有卖家最公平（程序公平）的排序规则，充分考虑了卖家之间的平衡。橱窗推荐是什么？简单地说，就是每个卖家都可以给自己的宝贝打上橱窗推荐的标记，在list中，有橱窗推荐的宝贝会在排序上优先展示，就像线下的街边橱窗展位一样，这些位置的商品更容易获得消费者的关注，其实这已有广告位的概念。通过橱窗推荐，我们有了一个宏观调控、平衡流量的工具。在淘宝初期，它起到了很好的扶持卖家和规范市场的作用。直到现在的搜索排序中，橱窗推荐仍然是一个很重要的因子。跳出来思考一下，我们说很多互联网上的东西在线下都能找到类比。下架时间其实是模仿线下的柜台——平铺，找了一种随机、公平的排序方法；橱窗也是模仿，柜台里有一些突出的位置，比如临街。我们就体会到其中隐藏的一个大问题——生态系统的平衡。买家只关注自己是否能买到满意的商品，而且大多数希望尽可能有折扣、低价，其购买过程也希望“简单、傻瓜”，恨不得自己想要的东西直接就摆在面前。所以，不考虑个性化的模式，如果对买家都采用相同的排序，则通常把热销、低价、少数大卖家的商品排在前面，这些商品可能获得较好的数据表现。我们仔细分析了人气排序，发现主要有两大弊病。一是马太效应。人气排序的结果形成了一个封闭的循环，搜索结果页的前几位长期被少数大卖家占据，流量分配极度不平衡，两极分化越来越明显，中小卖家生存空间被挤压。在人气巨大的搜索流量面前，卖家开始通过打造“爆款”的方式使得排名靠前，给店铺引流。这样一来，虚假交易、刷销量的现象就开始滋长，并且变得越来越猖獗和专业化。这里暂且按下不表，后续讲反作弊的时候再给大家细细道来。二是覆盖率低。这其实也和马太效应相关，在搜索结果中，总有一批商品永远也得不到曝光，没法得到初始的流量，也就没法得到初始的销量，这对中小卖家和新手卖家不甚公平。而对淘宝来说，没有持续的新卖家加入、成长，就做“死”了。因此，当时淘宝虽对部分用户还是保留下架时间做默认排序，然而为了留住新买家，在他们进来时，又默认人气排序，或者，在年底冲刺销量的时候优先推荐人气宝贝。这种种做法，也可以看出搜索团队内心的纠结。我们再从根上想，对买家来说，什么样的排序是好的？无非两点：1是宝贝、卖家靠谱；2是可挑选的余地。“1”是买家，特别是新买家的基本需求，这个没解决，“2”就是扯淡，但通过之前的努力，现在“1”ok了，“2”就显得越来越重要了。问题已经抛出来，我们一直在试图解决，人气排序在2008年做了一次全新的改进和优化，之后几年也不断在优化。本章的最后一节所说的“个性化”、2012年开始提的“小而美”都是为了解决这个问题。我们想到的办法叫——阿基米德。这个革命性的产品，又是如何导致了“7.8事件”，让马云说出“宁可关掉公司也不会放弃原则”的呢？3. “阿基米德”与卖家的抗议传统搜索，通常使用准确度、覆盖度、更新度、速度等方面来评价，具体效果指标往往围绕CTR（Click Through Rate，点击率）展开，例如CTR以及点击位置、点击间隔时间等。而淘宝搜索基于电子商务的特殊性，能够掌握用户整个过程的数据，所以更关注最终结果，也就是成交有关的数据，例如成交转化率、成交额、客单价。但有一个指标也很重要，就是基尼系数[插图]，这是衡量流量分配的重要参考指标。“阿基米德”既能满足买家利益，又能保证卖家公平，还可以使得淘宝这个生态系统有活性，可以持续涌现出新东西。它的主要特点有两个：一个是将人气排序和时间轮播结合起来，另一个是增加了卖家服务质量的因素。从本质上讲，这几次错在我们对卖家的理解不够。事情本身都是好的，但做法有些激进，在短期内让卖家感到较大的不安全感。回到搜索，这也是淘宝搜索和通用搜索的一大区别——它更密切地影响着上百万人的生计，再好的变化，也需要稳步进行，不能让市场剧烈波动。所以现在搜索再有什么大改动，一定会慢慢地灰度发布，至少三五个月才改完，让卖家有足够的时间去适应、去改变。我们“正反合”地认识到，一个好的系统，应该是机器算法和人的思维相结合，必须要有人在里面“玩”，这个系统才会有“新”涌现出来。我们想用人的智慧来帮助算法进化，如果没有人的参与，机器的进化效率会低很多。系统中，一定有部分人喜欢完全靠算法，放弃选择，我们就让他们生活在Matrix里；也一定有部分人，喜欢自己挑选商品，我们就给他们建立一个“锡安”。我们“正反合”地认识到，一个好的系统，应该是机器算法和人的思维相结合，必须要有人在里面“玩”，这个系统才会有“新”涌现出来。我们想用人的智慧来帮助算法进化，如果没有人的参与，机器的进化效率会低很多。系统中，一定有部分人喜欢完全靠算法，放弃选择，我们就让他们生活在Matrix里；也一定有部分人，喜欢自己挑选商品，我们就给他们建立一个“锡安”。4. 从技术到业务，解决“局整矛盾”搜索需要在处理业务需求的基础上，将需求中的共性问题提炼出来，抽象成一些平台性的基础需求，集中力量办大事，平衡局部利益与整体利益、短期利益与长期利益。5. 心态的修炼，从罚人到度人随着反作弊的进行，我们逐渐开始了一些反思：作弊方式其实是我们引导出来的。卖家刷销量是因为销量影响排名，而且销量是参加活动的门槛、直通车的门槛，买家看信用，多数买家喜欢买销量多的……所以其实是淘宝整个环境决定的。算法的完善总是离不开人的智慧。类似搜索排序，我们又想到了让卖家和买家来一起参与，这就是——搜索诊断助手和举报系统。反作弊走到今天，从罚商品到罚卖家，到帮卖家，再到帮小二，帮助整个市场。我们越来越清晰地认识到，反作弊不只是搜索团队要做的，而是全站要共同考虑的。6. 从商品到产品，一站式的理想先简单回顾一下搜索排序的发展，下架时间只考虑了卖家间的公平，橱窗兼顾了效率，人气考虑了买家，但是矫枉过正，整个市场马太效应明显，小卖家没机会，所以阿基米德综合考虑，弱化了销量的影响，使得整个生态系统更活。淘宝想到了把标品的导购过程拆分：“先选产品（SPU），再选卖家”。因此在2010年，搜索很重要的方向就是：基于产品库的标类垂直搜索。它的特点就是以产品节点为基础，整合点评、资讯、知识问答、图片等购前、购中、购后的信息，为用户提供全方位一站式的购物搜索体验，甚至可以搜到淘宝外，其他网购站点的商品，从而提升用户黏性，留住和吸引更多的用户选择用淘宝搜索来进行网络购物，将淘宝搜索打造为互联网购物入口。淘宝的搜索，从下架时间排序到个性化搜索，全靠顺势而为：五年前做个性化的投入产出比肯定不高，三年前如果还仅仅用下架时间排序也显得落伍。在合适的时间做合适的事情，在正确的时间遇到正确的人，都是一种幸福。四、电商还是商1. 下架的“招财进宝”加盟招财进宝的搜索在前面，引起广大卖家不满，最终下架。广告的投放需要合理。2. 淘宝团购到聚划算早期淘宝团购做不起来而聚划算成功的原因，可能为早期团购模式没有想清楚；聚划算在团购市场蓬勃发展的适合出现；淘宝土壤孕育了强大的营销团队。聚划算做的人不懂淘江湖规则，淘江湖不推单品单店，而聚划算与淘金币恰好相反；所以规则是人定的，事件环境变化，我们需要重新推演规则，不被规则所困。聚划算是一种供应链的改进，是社会模型的再造，让买家发声。3. C2B与预售，交易的未来预售的难点：发货时间：发货时间不确定；预售分批发货怎么发；现货与预售同时存在怎么发货预售数量：现货与预售库存同时存在怎么处理；要分仓分批库存怎么处理？预售价格：预售让消费者等待，价格是否要更低、预售怎么促销叠加？预售订金：预售定金怎么处理；分期付款怎么支持？五、“下单”之前1. 支付宝、交易系统的诞生问题：卖家收钱不发货，买家收货不付款怎么办？解决：最牛逼的产品经理马云提出“担保交易”的概念，即资金中介；最终商品在淘宝，交易在支付宝解决了这个问题。问题：第一个买家100块，第二个买家想改为80块，不能，会把以前的交易价格也改掉；另外支付宝与淘宝界面风格也非常不同，怎么办？解决：支付宝与淘宝分开。支付宝做支付，淘宝管商品和交易，引入宝贝快照的概念保存到交易系统问题：快照占据存储空间过大怎么办解决：逐步缩减关键信息问题：宝贝修改了，出价记录就清空了。而卖家不想这样，希望能保留怎么办解决：改为不管宝贝信息是否修改，都会保留最近一个月的出价记录，并说明有过变化2. 购物车的诞生2008年前都没有购物车，只有收藏夹。不做的原因：不同卖家的交易不可能合在一起，所以没有，导致的结果为：弊端运费模板无效，只能跟卖家说改价格。权衡之后增加了购物车：运费模板真正有用；花样促销开始
产品经理经典面试题问题拆解与思路
导语：本人2021年毕业，工作近两年，最近准备面试，总结一下网上经典面试题及个人思路，希望对初中级产品有一定帮助。一、产品经理具备的能力与素质不同级别的产品经理面试时考察的能力是不一样的，我主要讲下产品所需要的基本能力。产品所需的能力一定跟所要做的事情息息相关，所以这个问题的拆解思路就是项目或需求的执行思路。需求的处理流程从需求处理的流程，也就能了解到产品经理所需要的基础能力有哪些。需求获取在需求获取阶段，我们需要做好收集需求和管理需求两件事情，数据的来源，我一般分为三种：数据分析、业务需求、产品规划。这也就要求我们具备数据分析能力、管理能力、同理心。需求分析 需求分析主要从需求要素、定位、分解、优先级四个方面进行。这样就要求我们具备逻辑思维能力、分析能力、同理心。方案设计方案设计时一般需要做：方案设计、方案对比（竞品分析）、可行性分析、方案确认。我们需要具备学习能力、分析能力、创造力。方案执行方案执行需要需求评审、确认迭代内容（需求优先级管理）、测试验收。需要我们具有执行力、沟通协调能力（项目推动能力）。需求管理与优化功能完成了并不代表结束了，需求方案上线还只是开始，要想知道这个需求是否真正达到了预期效果，发挥出了真正价值，还需要持续跟踪监测。需要我们具备数据分析能力、管理能力。综上，从需求处理流程，我们也就知道了产品经理所需要的基础能力和素质是哪些：执行力学习能力沟通协调能力（项目推动能力、团队合作能力）逻辑思维能力分析能力创造力同理心当然，这只是基础能力，要成为高级产品经理还需要很多能力或思维方式。二、项目延期怎么解决此问题考察的是沟通协调能力以及项目推动能力。第一点，项目延期怎么处理？了解情况：了解不能按时上线的原因及需要延期多长时间上线；知会需求方：确定影响范围，知会需求方，讨论解决方案；确定解决方案：协调资源解决；或者砍掉非核心功能保障上线时间点。第二点，怎么避免项目延期？保障产品文档质量，避免需求变更导致延期，前期沟通评审功课做足；合理评估时间，设置任务里程碑，及时跟进进度，发现风险点；建立一个内部网络空间，所有文档资源统一存放，供团队成员共享；制定制度和标准，实行奖惩措施，制度和标准及其重要。三、做过的项目中，你觉得最成功的的项目或者产品是哪一个，为什么？首先这个问题考察2个点：第一个即什么才能算成功的项目或者产品，从3个方面回答：这个项目或者产品给用户带来了哪些价值（用户体验、服务提升、解决了什么痛点），给公司带来了什么价值（产品带来了多少利润，提升了多少用户量，提升了多少活跃等），自己在项目中获得了什么（能力的提升，价值的体现，解决了什么问题）。第二个考察的点即是项目描述的能力，产品经理能不能很好的对项目进行复盘，能不能清晰描述一个完整的项目经历。这里很多文章都提到过的STAR法则，运用这个法则可以很好的描述一个项目，这里就不展示论述。产品经理要学会讲好一个故事，让面试官不感到枯燥。四、产品的需求来源有哪些个人在做需求的时候将需求划分为三个来源：业务需求。用户意见反馈、客服反馈、用户调研访谈、内部其他业务方需求等。数据分析。很多时候的需求都需要数据支撑，并不一定业务需求就合理，也需要数据支撑做分析。产品规划需求。产品自身迭代过程中规划的一些大功能模块等需求。五、你怎么去划分需求的优先级划分需求优先级可以采用两种方式，一种是紧急重要度划分，第二种是采用KANO模型去划分。紧急重要度划分比较简单，这儿简单讲下KANO模型首先需要对需求分类：基本需求，期望需求，兴奋需求，无差异需求，反向需求。其次是按照要求对优先级进行划分，划分标准按照用户满意度（需求价值）和实现难度来进行。基本需求 > 兴奋需求 > 期望需求 > 无差异需求，其中兴奋需求和期望需求还需要再根据具体情况来讨论。基本需求：必须要有的基本需求，没有用户会很不满意，有了用户也不会为此感到满意；期望需求：如果这个需求有，用户会感到满意，如果没有用户满意度会下降；兴奋需求：如果这个需求超过用户预期，达到用户兴奋，则会满意感大大提升，没有的话用户满意度也不会降低；无差异需求：又或者没有，都不会影响用户的满意度，用户不在意； 反向需求：少数派需求，做了就会产生负面影响。六、你的产品方法论是什么简单的产品方法论可以从需求处理流程来思考：需求来源（需求获取）、需求分析、方案设计、方案执行、需求管理与优化。当然，要成为大佬，肯定不能只有这点简单思考。下面讲几种大佬的产品方法论。1. 苏杰：Y模型和四轮MVP理论Y模型苏杰的Y模型很硬核，告诫我们不要按用户的反馈指导出方案，要充分挖掘用户背后的真实需求。①是代表用户需求场景，是起点，是表象，是需求的第一种深度，观点和行为，即在什么场景下什么目标用户的什么时间操作下的什么需求；②是代表用户需求背后的目标和动机，需求的第二种深度，用户为什么要提出这个需求，最底层的动机是什么？我们在思考用户目标时也要综合考虑公司、产品的目标；③是代表产品功能，是我们根据用户需求深度剖析得出的解决方案，是实施人员能看懂的描述；④是代表人性需求，即马斯洛需求，或者说是需求的第三种深度价值观，而深度是需求的本质。我们可以将我们在需求分析的过程，形象地将该流程抽象化为Y模型，大部分的需求分析流程只需要经过 ① -> ② -> ③ 流程，将用户需求转化为产品功能即可，而较为复杂的需求则需经过 ① –> ② –> ④ –> ② –> ③ 流程才能进行提炼。四轮MVP模型分析完Y模型，苏杰又提出了四轮MVP理论，四轮即Paperwork（纸面研究）、Prototype（原型）、Product（产品）、Promotion（推广），这是产品上线的四个必经关卡。通俗点讲，就是想清楚、做出来、推出去，按部就班。在用户侧，随着用户的发现、启程、习惯、精通，产品功能模块也会逐步完善，直到产品1.0的生命周期完结，产品从验证期、过渡到爆发期，再到平台期走向衰退时完成2.0改版。2. 梁宁：痛点痒点爽点痛点是恐惧。有一种痛点的解释是：“对于产品来说，痛点多是指尚未被满足的、而又被广泛渴望的需求。”梁宁认为这种说法是不对的，没有被满足，用户只是难受而已，不能拿用户的难受作为痛点，或者产品的切入点。痛点：一个是激发人的“恐惧”，一个是激发人的“性本能”。首先用户要有需求，当这个需求不能够得到满足以后，会不断产生恐惧。需求得不到满足是因为目前没有产品能够解决这一个“性本能”，当这个需求越发膨胀的时候，才会出现恐惧，恐惧到一定程度，就成为了我们说的痛点。有需求，还能被即时满足，这就是爽。爽点，用户的需求能即时满足。人在满足时的状态叫愉悦，人不被满足就会难受，就会开始寻求，如果这个人在寻求中，能立刻得到即时满足，这种感觉就是爽。游戏，无疑是把即时满足，把爽点做到极致的一类让人上瘾还很难戒掉的产品。你看到一个人展示出了勤奋、规整、自律，其实这是因为被一些列的恐惧、集体人格、潜意识压迫，才会呈现出那样样子。痒点满足的是人的虚拟自我。痒点，要满足用户想象中的自己。比如，我们看偶像剧，追星，看网文，看英雄故事，看网上的名人八卦，看名人的创业故事、成功神话。你是在热追他们吗？不是，你情不自禁投入到关注的内容，是你的虚拟自我，是你自我想象的一个投射。3. 俞军：价值公式和交易模型用户价值 = (新体验 - 旧体验) - 替换成本泛学科是产品思维的有力补充当前产品圈价值公式、交易模型等经典理论，一半以上都是俞军提出的。俞军老师无论是在百度还是滴滴，操盘的都是大用户量级、复杂多赛道交织的产品。所以这种环境历练下，你很难去关注微观产品细节，因为太片面，难以驱动整个平台的利益。重剑无锋，大巧不工，只有掌握宏观产品思维，才能驱动一把把这么巨大的重剑。在处理所有宏观问题时，经济学当仁不让是第一学科。经济学不但是钱和决策的学科，还是人和心理的学科，作为宏观的产品底层思维而存在，再合适不过。俞军说，在经济学思维之下，用户不再是人，经过解构、整合到本质之后，变成了一个个需求的集合。用户价值只是天平的一端在俞军产品宇宙中，企业和用户在天平的两端，通过产品这个媒介完成价值互换，创造整个系统的价值增量。进一步说，企业投入产品经理、程序员、设计师和运营等资源，来创造好的产品，让用户在使用产品的过程中，获得价值，从而企业分成。产品的研发资源和维护资源不会增长，随着用户越来越多，价值越来越大，整个边际收益也越来越大。但，并不是无脑投资源创造新的用户价值就可以，还有诸多限制条件。最大的限制是，企业资源是有限的，用户需求是无穷的，把用户价值拉满，企业价值不管不顾，最后就是ROI过低，叫好不叫座，产品崩盘。其次，从用户分群来看，不同小群体的用户价值还可能有冲突，不同产品模块之间也会有影响，好的方面会形成化学反应，稍有不慎就会不进反退。少即是多所以俞军老师又提出：产品就是一组约束条件下的一个效用组合，它满足了不同场景下的一个个需求。产品经理对产品的迭代优化也是需要基于场景来不断的优化的，每一个优化都需要考虑是否达到roi最优，即从产品定位上、产品方法上是否最优。也就是说，做产品不是无脑功能堆叠。产品应当被视为是一个提供价值的效用组合或模型，而产品经理要做的，是模型的最优调参。用户价值是主观的而到底怎么衡量价值，要看用户怎么想。价值是用户感受到的主观效用，即：用户的幸福程度=效用除以欲望。用户期望越大，在一定的效用下，幸福程度越低。在产品效用一定的情况下，随着用户的胃口（欲望）越来越大，他们的满意度会逐步递减。比如网约车补贴大战时的滴滴在回归理性市场之后，优惠券从10元降低到5元，用户满意度骤降。虽然5元优惠券比正常的出租车还是便宜很多（效用更高），但用户因为习惯了10元优惠券的预期（欲望），导致对5元优惠券不满足。所以俞军告诉我们，做产品不单单要关注产品效用，还得分析场景下用户的预期（欲望）程度。用户体验体现在场景中用户的欲望，会驱使用户在产品上做出各式各样的行为，比如抖音短视频的精彩推送，会激发用户享乐的欲望，不断刷新下一条观看，逐步上瘾。拆解用户行为来看，俞军指出了每一次行为的决策逻辑：用户，拥有某种认知，在某个场景下，带着某种期待，获得了怎样的体验。这个公式可以用来分析产品的功能设计，是否让用户愉悦。具体到产品里面，就是著名的价值公式：用户价值=新体验-旧体验-替换成本在拆解产品目标，衡量需求优先级上，俞军的价值公式可谓第一公式。俞军教会我们，只有学会从各个角度，用交易、体验、需求、痛点来分析用户行为，才能层层深入触摸用户心智，形成深层的情感连接。七、你最近最喜欢的APP是哪款这个问题很深奥，除了会考察产品的体验、思考，还有你的逻辑思维能力，对新鲜事物的敏感度等。不要挑微信、微博、淘宝这类很大众的产品，最好和你业务相关且有了解的。除了考察上述能力外，还会让你用此款产品做推荐、总结、竞品分析等。一定要提前准备好一个比较熟悉和喜欢的产品进行研究。除此之外还可以参考大佬的文章，看下大佬怎么回答这类问题：面试官问你最喜欢的一款APP是什么？用这两种逻辑回答八、请描述一下你在产品设计过程中的思考方式，以及如何保证产品的用户体验了解用户需求：通过调研、访谈等方式了解用户需求，从而确定产品的功能和特性。确定产品目标：根据用户需求和市场情况，确定产品的目标和定位。保证用户体验：在产品设计过程中，始终以用户为中心，注重用户体验，从而提高产品的使用价值和满意度。九、如何做产品规划确定产品目标：产品经理应该先明确产品的目标和定位，包括产品的核心价值、目标用户、市场定位、商业模式等。这是产品规划的基础，需要深入了解用户需求和市场环境，制定出具有针对性和可实现性的产品目标。进行市场调研：在确定产品目标后，产品经理需要进行市场调研，了解市场趋势和机会，识别用户需求和行为，评估竞争对手的产品和优劣之处等。市场调研可以帮助产品经理深入了解用户和市场，发现产品的差异化竞争优势，为产品规划提供可靠的数据和信息支持。制定产品策略：在了解市场和用户后，产品经理需要制定产品策略，包括产品定位、功能设计、用户体验、商业模式、营销策略等方面。产品策略需要综合考虑产品目标、用户需求、市场趋势和竞争对手等因素，确保产品具有创新性、建设性和开创性的特点，同时能够实现商业价值和用户价值的平衡。确定产品规划：在制定产品策略后，产品经理需要确定产品规划，包括产品的开发、测试、上线、迭代等各个阶段的具体任务和时间安排。产品规划需要综合考虑资源、时间和风险等方面的因素，确保产品的顺利推进和实现。结合数据分析和洞见：在产品规划和推进过程中，数据分析和产品经理的洞见都是非常重要的。数据分析可以提供关键的信息和见解，帮助产品经理了解用户需求和行为、优化产品设计和功能、评估产品性能和市场表现等方面。产品经理的洞见也是至关重要的，通过深入了解用户需求、市场环境、竞争对手等方面，把握市场趋势和机会，制定有效的产品策略和规划。数据分析和产品经理的洞见结合使用，可以为产品开发和优化提供更全面和深入的支持。产品规划是一个系统化的过程，需要综合考虑产品目标、市场趋势、用户需求和竞争对手等因素，并结合数据分析和产品经理的洞见，制定有效的产品策略和规划，十、你觉得需要给用户交付一个什么样的产品算好产品一个好的产品需要满足用户的需求和期望，提供有价值的功能和优秀的用户体验。具体来说，以下是我认为需要考虑的几个方面：产品功能：产品应该提供用户需要的核心功能，并确保这些功能的可靠性和易用性。这需要产品经理深入了解用户需求，并结合技术和资源的实际情况进行合理的平衡和取舍。同时，产品还需要不断地进行功能迭代和优化，以满足用户的变化需求。用户体验：产品的用户体验应该简洁、直观、易用、美观。用户需要在使用产品时获得良好的体验，包括产品的响应速度、页面设计、信息展示、操作流程等方面。良好的用户体验可以增强用户对产品的信任感和忠诚度，提升产品的口碑和用户满意度。数据安全和隐私保护：在产品开发和运营过程中，保障用户的数据安全和隐私是非常重要的。产品需要采取相应的技术和管理措施，确保用户数据不被泄露或滥用，同时遵守相关法律法规和行业标准。商业模式：产品还需要有可行的商业模式，可以为企业带来商业价值，同时也为用户提供有价值的服务。商业模式需要考虑产品的定位、用户需求、市场环境、竞争对手等因素，确保产品的商业可行性和长期盈利能力。一个好的产品需要综合考虑产品功能、用户体验、数据安全和隐私保护、商业模式等因素，为用户提供有价值的服务和体验，并为企业带来商业价值。十一、如何处理团队内部冲突当团队内部出现冲突时，你可以从以下几个方面处理：理性沟通：首先要保持冷静，理性沟通，了解各方的意见和需求，找到问题的根源。寻求妥协：在了解各方需求的基础上，寻求妥协，找到一个双方都能接受的解决方案。寻求第三方帮助：如果双方无法达成妥协，可以寻求第三方的帮助，如上级领导或人力资源部门。团队建设：通过加强团队建设，增强团队凝聚力和协作能力，从而减少冲突的发生。十二、你在团队协作中的角色和贡献团队协作：在团队中，你的角色是协调各部门之间的工作，促进团队协作，确保项目按时完成。任务分配：你需要根据各部门的能力和资源，合理分配任务，确保项目进度和质量。冲突处理：当团队内部出现冲突时，你需要理性沟通，寻求妥协，或者寻求第三方帮助，从而解决问题。团队建设：你需要加强团队建设，增强团队凝聚力和协作能力，从而提高团队的工作效率和质量。十三、数据分析的常用方法7种常用的数据分析方法，你掌握了吗？十四、如何平衡用户需求和业务目标平衡用户需求和业务目标是任何企业的核心挑战之一。以下是一些方法，可以帮助您平衡这两者之间的关系：确定用户需求：首先，您需要了解您的用户需求。这可以通过调查、用户研究、分析和反馈来实现。通过了解用户需求，您可以确定哪些方面对他们最重要，这可以帮助您优先考虑这些需求。确定业务目标：同时，您需要清楚地了解您的业务目标，以及哪些因素对实现这些目标最为重要。这可以通过确定关键绩效指标（KPI）来实现。找到重叠点：在确定用户需求和业务目标后，您需要找到它们之间的重叠点。这些重叠点代表了您可以为用户提供价值并实现业务目标的领域。优先考虑重叠点：在设计产品或服务时，优先考虑这些重叠点，并尝试在这些点上找到最佳平衡点。这意味着您需要确定一个解决方案，既满足用户需求，又能实现业务目标。评估和优化：定期评估您的产品或服务的性能，并根据收集的数据进行优化。这有助于确保您的产品或服务能够持续满足用户需求和业务目标。需要注意的是，平衡用户需求和业务目标是一个不断演变的过程。随着市场变化和用户需求的变化，您需要不断调整您的方法和策略，以确保您的产品或服务保持竞争力并满足用户需求。十五、如何对产品进行市场定位和竞品分析客户细分：了解您的潜在客户和目标市场。这可以通过研究目标市场、竞争情况和潜在客户的需求和偏好来实现。根据不同的客户需求和市场特点，将您的产品或服务进行细分，以便更好地定位和营销。竞品分析：研究竞争对手的产品或服务，了解其特点、定价、市场占有率等。这可以帮助您确定自己的产品或服务的竞争优势和差异化点。产品特点：分析您的产品或服务的特点和功能。这包括产品的可靠性、性能、易用性和安全性等。了解您的产品的优劣势可以帮助您进一步确定市场定位。定位您的产品：基于您的目标市场、竞争情况和产品特点，确定您的产品的市场定位。这意味着确定您的产品或服务如何与竞争对手不同，并确定您的目标市场如何最好地接受您的产品或服务。市场趋势：了解市场趋势和行业变化，如技术趋势、客户需求变化、法规和政策变化等。了解市场趋势可以帮助您发现新的机会，并根据趋势调整您的产品定位和市场策略。用户调研：通过用户调研了解客户需求和反馈。了解客户需求可以帮助您更好地满足客户需求，并不断优化您的产品或服务。十六、如何进行产品项目管理制定产品规划：确定产品的目标、范围和功能。这可以通过对市场需求和竞争情况进行研究，并与利益相关者交流以获得反馈来实现。制定项目计划：在产品规划的基础上，制定项目计划，包括时间表、任务和资源分配。这可以通过项目管理工具和技术来实现，例如甘特图、流程图和关键路径分析等。确定团队成员：确定需要哪些专业技能和资源，以支持产品规划和项目计划。这包括开发人员、测试人员、项目经理和其他相关职能。实施产品开发：在产品规划和项目计划的基础上，执行产品开发。这包括产品设计、开发、测试和上线等步骤。在执行过程中，需要不断跟踪和调整项目计划，以确保项目进度和目标的实现。管理项目风险：对项目风险进行评估和管理。风险可能包括技术风险、资源风险、时间风险和财务风险等。需要制定相应的风险管理计划，并不断监测和应对风险。评估项目绩效：对项目绩效进行评估和监测。这可以通过监测项目进度、成本和质量等指标来实现。需要定期进行项目审查和评估，以发现问题并制定相应的纠正措施。产品规划和项目管理需要制定详细的计划和团队组合，跟踪和调整计划以确保项目的成功。重要的是，要不断地与团队成员和利益相关者进行沟通和交流，以确保项目按照预期顺利进行。十七、如何对产品进行持续改进和优化定期评估用户反馈：了解用户对产品的反馈和需求，以发现潜在的问题和改进点。可以通过用户调查、反馈表单、用户分析等方式收集用户反馈。分析数据和指标：分析产品的数据和指标，以了解产品的表现和用户行为。例如，通过分析访问量、转化率、用户满意度等指标，可以了解产品的强项和改进点。设计实验和测试：设计和实施实验和测试，以验证产品的改进和优化。例如，A/B测试和用户测试可以帮助确定新功能或设计的效果和用户接受度。优化产品设计和用户体验：优化产品的设计和用户体验，以提高产品的易用性和用户满意度。可以通过改进界面设计、流程设计、交互设计等方式实现。不断更新和改进产品：持续更新和改进产品，以保持竞争力并适应市场变化。可以定期发布新版本，添加新功能或改进现有功能。持续学习和改进：不断学习和改进自己的产品开发技能和知识，以提高产品的质量和效率。可以参加培训、研讨会和社区活动等。持续改进和优化是产品成功的关键步骤。需要不断跟踪和分析用户反馈和产品数据，设计实验和测试，优化产品设计和用户体验，并持续更新和改进产品。通过持续学习和改进自己的产品开发技能和知识，可以提高产品的质量和效率。十八、如何进行产品的用户测试和迭代设计测试计划：首先需要设计测试计划，明确测试的目标、测试场景、测试人员、测试指标等。测试计划可以包括多个测试阶段，例如功能测试、用户体验测试、性能测试等。招募测试用户：招募测试用户，可以通过社交媒体、用户研究公司、自有用户群体等方式招募。需要确保测试用户具有目标用户的特征和特性。进行测试：根据测试计划，组织测试用户进行测试。可以使用各种测试方法，例如问卷调查、用户访谈、用户行为记录等方式收集测试数据和反馈。分析测试数据和反馈：根据测试数据和反馈，进行数据分析和用户反馈分析，以发现潜在的问题和改进点。可以使用数据分析工具和用户反馈工具，例如Google Analytics、Hotjar等。提出改进方案：基于测试数据和反馈，提出改进方案和优化措施。需要明确改进方案的优先级和影响范围，以确保改进方案的有效性和可行性。实施改进：根据改进方案，实施产品的迭代和改进。可以使用敏捷开发方法，快速迭代产品的设计和功能，以满足用户需求和反馈。再次测试和迭代：在改进实施后，进行再次测试和迭代。重复上述步骤，直到产品达到用户期望和要求的水平。产品的用户测试和迭代是确保产品成功的关键步骤。需要设计测试计划，招募测试用户，进行测试，分析测试数据和反馈，提出改进方案，实施改进，再次测试和迭代。通过快速迭代和改进，可以确保产品满足用户需求和反馈，并保持竞争力。为什么要工作这个问题我面试的时候没有回答好，我的回答是：1. 为了更好的生活。2. 人其实闲下来一段时间会感到焦虑的。这个问题我也不知道怎么回答，大家有兴趣可以去看下这篇文章：我们为什么要工作？_评论频道 - 凤凰网为什么做产品经理比较好的回答方式：个人兴趣：平时喜欢互联网，喜欢了解各种互联网产品，看他们解决了什么问题、定位是什么，为什么设计这样的产品功能。如果能自己做出一款改变一些人的产品，一定会很棒！能力：产品经理除了需要沟通、组织协调等能力，还需要有比好的同理心、逻辑思维、商业敏感度、行业理解能力。而这些里面，我个人的同理心、商业敏感度比较好。比如xxx例子。个人成就感：往大了说，如果有成千上万的人使用自己的产品，那是多么骄傲和自豪的事情，能够给我带来巨大的成就感。一个成功的产品一定是解决了某个或某些问题，体现出自己的商业判断和创造力，商业上的竞争是残酷也是充满激情的，如果能够获胜，那也能有英雄一样的体验吧！往小了说，如果产品没有价值，是没有人会用的，所以产品经理是在创造价值。挑战：产品经理被说成是指挥官，拥有很多需求的决策权，拥有决策就要承担相应的责任。能否带领项目走向成功，过程中需要花费非常大的努力、协调各种资源、不断的提升和突破自己，这种挑战和新知识的学习，非常能激发我的斗志。未来的发展：产品经理能够提升一个人的综合能力，其中不仅仅包括行业理解力、产品设计能力、需求分析等专业能力，还包括沟通能力、学习能力、执行能力、日常管理能力、领导力等通用能力，可以极大的促进自己各方面的学习与成长。我希望未来自己通过产品经理的锻炼，综合能力有更好的提升，未来能够成长为一个商业leader或者CEO。这个回答全面了很多，能够让人感受到候选人对产品经理这个岗位的理解有一定的深度，对自己的兴趣、能力、未来的发展规划也比较清晰。其实一个人在做职业规划会用到一个模型，就是趋势+能力+梦想。趋势：认可这个行业或者岗位的未来发展能力：要说明自己的能力有哪些可以匹配的上的，毕竟是人家选择你，你没点能耐谁愿意培养你呢梦想：有梦想驱动的人，未来才能走的远，才有更好的成长空间同样，我们在思考问题和回答问题，也可以套用这个模型。然后再对里面的模块进行拆分细化参考资料产品经理经典面试题整理：问题拆解与回答思路需求系列（一）——需求处理流程产品经理面试必备常见10道题及解析优秀简历法则：从star法则到start法则（简历系列2/3）大咖们的15条产品方法论，你都知道吗？需求分析 | Y模型梁宁：什么才是最好的产品？紧扣痛点、爽点、痒点深度解析 | 俞军的产品方法论为什么做产品经理？
一、决策、信念与行为偏差​ 认知偏差多半会影响信念的形成、商业与经济决策、以及其他一般的人类行为它们是可复制与再现的，面临特定情境时，一般可预期人们会有相应的偏差倾向。1. 不明确性效应(Ambiguity Effect)我们倾向于避免未知，决策时避开资讯不足的选项。示例：用户在决策时，会避免自己不清楚的选项，我们可以通过添加明确的细节来最大程度地减少歧义，提高转化率。CTA（行动召唤） 按钮应在其旁边包含信息性标签，以清除不确定性。2. 锚定效应(Anchoring Effect)人们在对某人某事做出判断时，易受第一印象或第一信息支配，就像沉入海底的锚一样把人们的思想固定在某处。示例：一个很简单地销售经典案例：三款产品价格、功能如下，最终销量如下。产品价格功能数量销量A130元31,200B440元9890C390元8200,000消费者的想法：A比起另外两个有点太便宜了，功能也少了很多，看起来质量也很差。B、C看起来功能差别不大，价格还差了不少，仔细看了C缺的功能，觉得没必要为了这个鸡肋的功能多花50元，于是把注意力放到了C上。C比A功能强大，比B物美价廉，还等什么？这就是锚定效应的威力，商家的精准刀法就是利用锚定效应。在用户认知价值的过程中，锚定效应是最关键的因素。3. 注意力偏差(Attentional Bias)一个人过度关注环境中的特定讯息 ，此时个体会忽视其他讯息 。注意力偏差可以解释一个人在被现有的思路占据时，没有考虑其他的可能性。示例：我们用淘宝购买一个确定型号的键盘，打开app后，我们第一时间就是找搜索栏，然后输入型号，从结果列表选择我们喜欢的。这个过程中，我们通常不关心app一共有几个tab页，也不关心首页上摆放了哪些东西。对于无关信息的不关注程度，其实超乎我们的想象。认知心理学把这个现象叫做“看不见的黑猩猩现象”。4. 获得性启发(Availability Heuristic)我们认为那些迅速跃入脑海的事情比那些不容易想起的事情更为常见和重要。因此，最近发生的、频繁发生的、极端的、被记住的事情比大多数信息更有影响力。示例：通过创建一些与众不同的东西（在不影响一致性和熟悉度的情况下）让你的设计被记住。5. 可获性层叠(Availability Heuristic)这个心理效应有一个更简单的描述，叫做三人成虎，也就是一件事越常被公开谈论，人们就越相信这件事。示例：创建一个醒目的标语，并确保重复多次。如果可能，这个标语以押韵结尾会更好。6. 确认偏差 Confirmation Bias当人们本来就持有某种观点时，对这种观点的感知和注意度会被放大，会选择性地回忆或收集关于它的事例。人们对于自己原本就相信的观点会更容易接受，而把反面观点搁置在一旁。示例：在用户研究中，当你的预设想法是用户对A设计的满意度比B设计更高时，在研究中你可能会更关注用户提到的A设计的优点、收集更多用户对于A设计的正面评价。当用户表示对A设计满意时，会觉得“果然是这样”。这种偏误会让你遗漏许多其它信息。7. 逆火效应(Backfire Effect)我们不能轻易改变人们的信念：与根深蒂固的信念相反的证据和论据无济于事，只会巩固信念的地位。这是一种更严重的确认偏差，即当假设被相反的信息否定后，我们反而更加深信自己原本的假设。示例：外卖骑手或者四级听到其他用户、客服或者平台官方提供的证实他们的猜想是错误的信息后，有不少人反而会觉得“他们都是不清楚真相的”或者“官方的辟谣肯定是心里有鬼”，继而更加深信自己的猜测是正确的。8. 从众效应(Bandwagon Effect)我们经常会因为大多数人以同一种方式思考，而改变我们自己的想法。示例：我们在设计中可以营造出一种群体选择的效果来吸引更多的用户，通过展示购买人数和滚动播放购买信息来体现出该商品的热门，让正在犹豫的用户「随大流」下单购买。9. 信念偏差(Belief Bias)我们更倾向于接受与我们的先验知识相符的论点，而拒绝对该论点的反驳。示例：谈论产品的好处时，不要夸大其词。如果它好到让人无法相信，那么人们将不会相信它。10. 选择支持偏差(Choice-Supportive Bias)做出决定后，我们倾向于称赞我们选择的选项，然后降级其他选项。示例：在用户做出购买决定并成功达成交易之后，是用户分享产品（或添加评论）的绝佳时机；显示肯定的信息，并祝贺他们达成了这一步骤以激励用户。11. 知识的诅咒(Curse of Knowledge)当我们是某个领域的专家时，会不知不觉假设其他人和我们具有相同的理解能力，尤其是对于专业术语的使用。这个偏差来源于斯坦福大学心理学博士论文中的一个实验，实验要求一位敲击者在桌子上敲出一首耳熟能详的歌曲（如《祝你生日快乐》）的旋律，而另一个人作为听众辨认歌曲。敲击者认为，听众能正确识别出大约50%的旋律，结果实际的正确率只有2.5%。敲击者为什么会过分高估听众的正确率呢？因为敲击者时常随着敲击声而感受到曲调，对于他们来说，旋律听起来非常清晰和明显；但听众听不到音乐，只有手指敲击桌面发出的低沉的声音，即使努力辨认，也只是像怪异的摩尔斯电码。示例：考虑一下大多数用户，他们的技术水平可能不如你想象的那样，并且对你熟悉的事物也不太熟悉。我们作为产品经理可谓是“全知”的存在。但我们做任何功能，都要假设用户的信息是缺失的和不完整的，而且缺失的和不完整的也经常不一样。用户的认知程度参差不齐，我们不止要拥有同理心去思考他们的想法，还要摆脱知识诅咒去体验他们的视角。12. 诱饵效应(Decoy Effect)引入第三个选项来加强旧选项的吸引力。示例：假设有产品 A 和 B，以下是顾客可以选择的选项：(1) ¥100 – A(2) ¥300 – B(3) ¥300 – A + B在这个情景，（2）是“诱饵”，用来引导顾客选择“目标选项”（3）。13. 差异偏差(Distinction Bias)在有比较项存在的时候，我们对微小的差异变得敏感，而实际上，这些差异并不是很大。示例：在竞争对手旁边展示你的产品优势，以便用户注意到差异，即使是一个很小的差异。14. 禀赋效应(Endowment Effect)和没有拥有的物品相比，用户更倾向于保留自己拥有的物品。他们倾向于高估自己拥有的东西，而忽略其客观的市场价值。示例：禀赋效应是损失规避（loss aversion）的一种表现形式，免费试用是禀赋效应的最常见用法。一旦用户开始使用某种产品并投入了一段时间，那么在试用期结束时，他们很难放手而停止使用。当用户准备离开时，他们会觉得自己即将失去很多美好的事物。15. 功能固着(Functional Fixedness)指个体在解决问题时往往只看到某种事物的通常功能，而看不到它其他方面可能有的功能。这是人们长期以来形成的对某些事物的功能或用途的固定看法。示例：当产品挑战到现有的使用传统时，可能会引起一些可用性挑战。请确保进行可用性测试，并尝试提前解决这些潜在的问题。16. 巴纳姆效应(Barnum Effect)也称佛瑞效应。人们会对于他们认为是为自己量身定做的一些人格描述给予高度准确的评价，而这些描述往往十分模糊及普遍，以致能够放诸四海皆准适用于很多人身上。示例：在产品文案中，尽量避免使用“大家”，“用户”等描述，使用诸如“你”，“你的”之类的可以更贴近用户，人们理解规范性信息时，存在一种选择性代入感，这种代入感会让人无意识地专注于选择贴合自己认知和经验，从而产生一种“我也是这样”的归属感。17. 框架效应(Framing Effect)面对同一个问题，在使用不同的描述后，人们会选择比较有利或者更顺耳的描述。框架效应的基础是损失厌恶。示例：在大多数情况下，正向表达（例如玻璃杯已满一半）的转换率会更高。18. 频率错觉(Frequency Illusion)首次引起我们注意后，我们很快就会从很多地方注意到相关信息。例如，如果某人想购买一辆新车，通常会突然发现到处都是这辆车。示例：推动广告系列时，使访问者在不同的营销渠道中接触相同的内容，让别人觉得你的产品周围都是，加深这种新产品的印象。19. 后见之明偏差(Hindsight Bias)后视偏见会让人沉迷于“我早就预料到了”这种感受当中，无法真正从事件中汲取到有用的经验，也难以用公平的眼光来评判客观事物和他人，主观上也很容易选择性地忽略许多客观事实。示例：后视偏见会给人带来快感，但也会在工作中影响决策的正确性和公平性，从而带来潜在风险。纠正后视偏见的方法就是在知道事情结果之前，记录下自己的想法，事后做验证并统计相关数据。20. 当下偏差(Current Moment Bias)又称现时偏差，人们更倾向于获取即时收益，而非未来的更大收益。示例：为用户的立即购买提供小折扣（或免费送货），而非承诺他们在将来购买时提供更大的折扣。21. 可辨识受害者效应(Identifiable Victim Effect)我们倾向于同情一个特定的人而不是匿名的某一个人。示例：在讲产品故事时，请使用个体案例，而非一般性陈述。22. 宜家效应(IKEA Effect)宜家效应是指人们倾向于高度评价他们参与创造的产品，消费者对于一个物品付出的劳动（情感）越多，就越容易高估该物品的价值。示例：利用宜家效应提高用户粘性的核心是创造低投入、高回报、高贡献价值的任务，保证用户能够完成任务的基础上贡献自己的价值。在学习场景中我们可以利用宜家效应提高用户粘性，将用户留下来坚持学习。23. 影响力偏差(Impact Bias)我们倾向于高估未来情绪状态的持续时间或强度。示例：描绘在没有你的产品或服务下用户会遭遇的问题，然后，介绍你的产品会如何解决这些问题。24. 资讯偏差(Information Bias)因测量误差所导致的一种偏误现象，有时亦称为观察偏误或分组错误。示例：在展示产品或服务时（在网站上或app内），请确保附有详细说明的照片。在产品说明中获得的信息越多，用户获得的保证就越大。25. 沉没成本谬误(Sunk Cost Fallacy)我们在某件事上投入越多就越难放弃它。因此，我们往往会继续执行这个走向失败的行动，仅仅是因为我们过去已经在此投入了过多的时间、金钱或精力。示例：当游戏玩家支付了每月30元的会员费时，很多人会强迫自己继续玩游戏，因为他们已经在虚拟游戏中投入了大量时间和金钱。26. 损失趋避(Loss Aversion)指人们面对同样数量的收益和损失时，认为损失更加令他们难以忍受。损失带来的负效用为收益正效用的2至2.5倍。损失厌恶反映了人们的风险偏好并不是一致的，当涉及的是收益时，人们表现为风险厌恶；当涉及的是损失时，人们则表现为风险寻求。示例：限制特价交易的时间以产生紧迫感：“此优惠在x小时内结束”。27. 单纯接触效应(Mere Exposure Effect)人们会单纯因为自己熟悉某个事物而产生好感。它表明某一外在刺激，仅仅因为呈现的次数越频繁（使个体能够接触到该刺激的机会越多），个体对该刺激将越喜欢。示例：坚持使用用户熟悉的 UI 概念、行为、术语、符号和图标。在营销材料、网站和产品上保持一致来优化漏斗，用词保持和行业术语一致，确保你的用户感到舒适。28. 负面偏差(Negativity Bias)相比于中性或者积极的事物，具有负面影响的事物对人们的心理影响更大。示例：通过解决负面体验来说明你的产品价值，如果希望自己的故事能够产生更大的影响,就要尝试多展现情感上负面的内容。29. 忽略可能性(Neglect of Probability)当我们承受压力时，我们没有想到风险发生的可能性。结果，较小的风险可能会被高估或被忽略。示例：在转换漏斗中，最小的不确定性可能导致用户对产品的不信任并停止使用。需要确保所有细节均清晰明了并预先显示，尤其是涉及金钱的事物，例如总成本，折扣（如果存在），附加成本等。30. 乐观偏差(Optimism Bias)与别人相比，我们经常高估自己成功的几率。示例：请确保产品没有隐藏任何可能破坏乐观偏见的令人不愉快的功能（例如额外的费用，可能的延误等）。31. 鸵鸟效应(Ostrich Effect)我们故意避免负面信息（或与我们的期望不一致的反馈），认为如果我们把头埋在沙子里，它们就会消失。示例：与客户支持一起并肩工作，主动去看什么让用户困惑，从处理用户投诉中可以学到很多东西。32. 规划谬误 (Planning Fallacy)我们倾向于低估完成一项任务所需的时间，通常规划谬误会导致时间超支，成本超支或收益不足。将大型任务分解为较小的部分有助于解决这些问题。示例：将你的初始估算值乘以2，不，实际上是3。这样做不是因为你懒惰，而是因为你的估计可能是错误的。33. 对抗心理 (Reactance)当我们感到某人（或某物）试图剥夺或限制我们的选择时，对抗心理就会发生。当它发生时，我们有一种抵制它并采取相反行动的冲动。示例：当你与用户“争论”他的选择时要小心，说服对方时必须循循善诱，永远不要与用户直接对抗。34. 自制偏差 (Restraint Bias)人们经常会高估自己控制冲动行为的能力。示例：我们都认为“标题党”属于旁门左道，但我们还是陷入其中，不是吗？35. 韵律当理由效应 (Rhyme as Reason Effect)人们会更容易把有韵律的、押韵的句子，当作是真实和准确的。一句话只要变得有韵律了，那么就更有说服力了。示例：大部分广告语都朗朗上口，非常洗脑。所以，尽可能的把你的产品文案变得有韵律感，这样更容易说服用户。36. 风险补偿(Risk Compensation)也称佩尔兹曼效应。当我们感觉到更大的风险时，我们会变得更加谨慎，而当我们受到更多保护时，我们就会没那么谨慎。所以当我们知道在已经采取了很多安全措施以后，我们更有可能采取冒险的方式行事。示例：在购买或注册前让用户对产品产生尽可能的安全感，让他们获得信心和信任。37. 选择性知觉(Selective Perception)我们对事物的看法在很大程度上受到期望的影响，当人们集中注意力时，人们会从环境中过滤掉事物。示例：产品的转化漏斗并没有在用户登录时开始，而是在用户首次看到你的广告时就开始了。营销信息与产品提供内容之间的不一致会让你的用户大失所望，从而导致转化率的下降。在所有媒介上（漏斗的各个阶段）的消息一致将为用户带来正确的期望，从而提高转化率。38. 幸存者偏差 (Survivorship Bias)过度关注幸存下来的人或事物，忽略那些被筛选掉的人或事物（可能因为无法观察到），从而得出错误的结论。示例：在需求分析和调研过程中，如果忽视了幸存者偏差，很有可能搜集到的数据，体现的仅仅只是少部分用户的需求和想法，最终将伪需求和小众需求当作主要需求来作为设计，从而让产品从一开始就走向万劫不复。39. 零风险偏差 (Zero-Risk Bias)我们喜欢确定性，即使它适得其反。在有其他方案可以降低整个风险的情形下，仍倾向于完全消除某一项风险的偏见。一个例子是刻意降低个人负责领域的风险，可是代价是整个组织风险的上升。示例：提供退款保证和无风险试用，以降低风险水平，使你的用户感到安全。40. 感知价值偏差 (Perceived Value Bias)我们根据产品的外观或服务方式来感知其价值。正如人们所说：全部在包装中！示例：设计对于产品的成功比你想象的更为重要，多余的空间，错误的边框颜色和未对齐的文字，都会影响转化率，确保UI设计的优先程度。41. 分析瘫痪 (Analysis Paralysis)又称选择超载。当出现太多选择时，我们的大脑就会瘫痪，很难进行选择。示例：选择太多 = 转换率低42. 稀缺效应 (Scarcity Effect)我们将稀缺物品的价值提高，将高可用性物品的价值降低。害怕错过（FOMO: fear of missing out ）使我们更容易受到诱惑和冲动，并促使我们做出轻率的决定。示例：使用“限时优惠”，“有限数量” 等修辞来形容你的产品或服务。给人的印象是许多人正观看此项目，并随时可以抢走最后的几件物品。43. 流畅性启发 (Fluency Heuristic)我们认为那些处理速度更快、更流畅、更顺利的事物具有更高的价值。有时不合逻辑的论点在沟通良好的情况下（由有权威和经验的人提出）也可能会赢得胜利。示例：为用户提供便利（快捷、简单和易于理解的导航）使内容易于浏览（图像，易读的字体）创建“心理捷径”，它将吸引用户，促使他们把你的产品作为首选提供有意义的默认选项，因为用户会认为你考虑了他们的最大利益，并将尽可能选择默认选项添加功能强大的跨产品搜索，以简化特定主题的查找二、社会偏差社会偏差这些偏差大多是由归因偏差导致。44. 行动者-观察者偏差 (Actor-Observer Bias)行动者喜欢将他们自己的行为归因于情境性因素，而观察者喜欢将同样的行为归因于行动者稳定的人格素质。示例：我们会用外在、不可控的情境性原因来解释自己的行为，比如上班迟到是因为路上出了意外。但是当我们作为观察者，试图对别人的行为进行解释时，我们会用内在的、稳定的人格原因来解释，比如上班迟到是因为他懒、没有时间观念。45. 达克效应 (Dunning–Kruger Effect)我们无法认识到我们缺乏能力，并且由于无法分辨能力好与能力差的不同，因而认为大家都一样。示例：能力差的人通常会高估自己的技能水平；能力差的人不能正确认识到其他真正有此技能的人的水平能力差的人无法认知且正视自身的不足，及其不足之极端程度；如果能力差的人能够经过恰当训练大幅度提高能力水平，他们最终会认知到且能承认他们之前的无能程度。46. 错误共识效应 (False Consensus Effect)人们倾向于高估别人对自己的认同程度，想象其他人像我们一样，并分享我们的观点，信念，偏好，价值观和习惯，认为所有人以同样的方式思考。示例：在没有涉足政坛（或特定国家）的情况下，你最近对你所在国家的选举结果是否感到惊讶？47. 基本归因谬误 (Fundamental Attribution Error)解释他人行为时，归因于内在特质（一定是他有这样的人格，才做出这样的行为），而非外在情境（也许是情势所迫，或这个场所有特殊的潜规则）。基本归因谬误是矛盾和问题的常见来源，而且这种认知偏差存在于用户也同样存在于设计师本身。示例：需要设计师能够清楚地分辨「我的观点」和「我的行为」，能够真正将自己从自己所处的立场、角色、职能上抽离出来，复盘整个局面。首先接纳全部的现实，包括他人的想法、观点，先不去判断对错，明白事物的动态变化过程。不要再单一地去判断，因为任何一个视角必然会存在一个立场，它们是当前事物诸多层面中的一方面而已。48. 晕轮效应 (Halo Effect)人们对他人的认知首先根据初步印象，然后再从这个印象推论出认知对象的其他特质。也就是，人们对人的认知和判断往往只从局部出发，扩散而得出整体印象，即是常常以既定印象概全。示例：通过使用权威照片和可建立信任关系的视觉效果来充分利用这种具有启发式的方法。49. 群内偏差 (Ingroup Bias)群内偏差常被用来引导用户决策，它是指人们会在认知上倾向于自己所属的群体。在体验设计中利用群内偏差的关键点在于打造群体归属感，借由小群体的力量影响用户的决策。示例：比如 Booking 在查看评论的区域加入了筛选评论语言这一按钮，虽然设计的本意可能是为了方便用户更好地理解评论内容，但是在真实的使用过程中可以发现，用户更加信任自己所选标签内的评论内容，因为同语言往往意味着来自相同的国家或者相近的文化背景，用户通过这种方式找到一个小群体，然后被影响进而做出与群体内人们更为相似的决策。50. 权威偏见 (Authority Bias)我们认为权威人士给出的建议准确性更高，并且更容易受到该建议的影响（即使事物主体与该人物的权威性无关）。示例：通过宣传产品的知名推荐来建立权威:联系有影响力的人，让他们免费使用你的产品或服务突出显示知名客户或品牌展示来自社会名流的推荐语在产品展示和陈述中使用权威人物（例如医生、教授等）51. 得寸进尺法 (Foot-in-the-Door Technique)得寸进尺法又译登门坎效应，是一种通过先提出一个简单的小请求来说服用户同意一个较大请求的劝说方法。示例：通过提供免费试用与用户建立联系。不要用过于复杂的引导流程让用户感到不耐烦。把大块的内容分解成小块或容易解决的内容，让用户保持开心和参与度。三、记忆错误与偏差记忆错误与偏差在心理学和认知科学中，记忆偏差是一种认知偏差，导致记忆的强化、弱化（包括能否想起的机会、想起所需的时间，或两者皆有），或者记忆内容的改变。52. 谷歌效应 (Google Effect)我们会容易忘记可以在网上轻松找到的信息。示例：你还记得你最好的朋友或孩子的电话号码吗？53. 幽默效应 (Humor Effect)当信息被认为是有趣或幽默时，我们会更好地记住信息。这可以帮助提高产品的转化率，并有助于整体业务的提升。示例：在用户可能感到沮丧的情况下不要幽默。例如，如果你的应用与旧设备不兼容，请不要用有趣的方式说出来，因为此时用户可能很沮丧，无法感知幽默。54. 真相错觉效应 (Illusion of Truth Effect)重复的事情越多，我们就越相信。示例：在广告，网站，App Store页面，登录页，新闻通讯等一次又一次地重复你的消息（主要好处，主要区别）55. 峰终法则 (Peak-End Rule)用户不仅仅根据平均或所有体验的总和来评估体验，取而代之的是，他们的大脑会严重地偏向峰值（高或低）和体验的终点，峰值如果是愉悦的话，通常对应了用户旅程中令人难忘的愉悦感。示例：通过使产品的最佳功能变得更好，保持产品的竞争优势并提高产品高峰。另外也不要忽视产品的“购买后”体验，确保以精湛的品味结束体验。56. 图片优势效应 (Picture Superiority Effect)图片和图像比一千个单词更容易被记住。示例：始终在内容中包含图像，出色的视觉效果将提高转化率。57. 首因效应 (Primacy Effect)又称近时效应、序位效应。列表开头和结尾的项目比中间的项目更容易被用户记住。示例：如果你打算展示一长串信息，请确保第一个是最重要的内容。58. 雷斯多夫效应 (Von Restorff Effect)当很多信息一起呈现时，醒目的信息和被特别强调的信息会比其他信息更容易被人们记住。示例：确保CTA按钮以不同的样式，大小，颜色和位置显示出来，以达到不同的目的。59. 蔡格尼效应 (Zeigarnik Effect)进行中的任务会产生特定于任务的张力。当任务完成时，这种压力可以缓解，但如果任务被中断，它将保持不变。这种张力使相关信息更易于访问和记忆。示例：显示一个不完整的进度栏，以鼓励用户实现自己的目标。四、统计与几率偏差统计与几率偏差几率性推论是指根据有关几率的资讯推论事情的可能性，而几率的估算通常来自统计资料，因此两者密不可分。60. 基本比率谬误 (Base Rate fallacy)我们倾向于忽略一般信息，而只关注特定案例。示例：不要只分享那些冷冰冰的产品信息。相反地，展示其他相关用户或公司的评价、用例。如果你想更具有说服力 —— 把你的量化数据和一些个人故事相结合。用量化数据合理地支持你的观点。具体的例子会在情感上传递你想表达的信息。61. 赌徒谬误 (Gambler’s Fallacy)我们错误地认为，如果在给定时期内某件事情频繁发生，那么这件事情在将来发生的几率就会很小。示例：坚持事实，少依靠直觉，更多的依靠数据。62. 热手谬误 (Hot-Hand Fallacy)错误地认为经历过成功的人更有可能在其他尝试中进一步获得成功。一般是在某人近来做某事很成功时，认为他未来做同一件事也会很成功，而忽略其成功可能只是随机与巧合导致。示例：通过强调一系列成功案例来建立自己的强大品牌。63. 对样本数不敏锐 (Insensitivity to Sample Size)我们经常忽略样本大小并贸然下结论，即使样本数量还未达到足够的统计量。示例：与客户沟通很重要，但不要把产品设想建立在几次面谈的基础上。使用大量数据，并根据实际数据而非假设来做出产品决策。五、实验与研究偏差实验与研究偏差这是一些科学实验或统计研究容易发生的偏差。64. 取样偏差 (Sampling Bias)某些类型的用户被无意中从研究参与者池中剔除了。亦可理解为以偏概全，即以局部事例解释整体原因。示例：你正在设计自行车跟踪应用，需要对骑行者进行研究。你决定采访并观察北京市的自行车骑行者，但你没有意识到他们的骑行行为习惯可能与居住在山丘多的郊区的骑行者有很大不同。因此你的研究成果可能有不适用于所有目标受众的风险。65. 观察者期望效应 (Observer-Expectancy Effect)研究者有时可能会期望出现某种结果，他们无意识地操纵了试验过程，或者错误地解释实验结果，导致研究结果严重歪曲。示例：在用户研究中，研究者的表情、肢体语言等都可能会反映出自己所期待的结果，如果用户察觉到了这些，就可能做一些迎合研究者期望的反应。66. 社会期许偏差 (Social Desirability Bias)我们倾向于多表达符合社会期许的事情，而隐瞒那些不符合社会预期的事情。例如在询问是否有不良嗜好、性伴侣数量时，大家会有意无意地隐瞒或淡化实情。示例：社会证明是建立信任的好方法。以下是可在产品页面上使用的一些示例：知名的客户logo知名的合作伙伴logo客户的好评和真实推荐（来自目标受众）累计数据（客户数量，交易次数等任何有价值的数字）媒体的提及和引用由知名组织颁发的奖项认证证书真实数据支撑案例的链接不要说“我们很棒，因为……”，而是通过其他人来证实。67. 遗漏变数偏差 (Omitted-Variable Bias)当获得的奖励出乎意料之外，我们获得奖励的喜悦感就会增加。示例：为用户提供每日优惠，**奖金，奖章，奖品等。每天创建的“动作”越多，用户就越会感受到与产品的联系。参考资料常见认知偏差手册（共5大类67条）产品思维：从新手到资深产品人 (豆瓣) (douban.com)晕轮效应 - 维基百科，自由的百科全书 (wikipedia.org)
1. 软件测试概述1.1 软件测试的定义(1) 1983年，IEEE给软件测试的定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。(2) 1990年，IEEE再次给出软件测试的定义：①在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价；②分析某个软件项以发现现存的和要求的条件之差别并评价此软件项的特性。以上的定义都有一定的片面性。不能只对系统程序进行测试，找出系统程序中的错误，而对分析、设计等过程发生的错误视而不见。软件产品由文档、数据和程序组成，那么软件测试就是对软件开发过程中形成的文档、数据以及程序进行相关的测试。1.2 软件的缺陷等级划分软件缺陷的等级可以用严重性和优先级来描述：严重性：衡量缺陷对客户满意度影响的满意程度，分为致命错误，可能导致本模块以及其他相关的模块异常，死机等问题；常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误， 如服务器500错误。严重错误，问题局限在本模块，导致模块功能失常或异常退出；常见的有：功能未实现，功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。一般错误，模块功能部分失效；常见的有：操作界面错误，边界条件错误，提示信息错误，长时间操作无进度提示，系统未优化，兼容性问题。建议模块，有问题提出人对测试模块的改进建议。优先级：缺陷被修复的紧急程度；立即解决(P1级) ：缺陷导致系统功能几乎不能使用或者测试不能继续，需立即修复；高优先级(P2级) ：缺陷严重，影响测试，需优先考虑；正常排队(P3级) ：缺陷需要正常排队等待修复；低优先级(P4级) ：缺陷可以在有时间的时候被纠正。2. 软件测试的目的对于软件开发。软件测试通过找到问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题和不足，预防下次缺陷的产生。对于软件测试来说。使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件饿质量，也为以后软件测试积累丰富经验。对于客户需求来说，软件测试能够检验软件是否符合客户要求，对软件质量进行评估和度量，为了客户评审软件提供有力的依据。3. 软件测试的分类3.1 按测试阶段分类单元测试。验收软件单元是否符合软件需求与设计，开发人员自测。通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。单元测试的策略：逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、数据流分析。集成测试。将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。自顶向下集成：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。自底向上集成：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。系统测试。将软件在实际环境中运行，并与其他系统的成分(如数据库、硬件等) 组合在一起进行测试。检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。是黑盒的。测试重点是整个系统的运行以及与其他软件的兼容性。系统测试包括：功能测试，性能测试，可靠性测试，安全性测试验收测试。主要对软件产品说明进行验证，按照说明书的描述对软件产品进行测试，确保符合客户的各项要求。它的测试数据通常是系统测试的测试数据的子集。验收测试包括正式验收测试，非正式验收测试：Alpha测试(α测试)和Beta(β测试)测试。3.2 按测试技术分类黑盒测试。也称功能测试或数据驱动测试。把软件(程序) 当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。* 常用的黑盒测试方法有：等价类划分法、边界值分析法、因果图法、场景法、正交实验设计法、判定表驱动分析法、错误推测法、功能图分析法。 * “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，因此不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 白盒测试。又称逻辑驱动测试，结构测试。测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件(程序) 当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。* 常用白盒测试方法： * 静态测试：不用运行程序的测试，包括代码检查、静态结构分析、代码质量度量、文档测试等等，它可以由人工进行，也可以借助软件工具(Fxcop) 自动进行。 * 动态测试：需要执行代码，通过运行程序找到问题，包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。 * 白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化： 1.语句覆盖每条语句至少执行一次。2.判定覆盖每个判定的每个分支至少执行一次。3.条件覆盖每个判定的每个条件应取到各种可能的值。4.判定/条件覆盖同时满足判定覆盖条件覆盖。5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。6.路径覆盖使程序中每一条可能的路径至少执行一次。3.3 按照软件质量特性分类功能测试。测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。性能测试。测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。3.4 按照自动化程度分类手工测试。测试人员一条一条的执行代码完成测试工作。费时费力且很难保证测试效果。手工测试优点：1、测试人员具有经验和对错误的猜测能力。2、测试人员具有审美能力和心理体验。3、测试人员具有是非判断和逻辑推理能力。手工测试缺点：1、重复的手工回归测试，代价昂贵、容易出错。2、依赖于软件测试人员的能力。自动化测试。借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。自动化测试的优点：1、对程序的回归测试更方便。这可能是自动化测试最主要的任务，特别是在程序修改比较频繁时，效果是非常明显的。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。2、可以运行更多更繁琐的测试。是可以在较少的时间内运行更多的测试3、可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的4、更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。5、测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。6、测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。7、增加软件信任度。由于测试是自动执行的，所以不存在执行过程中的疏忽和错误，完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后，软件的信任度自然会增加。自动化测试的缺点：​ 1、不能取代手工测试​ 2、手工测试比自动测试发现的缺陷更多​ 3、对测试质量的依赖性极大​ 4、测试自动化不能提高有效性​ 5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。​ 6、工具本身并无想像力3.5 按照测试项目分类界面类测试。验证软件界面是否符合客户需求。安全性测试：软件遭受到没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。文档测试。以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。3.6 其他分类α测试。软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块(子系统)测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。β测试。软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。回归测试。对修改后的程序重新进行测试，确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。随机测试。没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。4. 软件测试在项目各个阶段的作用项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制定系统测试计划。概要设计与详细设计阶段：制定单元测试计划和集成测试计划。编码阶段：编写相应的测试代码和测试脚本。测试阶段：执行测试并提交相应的测试报告。5. 常见的软件测试模型5.1 V模型优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。V模型流程图如下：5.2 W模型优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。W模型流程图如下：5.3 H模型设计原理：H模型的设计原理是将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。优点：开发的H模型揭示了软件测试除测试执行外，还有很多工作；软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。缺点：管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；测试就绪点分析困难：测试很多的时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。H模型流程图如下：5.4 X模型设计原理：X模型的设计原理是将程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。X模型流程图如下：v模型适用于中小企业，w模型适用于中大型企业(因为人员要求高) ，h模型人员要求非常高，很少有公司使用；结合W模型与H模型进行工作，软件各方面的测试内容是以W模型为准，而测试周期、测试计划和进度是以H模型为指导。X模型更多是作为最终测试、熟练性测试的模板，例如，对一个业务的测试已经有2年时间，则可以使用X模型进行模块化的、探索性的方向测试。6. 软件测试的原则(1) 测试应基于客户需求所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境并且按照客户的使用习惯进行测试并评价结果。(2) 测试要尽早进行和不断进行软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早的开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制定出完善的计划和方案，提高测试的效率。(3) 穷举测试是不可能的由于时间和资源的限制，进行完全(各种输入和输出的全部组合) 的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。(4) 遵循GoodEnough原则GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。(5) 测试缺陷要符合“二八”定理一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。(6) 避免缺陷免疫测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定势。7. 软件测试的流程不同类型的软件产品测试的方式和重点不一样，测试流程也会不一样。同样类型的软件产品，不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同，但它们所遵循的最基本的测试流程是一样的。(1) 分析测试需求测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。序号检查项检查结果说明被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。(2) 制定测试计划测试计划一般要做好以下工作安排。确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型(如功能测试、性能测试) 选定测试环境和测试方法(如人工测试、自动化测试) 。安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。(3) 设计测试用例测试用例(Test Case) 指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。(4) 执行测试测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。(5) 编写测试报告一份完整的测试报告必须要包含以下几个要点。引言：测试报告编写目的、报告中出现的专业术语解释及参考资料等。测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。总结：测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。8. 参考资料2021最网最全软件测试基础知识【建议收藏】 - 知乎 (zhihu.com)软件测试知识点汇总_孤帆扁舟去的博客-CSDN博客
前言作为一个产品经理，Axure肯定要熟练运用，但是要做高保真的原型图，在碰到要画各种图表时，脑瓜子嗡嗡响，我是自己画呢，还是截图呢，大部分人肯定选择截图，画？不可能画的，不得把我累死了，画个趋势图都够我打一把王者荣耀了。今天教你用Axure画可交互的EChart图表。原理先讲原理，原理很简单，其实网上很多都是利用Axure的内联框架，但是内联框架嵌入代码，只能生成HTML文件才能查看，且你自己嵌入的html代码在发布到Axure云无法使用，很鸡肋。其实原理就是元件在载入时（如果要单击时才出现，可以插入单击事件），触发javascript伪协议执行ECharts的js代码。听不懂？那按下面简单步骤copy就行了。很简单！！！后面还会讲如何将代码做成元件，下次自己就可以直接用了。步骤第一步 : 拉入一个矩形框，命名为 'ECharts' 。这个命名很重要，可以自定义随便取，但是要记住，后面要用。第二步： 新建载入时交互。第三步： 这一步很重要，注入灵魂。将以下代码拷贝到编辑值框。javascript: var script = document.createElement('script'); script.type = "text/javascript"; script.src ="https://cdn.jsdelivr.net/npm/echarts/dist/echarts.min.js"; document.head.appendChild(script); setTimeout(function(){ var dom =$('[data-label=ECharts]').get(0); var myChart = echarts.init(dom); var option = { legend: {}, tooltip: { trigger: 'axis', showContent: false }, dataset: { source: [ ['product', '2012', '2013', '2014', '2015', '2016', '2017'], ['Milk Tea', 56.5, 82.1, 88.7, 70.1, 53.4, 85.1], ['Matcha Latte', 51.1, 51.4, 55.1, 53.3, 73.8, 68.7], ['Cheese Cocoa', 40.1, 62.2, 69.5, 36.4, 45.2, 32.5], ['Walnut Brownie', 25.2, 37.1, 41.2, 18, 33.9, 49.1] ] }, xAxis: { type: 'category' }, yAxis: { gridIndex: 0 }, grid: { top: '55%' }, series: [ { type: 'line', smooth: true, seriesLayoutBy: 'row', emphasis: { focus: 'series' } }, { type: 'line', smooth: true, seriesLayoutBy: 'row', emphasis: { focus: 'series' } }, { type: 'line', smooth: true, seriesLayoutBy: 'row', emphasis: { focus: 'series' } }, { type: 'line', smooth: true, seriesLayoutBy: 'row', emphasis: { focus: 'series' } }, { type: 'pie', id: 'pie', radius: '30%', center: ['50%', '25%'], emphasis: { focus: 'self' }, label: { formatter: '{b}: {@2012} ({d}%)' }, encode: { itemName: 'product', value: '2012', tooltip: '2012' } } ] }; myChart.on('updateAxisPointer', function (event) { const xAxisInfo = event.axesInfo[0]; if (xAxisInfo) { const dimension = xAxisInfo.value + 1; myChart.setOption({ series: { id: 'pie', label: { formatter: '{b}: {@[' + dimension + ']} ({d}%)' }, encode: { value: dimension, tooltip: dimension } } }); } }); if (option && typeof option === "object"){ myChart.setOption(option, true); }}, 800);先去试试效果吧！ 注： 自定义矩形框名称的，将var dom =$('[data-label=ECharts]').get(0); 中ECharts改为自己矩形框的名称即可。第四步： 现在正式教你改代码了，开始认真了！javascript: var script = document.createElement('script'); script.type = "text/javascript"; script.src ="https://cdn.jsdelivr.net/npm/echarts/dist/echarts.min.js"; document.head.appendChild(script); setTimeout(function(){ var dom =$('[data-label=ECharts]').get(0);/*ECharts就是你的矩形框命名*/ var myChart = echarts.init(dom); /*从option开始改*/ var option = { }; /*这儿结束*/ if (option && typeof option === "object"){ myChart.setOption(option, true); }}, 800);将ECharts官网的示例的 js 代码拷贝到上面标注的位置就行了。这是👉[EChart官网](https://echarts.apache.org/examples/zh/index.html)链接 ![官网示例](https://tycho-1257348921.cos.ap-guangzhou.myqcloud.com/typecho/166160506638714016.jpg) 将option拷贝到代码中option的位置。也就是替换下图中的内容就行了。结束，撒花 🎉 欧，还有ECharts的代码可以自己改数据的，这样就能更加方便演示。这很简单，琢磨下就会了。制作元件库直接把这段代码的矩形框制作成元件，下次直接拉，然后复制ECharts的代码就好了。步骤：文件-新建元件库，按刚刚的步骤新建矩形，重命名，然后一顿操作就可以点保存按钮了，命名为某某的元件库。然后点＋导入刚刚的元件库就有了。小问题ECharts的示例代码其实大部分是option就行了，但是还是有其他稍微复杂的，对于前端开发工程师来说可能很简单就能改了，但是对于一个会后端的产品经理来说，雪薇有点难，我改了几个，等后面搞懂了再来讲讲吧，有大佬也可以帮我看看！参考文章关于Axure中引入Echarts图表的几种方式ECharts官网
原文链接：KANO模型：产品人必懂的需求分析法需求会因人而异，会因文化差异而不同；也会随着时间变化。作为产品设计者，我们应该持续调研需求，对产品进行迭代优化。在做项目做产品的过程中，作为互联网产品设计师的我们，经常会接到来自PM/领导/业务方等等的各种需求。有的时候，哪怕一个小功能、次次次级页面都会争得不可开交。这个时候怎么办呢？到底应该听谁的呢？哪个需求优先级高？哪种呈现方法是更靠谱的呢？今天我们就来聊聊一个非常实用的需求分级方法——KANO模型。一、什么是KANO模型？KANO模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和排序的有用工具通过分析用户对产品功能的满意程度，对产品功能进行分级，从而确定产品实现过程中的优先级。KANO模型是一个典型的定性分析模型，一般不直接用来测量用户的满意度，常用于识别用户对新功能的接受度。帮助企业了解不同层次的用户需求，找出顾客和企业的接触点，挖掘出让顾客满意至关重要的因素。KANO模型的需求分类在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：基本型需求、期望型需求、兴奋型需求、无差异需求、反向型需求。1）兴奋型需求所谓暗处，用户意想不到的，需要挖掘/洞察。若不提供此需求，用户满意度不会降低；若提供此需求，用户满意度会有很大的提升。当用户对一些产品或服务没有表达出明确的需求时，企业提供给顾客一些完全出乎意料的产品属性或服务行为，使用户产生惊喜，用户就会表现出非常满意，从而提高用户忠诚度。这类需求往往是代表顾客的潜在需求，企业的做法就是去寻找发掘这样的需求，领先对手。2）期望型需求所谓痒处。当提供此需求，用户满意度会提升；当不提供此需求，用户满意度会降低。它是处于成长期的需求，客户、竞争对手和企业自身都关注的需求，也是体现竞争能力的需求。对于这类需求，企业的做法应该是注重提高这方面的质量，力争超过竞争对手。3）基本型需求所谓痛点，对于用户而言，这些需求是必须满足的，理所当然的。当不提供此需求，用户满意度会大幅降低，但优化此需求，用户满意度不会得到显著提升。对于这类需求，是核心需求，也是产品必做功能，企业的做法应该是注重不要在这方面减分，需要企业不断地调查和了解用户需求，并通过合适的方法在产品中体现这些要求。4）无差异需求用户根本不在意的需求，对用户体验毫无影响。无论提供或不提供此需求，用户满意度都不会有改变。对于这类需求，企业的做法应该是尽量避免。5）反向型需求用户根本都没有此需求，提供后用户满意度反而下降。总而言之，我们做产品设计时，需要尽量避免无差异型需求、反向型需求，至少做好基本型需求、期望型需求，如果可以的话再努力挖掘兴奋型需求。二、如何使用KANO模型？KANO模型分析方法主要是通过标准化问卷进行调研，根据调研结果对各因素属性归类，解决需求属性的定位问题，以提高用户满意度。1. 明确目的做之前，必须明白调研的目的是什么，是否合适用KANO 模型解决，为什么要用KANO 模型解决。例如：企业为卖家开发的CRM工具，随着卖家客户的不断增长，CRM系统中需引入一些新的功能满足其管理需求。而我们作为产品开发设计者，需要知道这些功能哪些是基本功能，哪些是增值功能，功能的优先级又该如何排列等等。KANO模型就可以帮助我们很好地贴合业务需求，从具备程度和满意程度这两个维度出发，将CRM中新增的功能进行区分和排序，从而知道：哪些功能是一定要有，否则会直接影响用户体验的（基础属性、期望属性）；哪些功能是没有时不会造成负向影响，拥有时会给用户带来惊喜的（兴奋属性）；哪些功能是可有可无，具备与否对用户都不会有大影响的（无差异因素）。2. 设计问卷此问卷调查表划分维度有两个：提供时的满意程度、不提供时的满意程度。而满意程度被划分为5级（非常满意、满意、一般、不满意、很不满意），因为人的满意程度往往是渐变的，而不是突变的。满意程度的文案可根据实际问题灵活修改，如使用（非常喜欢、理应如此、无所谓、勉强接受、很不喜欢 或者 非常有用、挺实用、无所谓、不实用、很不实用 ）更加形象的描述。例如：在【通讯录】中，是否需要直接提供「拨打电话」的按钮？问卷设置正反两题：1）如果我们在【通讯录】的客户列表中，提供“拨打电话”的按钮，你的感受是：A. 非常喜欢B. 理应如此C. 无所谓D. 勉强接受E.很不喜欢2）如果我们在【通讯录】的客户列表中，没有提供“拨打电话”的按钮，你的感受是：A. 非常喜欢B. 理应如此C. 无所谓D. 勉强接受E. 很不喜欢为了更加形象且一目了然，我们可以如下设计。填问卷的人只需要在空白处打勾打叉就好了，非常方便。设计问卷的过程中，有几点要注意：问卷中的每道题都涉及到正反两面，应适当给予强调，防止用户看错（比如正反对立词字体加粗/标红等等）；在设计问卷时，尽量做到清晰易懂、语言尽量简单具体，避免语意产生歧义；选项给予说明：由于每个人对“非常喜欢、理应如此、无所谓、勉强接受、很不喜欢”等形容词的理解都不一样，所以最好有一个明确统一的说明，让用户可以有个对照，方便填写。例如：非常喜欢：让你感到满意、开心、惊喜。理应如此：你觉得是应该的、必备的功能/服务。无所谓：无所谓喜不喜欢，都可以接受。勉强接受：你不喜欢，最好是没有，有的话就勉强凑活。很不喜欢：让你感到不开心、甚至沮丧，无法接受。3. 清洗数据在收集所有问卷之后，注意清洗掉个别的明显胡乱回答的个例。如全部问题都选择“我很喜欢”或“很不喜欢”的，这种回答毫无参考价值。4. 整理分类为了能够将需求区分为基本型需求、期望型需求和兴奋需求，需按照正向和负向问题的回答对属性进行分类，具体分类对照下表。当正向问题的回答是“我喜欢”，负向问题的回答是“我不喜欢”，那么KANO评价表中，这项功能特性就为“O”，即期望型。如果将用户正负向问题的回答结合后，为“M”或“A”，则该功能被分为基本型需求或兴奋型需求。其中，R表示用户不需要这种功能，甚至对该功能有反感；I类表示无差异需求，用户对这一功能无所谓。Q表示有疑问的结果，一般不会出现这个结果（除非这个问题的问法不合理，或者是用户没有很好的理解问题，或者是用户在填写问题答案时出现错误）。简单来说就是：* A：兴奋型； * O：期望型； * M：必备型； * I：无差异型； * R：反向型； * Q：可疑结果。 注意：以上对照表只是的最常见的一种归类方式。实际操作中，可因人而异，因产品、公司、地域而异（尤其是关于“R”和“O”的定义），因为满意度本身就难以衡量。5. 量化表格1）判断KANO属性记录所有合理的数据，计算出各项占比，填写在下面的对照表里面。从上表中不难看出，“通讯录中「拨打电话」“这个功能在6个维度上均可能有得分，将相同维度的比例相加后，可得到6个属性维度的占比总和。总和最大的一个属性维度，便是该功能的属性归属。可看出“在通讯录中提供「拨打电话」功能“属于兴奋型需求。即说明没有这个功能，用户不会有强烈的负面情绪，但是有了这个功能，会让用户感受到满意和惊喜。如果你只判断这一个需求，那么进行到这一步就可以到此为止了。如果涉及到多个需求的排序分级，你还需进行下一步。2）计算 better-worse系数Better-worse系数，表示某功能可以增加满意或者消除不喜欢的影响程度。Better，可以解读为增加后的满意系数。Better的数值通常为正，代表如果产品提供某种功能或服务，用户满意度会提升。正值越大/越接近1，则表示用户满意度提升的效果会越强，满意度上升的越快。Worse，可以叫做消除后的不满意系数。Worse的数值通常为负，代表产品如果不提供某种功能或服务，用户的满意度会降低。其负值越大/越接近-1，则表示对用户不满意度的影响最大，满意度降低的影响效果越强，下降的越快。因此，根据 better-worse系数，对两者系数绝对分值较高的项目应当优先实施。其计算公式如下：* 增加后的满意系数 Better/SI=（A+O）/（A+O+M+I） * 消除后的不满意系数 Worse/DSI= -1 *（O+M）/（A+O+M+I） 3）结果产出例如：某产品希望优化5项功能，但是不知道哪些是用户需要的。通过KANO调研分析，可以分别计算出5项功能的better-worse系数。根据5项功能的better-worse系数值，将散点图划分为四个象限，以确立需求优先级。第一象限表示：better系数值高，worse系数绝对值也很高的情况。落入这一象限的因素，称之为期望型因素（一维因素）。功能2落入此象限，即表示产品提供此功能，用户满意度会提升，当不提供此功能，用户满意度就会降低。第二象限表示：better系数值高，worse系数绝对值低的情况。落入这一象限的因素，称之为兴奋型因素。功能1落入此象限，即表示不提供此功能，用户满意度不会降低，但当提供此功能，用户满意度会有很大提升。第三象限表示：better系数值低，worse系数绝对值也低的情况。落入这一象限的因素，称之为无差异因素。功能3落入此象限，即无论提供或不提供这些功能，用户满意度都不会有改变，这些功能点是用户并不在意的功能。第四象限表示：better系数值低，worse系数绝对值高的情况。落入这一象限的因素，称之为必备型因素。功能4落入此象限，即表示当产品提供此功能，用户满意度不会提升，当不提供此功能，用户满意度会大幅降低；说明落入此象限的功能是最基本的功能。在实际项目中：我们首先要全力以赴地满足用户最基本的需求，即第四象限表示的必备型因素，这些需求是用户认为我们有义务做到的事情。在满足最基本的需求之后，再尽力去满足用户的期望型需求，即第一象限表示的期望因素，这是质量的竞争性因素。提供用户喜爱的额外服务或产品功能，使其产品和服务优于竞争对手并有所不同，引导用户加强对本产品的良好印象。最后争取实现用户的兴奋型需求，即第二象限表示的兴奋型因素，提升用户的忠诚度。结论根据KANO模型计算出的better-worse系数值，说明该产品先满足功能5和4，再优化功能2，最后满足功能1。而功能3对用户来说有或者没有都无所谓，属无差异型需求，并没有必要花大力气去实现。三、总结KANO模型定义了三个层次的需求：基本型需求、期望型需求和兴奋型需求。* 基本型需求：产品“必须有”的功能，也是MVP产品要求具有的功能； * 期望型需求：非必须功能需求，但通常作为竞品之间比较的重点； * 兴奋型需求：属于惊喜型产品功能，超出用户预期，往往能带来较高的忠诚度。 根据KANO模型建立产品需求分析优先级，运用到产品设计中就是要抓住用户的核心需求，解决用户痛点（基本型需求），抓住用户痒点（期望型需求）。在确保这两者都解决的前提下，再给用户一些high点（兴奋型需求）。严格来说，KANO模型并不是一个测量用户满意度的模型，而是对用户需求的分类，通常在满意度评价工作前期作为辅助研究的典型定性分析模型。KANO模型的目的是通过对用户的不同需求进行区分处理，了解不同层次的用户需求，帮助企业找出提高产品用户满意度的切入点，或者识别出使用户满意至关重要的因素。但需求会因人而异，会因文化差异而不同；也会随着时间变化。可能前段时间的期望型需求，甚至兴奋型需求，到如今已变成了基础型需求。所以，作为产品设计者，我们应该持续调研需求，对产品进行迭代优化。参考资料：kano模型_百度百科产品需求分析神器：KANO模型分析法 — Angelina_Zhang
这篇文章主要是一个学习笔记，然后记录下来分享给大家一些通俗易懂的交互知识。一、指导原则1.1 Krug 可用性第一定律"别让我思考"这个是交互设计里面最简单而又最重要的一条法则，Krug 在《Don't make me think》中说到”如果你只能记住一条可用性原则，那么就记住这一条“。Krug 在可用性测试中最常用的也就是这一条。简单举例说明，当然也是这本书里面的一些例子。一个找工作的网站。“工作”、“被雇佣的机会”、一个招聘的专有名词，你会怎么选择？第一个我会不假思索的点击，因为很通俗易懂，而第二个我会稍微思考一下，”原来点击就可以投递简历了“，第三个，我除了思考，我可能还得去百度一下是什么东西。最好的交互就是让一切变得不言而喻，不要让人思考，让人觉得毫不费劲，我看到就能使用。1.2我们如何在互联网获取信息网页制作者和阅读者的想法似乎并不一样，网页制作者会精心排班，挑选信息，他们以为阅读者会仔细的阅读然后思考，最后选择感兴趣的内容。其实阅读者的想法似乎与他们大相径庭，在以前没有人工智能算法的时候，网页不会给你推荐正好合口味的内容，如果运气好的话，你可能会瞄一眼标题，找到了感兴趣的，点击接着阅读。当然，现在的推荐算法实在是太强了，它可能比我还了解我，例如抖音，为什么你的抖音和你爸妈的抖音完全不一样，那只能说明，你们代购确实很大，哈哈哈！开个玩笑，其实抖音这类短视频的算法做得太好了，导致了跟之前完全不一样的情况，现在你会越看越着迷，而在十几年前，你可能翻了很久都没找到自己喜欢的东西。如果想要设计有效的网页，你必须了解三个事实，Krug提到。我们不是阅读，而是扫描其实这是一个优点，我们不应该所有内容都去阅读，而是筛选出需要阅读的内容，要善于扫描。我们不做最佳选择，而是满意即可”寻找最佳策略很难，需要的时间也很长，满意策略效率更高。“可以加入埋点，让用户去做群体决策，统计用户对这个网页、按钮、方法到底满意不满意，当然，尽量缩小实验范围，不然可能损失很大！我们不是追根究底，而是勉强应付用户对于一个软件或者网页，并不需要理解背后的工作机制，往往发现能用，就不太会去找更好的方法，假如偶尔发现一种更好的方法才会去换。所以设计者应该站在用户的角度去思考这个产品的交互，是否让用户能一直使用，使用起来是否舒服，像上面所说，他不需要思考，还能应付自己的需求。1.3 广告牌设计101法则注意以下五个方面以留住用户：在每个页面建立清楚的视觉层次尽量利用习惯用法把页面划分成明确定义的区域明显标识可以点击的地方最大限度降低干扰建立清楚的视觉层次一个视觉层次清楚的页面，有三个特点：越重要的部分越突出。这点很好理解，就是突出重点。逻辑上相关的部分在视觉上也相关。这点怎么理解呢，个人觉得是通过将逻辑的相关性同时转为视觉上的相关性，除了可以让用户更好的理解逻辑外，也突出了交互上的层次。逻辑上包含的部分在视觉上进行嵌套。这点和上一点其实有一点雷同，就是为了增强关联性，这样也能让用户更好的理解逻辑。当然，这只是我个人的想法，理解有偏差的话，也欢迎大家一起交流。用户希望使用时得到编辑的引导，网站（内容）的发布者也更清楚哪些东西流行，哪些东西更有价值，这是一个双向过程，但是双方没有交流，而是通过网页的交互来互相“通气”的，就是取决你是否能吸引我的眼球。一个清楚的视觉层次的页面肯定要比杂乱无章的页面更受欢迎。利用好用户习惯为什么会讲到利用用户习惯，简单举个例子。大家肯定对于这个页面都很熟悉了吧，搜索栏在最显眼的位置，左上角是标签，下面是资讯。假如我把搜索栏放到资讯下面，用户进来找搜索框，你觉得有多少用户会下来资讯再寻找搜索框，大概率很多都不会，当然，这里不计较百度的品牌效应，且假设存在很多替代品的情况下。用户习惯了这种使用方式，如果我们要设计一个搜索网站，大部分都将搜索栏放在最显眼的位置，这就是百度、谷歌一类培养出来的用户习惯。当然，我们取消搜索框，将搜索框和地址栏结合，就想多年前的雅虎，并且就在地址栏（输入网页地址的地方），用户会选择使用我们的搜索产品吗，我想，会的，但是这样做如果没有比之前的方式好，那其实没有必要，因为培养用户习惯是需要成本的，且得思考，这样的方式是否比之前的方式要好，清楚、不言而喻、没有学习曲线的方法，能不能带来更大的价值，值不值得花费一定的成本去改变用户习惯。将页面划分为明确定义的区域划分为明确定义的区域很重要，这样能让用户更快地关注他们需要的地方，放心地跳过哪些区域，让用户扫一眼就能确定哪些区域包含有用信息。明显标识可以点击的地方我在工作中遇到过一个情况，做了一次简单的调研，在一个报表页面，点击数字或者鼠标悬停是可以查看信息的，但是大部分用户都不知道这个东西的存在，这其实是增加了用户的学习成本，看到这种地方，用户会产生思考，“这个能不能点”，这个交互其实是不好的，会让用户错失很多信息。降低视觉噪声我们每天接受来自外界的大量信息，这些信息有将近70%是通过视觉感知获得的。视噪会干扰我们对信息的判断，影响到产品的易用性和可用性，与用户体验的好坏息息相关。下面是克劳德香农图，清晰的展示了视觉噪声的危害。1.4 为什么用户喜欢无需思考的选择在一些网站的设计中，被要求用户到达某一个地方的点击次数不能超过指定次数。其实用户不介意点击次数的多少，只是每次点击都是毫不费力的，并且能让用户坚信自己的选择是正确的。Krug 总结出来一个经验准则，“三次无需思考，明确无误的点击相当于一次需要思考的点击。”如果我们需要一直在网络上进行选择，那么让这些选择变得无需思考是让一个网站容易使用的主要因素。1.5 省略不必要的文字你仔细观察就会发现，大多数页面上的大部分文字都不过是在占地方，因为没有人打算阅读它们。这其实造成了一个问题，就是，你的网页的文字让用户阅读的难度变高了。去掉这些冗余的文字其实有几点好处：可以降低页面的视觉噪声让有用的内容更突出让页面更简短，让用户在每个页面上一眼就能看到更多的内容，而不必滚动屏幕二、必须准确处理的几个方面2.1 怎么创建“明确”、“简单”、“一致”的导航网络导航101法则你通常会为了寻找某个目标你会决定先询问还是先浏览如果选择浏览，你将通过标志的引导在层次结构中穿行最后，如果找不到想要的东西，你会离开web与现实世界的区别感受不到大小感受不到方向感受不到位置导航的用途* 给了我们一些固定的感觉 * 告诉我们当前位置 * 告诉我们如何使用网站 * 给了我们对网站建设者的信心 容错成本低有返回主页的按钮，无论迷失到哪儿，都能重新开始。提供搜索搜索的设计要注意三点：慎用花哨的用词：“快速搜索”“关键词搜索”“精确搜索”等等添加指示说明：在PlaceHolder中增加对搜索的描述添加选项：如果存在易混淆的搜索范围，如全站搜索？部分站点搜索？整个Web搜索？请加选项区分。关于页面名称标识要大：足够引人注目在合适的位置：通常在页面左上，目光焦点较多的地方每个页面都需要一个名称名称要和点击的链接一致面包屑面包屑，也就是层级菜单，可以告诉你当前位置。喜欢标签（TAB）的四个理由它们不言而喻：从来没有第一眼看到会不明白的用户它们很难错过：当Krug进行“用户点击测试”时，几乎所有人都会试着点击Tab标签它们很灵活：设计得当能增加修饰作用，更实用它们暗示了一个物理空间：能帮助你装载大量内容“后备厢测试”想象你被蒙上双眼，所在车子后备厢中，车子开动一段时间后，把你放在网站某个内容的某个页面上，你能迅速的判断出：这是个什么网站？（风格主题设计）自己现在在哪？（网页名称）如何回到主页？当前我有什么选择？（本页导航）网站主要栏目有哪些？（栏目清单）我怎么进行搜索？2.2 首先要承认，主页不由你控制主页的任务站点的标识和使命：告诉我这是做什么的网站站点层次总览：网站概貌搜索建立可信度和信任感：专业优美的设计，是良好印象和继续使用的重要因素内容更新：展现活跃迹象，不是死水一潭友情链接：没办法快捷入口注册看到我自己正在寻找的东西：让我有继续使用的第一动力……还有我没寻找的东西：以后用得到告诉我从哪开始：面对一个新网站，无从下手的感觉糟透了导读：精彩内容的推介你还要面临的一些不利因素每个人都想占有一席之地：主页的版面很珍贵，但信息量太多会容易造成堵塞——供应不足想要参与的人太多：产品，设计，市场，CEO，（甚至技术）都想在主页加上一些个人需要（或喜欢）的东西一个尺寸要适合所有人：主页要呈现在每个访问者面前，不管他们兴趣差别有多大如然发现这有的笔记写得太好了，列举在下：关于Web设计的原则与体会（一）关于Web设计中导航与主页的设计原则（二）关于Web设计中的可用性决策（三）
第五章 文档管理 产品文档包括商业需求文档（BRD）、市场需求文档（MRD）和产品需求文档（PRD）。5.1 商业需求与BRD 通俗的说，描述产品及项目的商业需求，就是回答“项目有没有必要开展”“需要多少投入”和“多久能够盈利”的问题。5.1.1 商业需求解析 分别从战略、资本和模式三个方面阐述产品的商业需求，在考虑清楚这三个结构化的问题后，要把思考的东西落笔成文，输出一个结构化文档，这就是商业需求文档。5.1.2 BRD的撰写 一份完整的BRD至少需要包括一下四个方面的内容：项目背景：阐述为什么做（why）项目时机：为什么是现在做（when）项目规划：阐释怎么去做（how）项目收益、成本、风险与决策5.2 市场需求与MRD 市场需求是面向市场着重考虑产品定位和用户定位的问题，即市场是否真的存在需求空间，以及是否存在有此需求的用户群体。5.2.1 市场需求分析 无论是那一种用户定位，其实产品本身一定要清晰一点--在产品研发前，去设想哪些人是自己的主流用户，在产品上线推广之后，通过调查反馈来验证产品是否抵达了自己的主流用户。不管是面向大众还是面向小众，只有牢牢把握住主流用户，满足了主流用户的需求，才能真正支持起产品的生命力。5.2.2 MRD的撰写 一份MRD至少要包括一下方面内容：用户描述和市场描述。用户描述 用户描述主要是进行目标用户群体的确认，包括目标用户群的地域、职业、学历、婚恋状况等基本信息，还包括消费尺度、兴趣爱好、出行习惯、作息时间等特征信息。市场描述 市场描述主要是指市场规模预测，进行竞争对手产品分析（竞品分析）和SWOT分析。5.3 产品需求和PRD 一份PRD文档可以包括以下几个方面（根据具体情况而定）：功能需求列表预计版本规则与概念定义UI设计与展示原型展示第六章 用户体验6.1 用户体验概述 用户体验（User Experience，UE/UX）就是用户使用产品的所有童颜和感知的总和，这种感受包括心理层面和生理层面的，比如视觉感受、点触与反馈感受、认知感受、价值感受（是否满足了用户需求）、情绪感受、超预期感受（意外惊喜、收获）等。 奎瑟贝利5E原则，认为用户体验包括五个方面：有效性：产品能不能起到作用，可用性或有用性效率：产品应该能提高使用者的工作效率易学习：学习成本低容错：防止用户放错，以及修复错误的能力吸引力：从交互和视觉上让用户舒适并乐意使用 史蒂文·克鲁格提到的用户体验包括一下六个方面：有用性：能否帮助人们完成一些必须的事务可学习：人们能否明白如何使用可记忆：人们每次使用的时候，是否都需要重新学习有效：它们能否完成任务高效：它们是否只需花费适当的时间和努力就能完成任务合乎期望：是人们想要的吗 此外，ISO 9241-210 标准将用户体验定义为“人们对于针对使用或期望使用的产品、系统或服务的认知印象和回应”。 事实上，用户体验并不神秘，它本身的构成正是基于对“是否有效”“是否好用”“是否有吸引力”“是否易学习”等一般问题的回答。 我们把用户体验拆分为功能层、表现层和框架层。功能层由技术来决定，表现层由设计来决定，框架层由交互来决定。 用户体验设计就是“一切围绕用户体验而展开，一切又落脚于用户美好体验，真正践行以用户为中心，想用户之所想，想用户之未想”的设计。 用户体验设计首先聚焦在核心功能的实现，对于任何产品来说，功能是摆在第一位的，功能对应的是用户的需求或欲望。产品先有功能，再谈其他。6.2 从场景适配入手 所谓场景适配，就是在合适的时间和地点，为合适的用户提供合适的服务。6.3 于细节处深打磨 “最好的产品通常会做好两件事：功能和细节。功能可以吸引用户关注这个产品，而细节则能够让关注的用户留下来”。6.3.1 影响用户体验的细节打不开产品等待加载各种通知的干扰产品评分邀请频繁的升级提醒6.3.2 APP 产品的细节设计注意留白适时出现切准痛点符合本能6.3.3 APP 产品的细节设计要求 对于产品设计需践行12个字：功能可见、即时反馈、结果可期。产品的干扰功能不是细节产品的负面设计不是细节6.4 用户体验要素视觉要素反馈要素情感要素第七章 产品设计7.1 概念设计 现在的UI设计主要包括一下内容图标设计控件与其状态设计页面设计 除了界面设计、交互设计的说法之外，还出现了 GUI（Graphical User Interface，图形用户界面）、HUI（Handset User Interface，手持设备用户界面）、WUI（Web User Interface，网页用户界面）的概念。 区分了这些新的概念与表达，可总结出现在主要又一下三种设计方式：UID（User Interface Design，用户界面设计）UED（User Experience Design，用户体验设计）UCD（User Centered Design，以用户为中心的设计）7.2 设计风格7.2.1 扁平化设计 扁平化设计是一种极简主义的美术设计风格，通过简单的图形、字体和颜色的组合，来表达直观、简洁的设计目的。扁平化设计操作要领：简单的设计元素贴切的图标关注色彩产品设计颜色的比列分配产品使用多少种颜色为宜强调字体的使用7.2.2 拟物化设计 简单地说，拟物化设计就是对实际物体的模仿重现，从而帮助用户获得自然的心理感受。拟物化设计的优势：更好的感知性更好的交互性拟物化设计操作要领：阴影的运用材料的选择良好的品味7.2.3 卡片式设计 卡片式设计就是把包含图片或文本信息的方块矩阵作为交互信息入口，UI 呈现形式类似于卡片的设计形态。 卡片式设计的本质在于：卡片充当整齐的信息容器卡片式设计操作要领：精选高质量和高相关的图片慷慨地留白掌握叠加文本的技巧排版技巧的运用润色一切围绕拇指操作方便而设计卡片的设计要整齐划一7.3 Logo 与界面 图标属于产品“视觉识别系统”里的一部分，强调系统性和整体一致性。好的Logo应具备怎样的特征？设计要直观要有独特的设计元素尽可能简介的美观 常见的APP Logo 设计模式有一下几种：使用产品的名称使用卡通形象基于产品属性7.4 产品交互 交互设计是一种目标导向设计，所有的工作内容都是围绕用户行为去设计的。交互设计的原则：简洁高效一致性反馈移动化交互设计的一些实操技巧：注重使用情境激发用户探索第九章 产品经理9.1 产品经理的核心职能 实际上，产品经理传统的职责比较偏市场营销，而在今天移动时代商业生态下，产品经理在关注市场的同时，更重要的工作是做产品定义。 产品定义具体来说可分为三个层面：用户需求定义、产品功能定义、产品原型定义。9.1.1 用户需求定义用户需求定义可分为目标用户、用户需求、使用场景和消费水平等。定义什么类型的人会用自己的产品--定义哪些人群是核心用户，哪些是可辐射用户，哪些是潜力用户。定义用户的需求--包括需求冬季和需求的具体内容，即用户到底因何产生怎样的需求。定义用户使用产品的场景--比起用户有没有需求，用户在哪里产生产生整个需求可能更为重要一些。9.1.2 产品功能的定义 产品功能的定义既来自现实的市场观察，又要超越当下、预见未来。“人无我有，人有我新，人新我转”就是产品经理之间竞争路径的真实写照。9.1.3 产品原型定义 对于互联网产品经理来说，高保真产品原型应当作为描述产品和定义产品的基本方式。9.2 产品经理的能力要求业务能力沟通能力数据分析能力技术能力