content.json

{"meta":{"title":"Tao's blog","subtitle":"My journey","description":null,"author":"tao98","url":"http://yoursite.com"},"pages":[{"title":"关于我","date":"2019-04-01T15:01:23.000Z","updated":"2019-04-20T16:21:36.096Z","comments":true,"path":"about/index.html","permalink":"http://yoursite.com/about/index.html","excerpt":"","text":"作品集pdf下载 http://t.cn/EawUerB 我是陶啸峰，这里占坑先。感谢Github, Hexo, Clover Tuan的支持。"},{"title":"关于我","date":"2018-12-17T15:01:23.000Z","updated":"2018-12-17T15:22:18.638Z","comments":true,"path":"tags/index.html","permalink":"http://yoursite.com/tags/index.html","excerpt":"","text":"我是陶啸峰，这里占坑先。感谢Github, Hexo, Clover Tuan的支持。"}],"posts":[{"title":"4月23日海军节整理及预测 （我永远喜爱055😘😘😘）","slug":"4-23海军阅兵整理","date":"2019-04-11T14:49:37.000Z","updated":"2019-04-20T16:21:28.937Z","comments":true,"path":"2019/04/11/4-23海军阅兵整理/","link":"","permalink":"http://yoursite.com/2019/04/11/4-23海军阅兵整理/","excerpt":"","text":"我永远喜爱055 😘😘😘😘 002肯定来不了了 官方新闻 邱延鹏介绍，组织各国海军舰艇海上阅兵，是海军这一国际性军种特有的海上礼仪活动，是世界海军交往交流的一种独特形式。4月23日在青岛及其附近海空域举行的海上阅兵，将采取舰艇单纵队航行、飞行梯队跟进的方式执行海上分列式。 中方参阅舰艇和飞机包括航母辽宁舰、新型核潜艇、新型驱逐舰、战机等在内，有些舰艇是第一次亮相。 其中，受阅舰艇32艘，编为潜艇群、驱逐舰群、护卫舰群、登陆舰群、辅助舰群、航空母舰群6个群。 受阅战机39架，编为预警机梯队、侦察机梯队、反潜巡逻机梯队、轰炸机梯队、歼击机梯队、舰载战斗机梯队、舰载直升机梯队等10个梯队。 除中方参阅兵力外，俄罗斯、泰国、越南、印度等10多个国家近20艘舰艇将参加检阅活动，包括驱逐舰、护卫舰、登陆舰等不同类型舰艇，他们都是各国海上力量的代表，将与中方舰艇一道，向世界展示维护和平、共谋发展的坚定决心。 什么意思呢就是说 002没了 双航母得等下次了。潜艇不知道095 096来不来。驱护舰都看过了。第一次亮相的就是055啦。可能还有新的龟背出来秀。 两张图 来自超大 他国来访军舰在我055大盾面前 这些都是臭弟弟新加坡 坚强号护卫舰， 排水量 3200吨 新加坡绿20号就到了 马来西亚莱丘号护卫舰，排水量 2400吨 印度 加尔各答驱逐舰 排水量 7500吨 会不会翻船呢 日本 凉月 驱逐舰 排水量 6800吨 秋月级 小盾 韩国 京畿 护卫舰 排水量 3250吨 FFX 仁川级 KDX没来可惜了 越南 丁先皇号和 陈兴道号 护卫舰 排水量 2100吨 2艘 猎豹级 当家4艘来了两 给面子嗷 俄罗斯戈尔什科夫护卫舰 排水量 4500吨 毛子家最新锐的。。。护卫舰还会来2艘1155反潜舰 7000吨的大型反潜驱逐舰 还行吧 就是太老了 菲律宾 丹辘 登陆舰 排水量 9000吨 民标船 泰国 纳莱颂恩 护卫舰 F25T 排水量 3000吨 天朝船体+多国系统 邦巴功 护卫舰 053HT 2000吨 天朝053H2出口型纳来颂恩（左） 邦巴功（右） 孟加拉 BNS PROTTOY C13B型轻型护卫舰 056的出口型 巴基斯坦 可能来 赛义夫 F22P 也是天朝血统 缅甸“辛标信”号 护卫舰 F14 装了C802 和直9 文莱 达鲁塔夸 巡逻艇 排水量 1625吨 umm 甲板打篮球 法国 葡月号 护卫舰 排水量 3000吨 这级舰除了100炮其他约等于没有 就是个装逼的船","categories":[],"tags":[]},{"title":"渲染和动效","slug":"渲染和动效","date":"2019-04-02T14:49:37.000Z","updated":"2019-04-20T16:30:01.196Z","comments":true,"path":"2019/04/02/渲染和动效/","link":"","permalink":"http://yoursite.com/2019/04/02/渲染和动效/","excerpt":"","text":"","categories":[],"tags":[]},{"title":"车载交互系统发展史","slug":"汽车中控发展史","date":"2019-04-01T14:49:37.000Z","updated":"2019-04-20T14:24:02.314Z","comments":true,"path":"2019/04/01/汽车中控发展史/","link":"","permalink":"http://yoursite.com/2019/04/01/汽车中控发展史/","excerpt":"","text":"背景定义我们这里做狭义的车载交互系统探讨，仅仅指“仪表”“中控（车机）”等及相关系统或组件。其他交互不作探讨。 当前，移动设备在消费级市场得到了前所未有的发展——从可穿戴设到手机再到平板可穿戴设备。移动设备越来越实惠，实现了前所未有的大面积普及。 慢慢地，移动设备开始占领人们的生活，在车内也找到了自己的位置，一时之间手机支架成为普通车型的主要“核心部件”。移动设备开始倒逼汽车交互系统发展，随着新技术的加入，使得人车交互日益复杂，汽车制造业开始反思人车交互体验。 汽车交互系统是司机了解车辆信息的重要桥梁，基于驾驶安全、用户体验和技术发展趋势及电动车的高速发展，这个时代将是行业对现行人车交互设计的重大变革机会。 如何变革？首先回顾下汽车汽车交互系统的发展史。 时间跨度1886年1月29日(距今130年)，两位德国人朱卡尔·木茨和戈特利布·戴姆乐获得世界上第一辆汽车的专利权，标志着世界上第一辆汽车诞生。这辆汽车本质上可以说是一台移动的内燃机，不存在仪表及中控系统。那么我们从哪里开始呢。其实我也不知道哪一款车是世界上第一个安装了仪表的，我也没查到也不能信口开河对吧。那不如从第一款平民化汽车——福特T型车（Ford Model T）为起点，直到2019年4月。 机械式电气化时代 -1998数字时代 移动设备带动人车交互发展最先一批使用数字仪表盘的是1998年出厂的克莱斯勒水星——大侯爵，其应用了真空荧光显示器，彩色屏幕便流行了起来。之后，汽车厂商们纷纷将大尺寸显示屏应用到汽车交互中。同年，诺基亚5110上市，这款产品的历史地位暂且不谈，但是它却成为首款可以玩贪吃蛇的手机。之前的数年，正是模拟移动电话网（1G）逐渐被第二代通信技术（2G）取代，手机取代大哥大的时候，与今天4G和智能手机快速发展带动汽车交互系统升级的状况简直一模一样。 1998-2005 按键为主 屏幕为辅奔驰 W220 蝴蝶奔。彩色大屏+众多按键，从功能上来说，大大丰富了汽车中控的功能性，可以看电视，那时候虽然没有倒车影像，但雷达精准度非常棒，还有奔驰独特前后单独雷达测距显示器。奔驰将彩屏成功地“打入”了中控台原本为音响系统留的位置上，并加入了多个媒体按键以操控。但是整个中控布局却杂乱不堪，从易用性上相比电气式并没有本质提高。它的人机交互体验可谓“烂出水平”了：需要插SIM卡以打电话，蓝牙什么的更是不存在的，整辆车可以理解成一个能飞奔的功能机；还要从九宫格按键中打字以设定导航，把字打出来的功夫都到了；同时导航的精度、详细地理信息的更新时效都十分蛋疼。 雷克萨斯LS430 采用了触摸屏，当时可谓是十分惊艳。 这一代的车型，装逼有余，在日常使用的方便程度上，存在着较大不足，但他们作为汽车座舱“玻璃化”的先驱者，也可谓达到了最初的目标。 2006-2011 优秀的触控体验来了来了，他来了。2006年——第一代IPhone发布的年份，之后不仅是消费级电子市场汽车中控大屏纷纷转向电容屏。 2012 特斯拉引领风潮优秀代表未来交互 HUD","categories":[],"tags":[]},{"title":"1-6 用户体验地图","slug":"1-6 用户体验地图","date":"2018-12-08T14:49:37.000Z","updated":"2018-12-30T15:31:47.908Z","comments":true,"path":"2018/12/08/1-6 用户体验地图/","link":"","permalink":"http://yoursite.com/2018/12/08/1-6 用户体验地图/","excerpt":"","text":"什么是 Experience Map用户体验地图是一个可视化地描述用户使用产品或接受服务的体验情况，以此发现用户在整个使用过程中的问题点和满意点，并从中提炼出产品或服务中的改进点和机会点。从用户角度了解产品、服务的重要的设计工具，用可视化的方法表现出用户在使用一个产品或服务的流程，包含用户的需求，期望，媒介，情绪变化）。 使用用户体验地图可以让团队成员在用户在整个体验过程中如何被对待的问题上达成共识，在跨部门与其他团队进行讨论时用户体验地图也是十分好用的工具。通过用户体验地图去描述用户在日常生活与产品的互动，让所有利益相关者去了解用户日常生活中的所见、所想、所闻、所做，从而让他们够从用户角度去考虑产品、设计产品。 最典型的用户体验地图例子，是Chris Risdon绘制的欧洲铁路购票的体验地图。 内容和元素 区域A：用户模型通过分配（1）角色（“谁”）和（2）要验证的场景（“什么”），为地图提供描述范围。区域B：地图的核心是可视化的体验过程，通常把体验过程的块状段落对齐排列（3）。用户在整个体验过程中的行为（4）、想法（5）和情感体验（6）可以通过调研中的引用或者视频辅以展现。区域C：分析应根据地图支持的业务目标而有所不同，它可以去描述研究过程中的发现和用户痛点，还有某个可聚焦方向的发展契机（7），以及所有权（8） 优势 体验地图第一大优势：好看。它以视觉化的方式，将用户与产品或服务进行互动时的体验分阶段呈现出来，让体验地图中的每一个节点都能更直观地识别，评估和改善。不论是电子版还是满墙的便利贴，在效果上已经充满了形式美。 体验地图的第二大优势：非常贴合时下流行的「情感化设计」。体验地图能协助团队精准锁定产品引发强烈情绪反应的时刻，同时找到最适合重新设计与改进的地图节点，这一切都几乎用户使用中的情感需求。 体验地图的第三大优势：能够多人参与，并且让所有人都横向梳理一遍产品流程。很夸张的是，大多数产品团队中，往往只有交互设计师认真从头到尾思考过产品流程；同时大多数产品，直到完成后才发现流程上的 bug，但此时只能假装没看见。 体验地图并不是一个独立的设计方法，它是产品前期用户研究过程中重要的一部分。在我做过的案例中，体验地图往往是最终收尾、拿结论的最关键节点——但是不能脱离了前期其它设计方法的材料准备。 准备工作1.定性分析、用户访谈 方法是直接于用户交流，可以采取面对面、电话沟通的方式；尽可能获取到最直接、最准确的资料。用户访谈过程需要注意用户的选择、问题的拟定、言语的沟通（不要有引导性话语）、时间的控制等,这里不做展开。这类一般由专业用研人员进行，但有些公司并没有用研部门，则需要设计师去承担这部分工作。 2.用户画像 Persona 用户调研后，在获取一手资料和用户研究报告后，需要确定产品／服务的用户画像。它是整个产品和服务的服务对象。 境外购物人群用户画像 Persona 上图是携程团队通过直接参与用户访谈过程并结合最终的《境外购物人群研究报告》，得出的境外购物人群用户画像 Persona。最终将主要目标人群可以分为三类：攻略帮、跨境通、随性购；画像中分别显示了三类人群的基本特征，包含：背景、购物习惯、喜爱的购物品牌、获取信息的渠道、常去的购物点等等。 3.确定体验方向、体验主题 它是整个体验地图的主题，很多产品的方向可能不止一个，用户的使用场景也完全不一致。所以确定主题是整个产品的奠基石。 就当前的业务线而言，就有很多方向；有的业务在使用场景上完全不一致；所以携程团队们选取了最主要的业务-境外购物体验地图。 正式绘制绘制的时候建议和相关的产品、用研同事一起站在用户的角度进行头脑风暴，可以使用便利贴方法，将每个参与人的想法记录下来，然后在进行归纳和分类。 图片来源：pinterest 1.确定用户需求，拆解用户行为 通过分析用户需求、拆解用户行为我们从行前、行中、行后确定了6个行为阶段，分别是：查询&询问、做攻略、寻找购物点、购物、购物&查找商品、结算、离境；在每个关键阶段中找出主要行为，可以用可视化的表现手法表达出来。 2.补充纵坐标中各类节点的内容 补充的所有内容均是以已经拆解的用户的行为阶段为基准，切不可随意填充无关行为阶段的内容。这里我们主要针对阶段，补充了用户在各阶段的思考、情绪变化以及痛点。 3.机会 在获取用户痛点后，思考可行的机会点，详情见下图。 https://pic4.zhimg.com/80/v2-b2f5375704fc36c457ff44ce98dabb83_hd.png 总结绘制用户体验地图时，需要注意： 注重前期对产品的思考，包含发展策略、目标定位等；不要根据自己的经验或认知来确定用户行为过程中的阶段；不要过早将聚到信息加入到Map中， 用户达成某个目标而使用的媒介；团队合作、头脑风暴； 法则1）明确用户体验地图将要支持什么样的业务目标； （2）要基于事实； （3）谁将会使用它； （4）它是关于谁的以及将要呈现怎样的体验； （5）怎样把它共享出去； （6）您的用户体验地图应该是“Focused”、“Socialized”、“Truthful”. 最后是一张完整的用户体验地图 另一个版本材料准备？用户角色、观察记录，或者还可以再加上行为研究、调查问卷、竞品分析。 用户角色 —— 最有效的体验地图通常会配合用户角色以及情境故事一起制作。每个体验地图都应该呈现某个特定产品目标使用者的真实特性，并且该使用者有明确的任务和目标。以后或许会写如何有效地做用户角色。 观察记录、行为研究、调查问卷、竞品分析 —— 都是为了同一个目的，获取大量真实、可靠的原材料。体验地图上每个节点的对应内容，并不是拍脑袋想，而是应该经过长期的用户研究获取资料。所以，也可以说「体验地图是用户使用问题的有效梳理方式」。 进入实例说明。 因为产品类型不同、研究目的不同，每次使用体验地图方法的步骤都是会有略微修改的。举三个栗子： 1、一个连原型还没有的产品，他们希望从纯情感的角度来了解自己的产品应该为用户做什么，因而协助团队开始产品功能设计。他们的体验地图可能是这样的： ![]https://pic2.zhimg.com/80/403a2f6939f9ab61ebdeae04976a036d_hd.jpg)每个节点位置的高低，是纯感性的 2、一个线下实体产品，他们希望改善自己的服务体验。他们的体验地图可能是这样的，其中紫色卡片部分是服务流程中搜集到的问题： 每个节点位置的高低，是由事实说明的，是理性的 3、一个广泛用户群的产品，不同身份的用户角色会对应不同的体验流程。此时需要根据不同的用户角色，制作多个不同的体验流程图，最后重合的部分，就是此次设计中需要具体改善的地方。 好了，那么到底该如何做用户体验地图？以一个互联网产品举例，细致分解步骤。 背景：该公司希望帮忙研究「用户拍照行为」，从而作为他们即将开始设计的手机 ROM 拍照功能指导。 第一步，整理原始材料。根据之前的线下、线上调研，观察用户，用户访谈等等，我们获取了大量用户自拍行为中的问题和惊喜点，将它们以小便利贴的形式整理出来。并区分「问题」和「惊喜」的颜色。 第二步，找一个宽阔干净的新板子，写出用户行为流程。注意：每个行为节点 (touch point) 都是中性动词，要尽量细化，用词精准干净。 第三步，画出情感坐标，并把行为流程置于中性线上。 第四步，把搜集到的「问题」和「惊喜」放到对应的每个行为节点上。惊喜点放在上面，问题点放在下面。 第五步，根据「问题」和「惊喜」的数量情况，和重要性程度，理性地判断每个行为节点的情感高低，并连线。注意：判断重要性是个略微感性的事，此时要基于用户角色，问自己这个用户角色对这个问题的在意程度有多少？ 再注意：当一个行为节点可能产生两个结果，比如高兴或不高兴，优先考虑不高兴的情况，因为我们不是要做一件歌功颂德的事。 以上，一个体验地图就完成了，要如何获得结论呢？ 1、看看最高点，为它多做一点事情，将它推到极致。 2、看看最低点，思考能不能把其它体验值高的步骤，分摊一部分功能到这里，均衡体验情感。 比如下图是「用户自拍行为」体验地图，明显看出整个前期拍照行为都是走低的，而后期修图持续走高。此时就可以郑重考虑把更多的后期功能放到前期。 3、看看体验值中线以下的点，对应竞品分析，看看别人是怎么解决那些问题，并设置惊喜点的。 以上，你就可以有效地完成一个用户体验地图。","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"1-5 PM的生命与产品流程","slug":"1-5 PM的生命流程与产品流程","date":"2018-12-06T14:49:37.000Z","updated":"2018-12-30T14:27:57.745Z","comments":true,"path":"2018/12/06/1-5 PM的生命流程与产品流程/","link":"","permalink":"http://yoursite.com/2018/12/06/1-5 PM的生命流程与产品流程/","excerpt":"","text":"一、产品、项目研发基本流程总体五个阶段： 需求采集、分析评估；产品内部评审；产品设计研发；产品研发；产品验收。 二、产品经理基本规范第一阶段： 需求评估整理需求输入：项目合同（立项书等文档）、项目需求文档、相关资料和第三方（联系人、联系方式、数据接口等）产品输出：业务流程图(TFD)/简要技术建议文档节点枢纽：产品/项目负责人审核 第二阶段： 产品内部评审产品输出：业务流程图（TFD）、功能结构图、市场需求文档（MRD）/商业需求文档（BRD）内部输出：产品审核意见（讨论会、书面文档或邮件形式）节点枢纽：产品内部评审通过后进入设计阶段，没有通过回到第一阶段进行需求再确认。 第三阶段： 产品设计产品输出：产品原型/产品需求文档（PRD）研发输出：原型问题建议文档节点枢纽：通过后进入研发阶段，没有通过回到设计阶段进行再完善。 第四阶段： 产品研发UI输出：UI效果图研发输出：研发阶段问题节点枢纽：效果图评估通过后，UI图交付研发，研发阶段问题解决后进入产品交付阶段。 第五阶段： 产品验收研发输出：完整产品系统、测试文档和操作手册以及其他相关资料产品输出：产品验收通过说明通知（文档、邮件）、PRD归档项目经理输出：项目接收确认节点枢纽：通过后产品和研发都将相关资料归档，项目经理将产品交付甲方。如果是内部项目则交付运营，产品进入运营阶段。 三、产品经理基本文档流程图：业务流程图、页面流程图思维导图：信息结构图、功能结构图需求文档：市场需求文档（MRD）、商业需求文档（BRD）、产品需求文档（PRD）需求原型：产品原型其他文档：临时文档 四、 名称解释（1）业务流程图： 就是用一些规定的符号及连线来表示某个具体业务处理过程。业务流程图是一种描述系统内各单位、人员之间业务关系、作业顺序和管理信息流向的图表，它是物理模型。主要是描述业务走向，描述的是完整的业务流程，以业务处理过程为中心，一般没有数据的概念。 特点：利用它可以帮助分析人员找出业务流程中的不合理流向。 （2）页面流程图： 具体到产品功能设计前，不同页面之间流转关系的图表，用户通过某项操作进入相应页面以及后续操作和页面。 特点： 主要表现页面功能的逻辑性，规划行为路径。而不是单页面交互设计，无需考虑页面内容、布局。更加聚焦于用户目标和任务的完成。 （3）信息结构图： 主要梳理出产品所涉及到的信息层次和结构。即一款产品包含哪些方面的数据和内容，同时又如何归类。 特点：可以快速判断出产品的主要功能和特点。 （4）功能结构图： 所谓功能结构图就是将系统的功能进行分解，按功能从属关系表示的图表。功能模块可以根据具体情况分的大一点或小一点，分解得最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。 特点： 功能结构图主要是为了更加明确的体现内部组织关系，更加清晰的理清内部逻辑关系，做到一目了然规范各自功能部分，使之条理化。 （5）商业需求文档（BRD）： 基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。BRD是产品生命周期中最早的文档，再早就应该是脑中的构思了，其内容涉及市场分析，销售策略，盈利预测等，通常是供决策层们讨论的演示文档，一般比较短小精炼，没有产品细节。 特点：BRD的作用，就是决定了你的项目的商业价值。 （5）市场需求文档(MRD)： 产品项目由“准备”阶段进入到“实施”阶段的第一文档，其作用就是“对年度产品中规划的某个产品进行市场层面的说明”，这个文档的质量好坏直接影响到产品项目的开展，并直接影响到公司产品战略意图的实现。 特点：侧重的是对产品所在市场、客户（client）、购买者（buyer）、用户（user）以及市场需求进行定义，并通过原型的形式加以形象化。 （6）产品需求文档(PRD)： 对MRD中的内容进行指标化和技术化 特点： PRD的好坏，直接决定了项目的质量水平 （7）产品原型： 线条、图形描绘出的产品框架，也称线框图 特点：目标在于清楚的表达产品的设计理念和功能的执行逻辑 产品流程拆解：如何提升产品的竞争力项目从0到1的一个例子，怎么去评估一个项目是否值得持续投入资源？ 项目创新 -> 取得关键性进展 -> 给到更多流量 – > 持续迭代 而一个失败项目走的循环一般是： 项目创新 -> 无法取得关键性进展 -> 资源收缩 -> 项目停止 因此，启动一个项目时，第一步最关键的要素可能并不是直接做产品设计，甚至不是需求分析，而是定义关键指标，所有的目的都是为了达成这个关键性指标，这个关键性指标就像是撬动项目进行到下一步的杠杆点一样，抓住了这个点，才能推动项目。 在做产品的过程中，会遇到各种这样的关键性环节，需要在不同的阶段把握这个系统中有触发能力的各个要素，利用这些要素进行产品的设计和迭代。 在这里，我把产品的设计过程拆解为需求分析、用户研究、产品定位、原型设计、版本迭代、数据分析、产品增长 7个关键步骤，这些要素相互关联，互相作用，最后推动产品的雪球越滚越大，持续地正向增长。 一、需求分析产品经理是需求的过滤器。因此日常工作中最重要的工作是分析各个层面的用户需求，如来自真实用户、来自老板、来自运营的需求，找出他们的本质需要，并提供解决方案，即产品需求。在需求分析的过程中，有以下原则需要去把握。 分清产品需求和用户需求，用户本质需求高于解决方案（产品需求）高于用户表面需求 用户说自己想吃饭，本质需求是饿了，可能给他一碗老北京炸酱面他能吃得更香。在这里，用户想吃饭是他的表面需求，他的本质需求是饿了，而老北京炸酱面则是解决方案。 同理，用户想要一匹更快的马时，本质需求是希望能移动得更快，这时候，提供一辆T型车是更好的解决方案。因此，需要从各种声音里分辨出最真实的需求，才能提供出一个超出用户期待的解决方案，这就是产品需求。 同时，用户需求是在不断进化的，因为人们对于已经得到的产品和服务的适应性，从而总会再追求更美好的体验。这对于旧产品是危机，对于新产品则是机会。因此需要过一段时间就能把自己的解决方案进行更高一层次的抽象，这样得到更本质的用户需求。基于这个更本质的用户需求，去思考你的产品需求。 抓住那些最痛的痛点先做起来 而真正的工作中，我们会碰到各种需求，前端的功能后台的功能，老板的要求用户的抱怨。这个时候，感知到需求的不同疼痛程度，从而排列优先级是产品经理核心需要做的事。这时候产品经理要敢于拒绝也要敢于承担，需要首先去识别那些用户最痛的点，这涉及到第二节的用户研究，同时，把他们的优先级提高，首先去完成；同时穿插好体验的优化。 从产品的生命周期看需求 互联网产品的基本规律是先通过解决最基础的刚性需求黏住用户，取得渠道价值，再通过营销商品（广告、电商、金融、知识等）获得变现。因此，产品不仅承载着用户的使用需求，同时承载着开发者的商业需求，因此，在不同阶段会用不同的需求重点。 在产品初创阶段，需要验证用户需求，做出可以满足用户刚需的产品。 在产品的增长阶段，更多是通过用户推荐，铺渠道获得更多用户，同时，产品需要在涌入这么多用户的时候保证系统的稳定性，并解决各种问题，推出新的功能。 下面，就是做产品的商业变现，这时候，无论是卖自己的产品还是卖别人的产品或者广告，怎么更好地进行流量的变现，都是产品在这个阶段最重要的需求。 同时，在产品的成熟期，可能会面临流量的瓶颈，一方面是最基础的需求可以覆盖的用户本来就有限，一方面是市场供需达到平衡，这时候对老用户的精细化运营就非常重要，需要去做产品的用户黏性了，因为老户维护的成本低于新户拉新的成本，这时候就需要通过老户的活跃，去不断提升产品的DAU、MAU。 所以，需要明确，产品不仅有用户价值、也承载着商业价值，在产品的不同阶段会有不同侧重的需求。 二、用户研究用户和需求是相符相成，在产品迭代中，用户的需求是产品的驱动力之一。满足用户的需求，是产品存在的前提，只有在这个基础上，才能有下一步的商业变现。研究用户，是为了能更好地把握住产品该为谁而做，怎么创造出核心价值黏住用户。 了解用户 可以从抽象层面和具象层面两个角度去了解用户，用户画像是对用户轮廓的一种描述，通过用户画像可以使我们更清晰地明白用户是怎么样的，在产品设计的时候需要考虑哪些具体需求。 用户分类 用户分类能够对于复杂的用户进行切割，是为了更好地对用户进行区别对待，挖掘出需求来。比如，网易云音乐从用户的年龄和对音乐的喜好程度进行了切割，从而得出了4类特点的用户，分别对应白领、青春期的大学生、工作多年的人和资深音乐爱好者，针对这4个人群去进行需求分析和各个击破就更有针对性。 变成用户 最最真切的体验则是变成用户，一下子跳出产品制造者的身份，从外部视角去看产品；这样更能体会到在使用过程中的痛点是什么，从用户的角度去观察、去思考，才能挖掘出一些细节的需求点，获得该怎么样在细微处调整的洞见。 三、产品定位在一个供需平衡的市场中，只有找到定位才能撕出一个口子来，让用户更偏向于选择你，而非其他的竞品。这个定位就是用户选择你的理由，代表产品所服务的用户群是谁，所创造的核心价值是什么。 QQ的全民K歌，在产品初创期，通过用户的研究，发现用户唱歌的需求并没有完全满足，而且分析了市场上同类产品之后，在寻找有哪些竞争优势可以吸引到用户，发现腾讯的核心优势是社交关系链，所以明确了产品的定位，一个具有熟人关系链的独立唱歌工具。 定位代表了产品的方向，围绕着定位的持续打磨才能让产品定位变成用户可感知的产品特性。因此，他们围绕着核心定位“唱歌工具”提高基础体验，同时，在产品中引入熟人关系链，引爆了用户增长，也为产品构筑了闭环能力。 因此，在寻找及打磨产品定位时，有3点非常关键： 找到市场未被满足的痛点 定位应该从消费者的心智出发，而不是从产品本身出发。首先找到你想服务的那批用户，再找到这批用户没有被满足的痛点中，什么是自己可以提供的。 根据自己的优势，提供核心价值 基于这个没有被满足的需求以及自身的优势，打磨产品的核心功能，增加用户对于该产品的认知，从而获得用户选择你的偏好。 在恰当的时候，调整产品的定位，以获得更深度的发展 产品的定位，不是一成不变，而是随着用户数的增长，不断发展的。比如工具类的51信用卡管家，创立一开始的定位是信用卡的管理，当随着用户数的积累，以及场景的加深，开始发现用户本质是希望有对于自己负债的管理，因此，我们的产品定位从信用卡管理转变为了负债管理，从而接入了京东白条、蚂蚁借呗等一系列线上的负债账号管理功能。这样的定位改变，不仅增加了潜在用户，而且提升了服务的深度，增加了用户黏性，为产品更长远发展奠定了基础。 四、原型设计互联网产品分为两类，web端产品和客户端产品，一种是在本地的文件，一种是直接通过浏览器访问的。因此，无论是面向用户的前端产品还是面向B端的后台产品，最基本的组成要素都是页面。只不过对于C端用户而言，重点是引导用户的体验和购买，而对于B端用户，更多是为了运营活动及数据统计。 流程梳理在原型设计的一开始，首先需要梳理整个流程，可以通过画泳道图的方式，把角色、路径分析清楚，然后通过恰当的流程串联起来，完成梳理。 原型设计 这主要指具体页面的设计，这就涉及到页面分布，导航，具体文案展示，及文案从哪里取得，这时候懂一点开发知识有助于理出来需求。 非功能性需求设计 主要涉及到页面的兼容性，稳定性，打开速度等，这些是为了能更好地让产品服务到用户的考量。 五、版本迭代许多产品并非生来就NB，而是在不断地获取用户，不断迭代过程中，发现了增长的捷径，越变越好的，因此，完成产品的从0到1之后，养产品是一个非常重要的能力。 迭代的节奏 迭代是一种团队作业，需要把握好需求提出，开发提测，及发版的节奏，才能让团队能够更高效地运转，就像行军打仗一样，需要把握好队伍的纪律性，才能来之则战，战之能胜。 需求的安排 在迭代过程中，大小版本最好能穿插，同时根据产品的生命周期，需要识别功能的优先级。对于初创期的产品，快是非常重要的，快速的发版快速的反馈，以获得好的转化，才能在激烈的竞争中活下来。而对于稳定期的产品，比较重要的需求就是做活跃，和变现。因此，需求的安排需要根据产品的生命周期和开发的节奏来定。 六、数据分析互联网产品能够快速进化，领先于原子世界产品的一种重要因素是数据化，所有的用户信息、访问、转化都是可追溯的。因此，数据分析，是互联网产品实现高维打击最重要的一个功能之一。数据分析，关键是定义关键指标，分析薄弱环节，获得产品灵感。 定义关键指标 页面访问指标主要可以拆解成3类，流量的来源，流量的分配，及流量的转化。流量的来源，即主要用户来源路径是哪里，方便挖掘更多的流量；流量的分配则是在导航页面流量主要往哪里集中，为了更好实现自己的目标，可以在导航中做更好的引导；流量的转化，则是关心的一个流程里，用户的转化漏斗，分析环节中的转化率，方便去发现薄弱的环节。 寻找薄弱环节 当定义好关键指标之后，那些关键环节转化率的变化，就是我们最应该注意的地方。如果在整个转化漏斗中，发现某个环节的转化率特别低，那么就需要转门针对这个环节做优化。 获得产品灵感 从数据中，可以发现用户的点击偏好，已经用户特征。根据这些特征，去推出满足用户需要的服务，就是通过数据去驱动产品创新的主要来源。举个例子，在51信用卡的发现页，我们发现用户点击征信查询的行为特别多，因此，这说明用户非常关心自己的征信情况，同时很大部分用户通过查询拥有自己的征信报告，所以，我们据此推出通过征信报告来授信的借贷类产品，获得了不错的转化效果。因此，用户行为能够带来用户洞察，从而帮助我们寻找满足用户的产品。 七、产品增长Paul Gram 说 创业的本质是增长，对于产品而言，一落地之后遇到的最大问题也是增长。唯有获取越来越多的用户，带来越来越多的转化，才能卷入更多资源，从而投入到产品的迭代中，让产品越长越大，否则处境就很危险。 在产品增长中，有一个经典的AARRR模型，即把增长目标拆分为：拉新、促活、提高留存、变现、传播推荐5个步骤。 我主要做变现这一环节，因此重点讲一下产品的变现逻辑，对于流量变现，有一个完整的公式可以概括： 流量价值 = 流量 × 转化率 × 客单价 × 复购率 因此所有变现问题的关键就是围绕着： 怎么获取更多的有效流量怎么提高流量的转化率怎么提升客单价怎么提升用户的复购4个环节逐步展开，通过这几个措施，去推动产品的增长 产品是一个系统，一个项目从0到1，再从1到N，是在反复地迭代过程中，在与同类产品的竞争中，越滚越大的。","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"1-4 功能结构图，信息架构图，产品结构图的相爱相杀","slug":"1-4 功能结构图，信息架构图，产品结构图的相爱相杀","date":"2018-12-04T14:49:37.000Z","updated":"2018-12-25T15:17:25.187Z","comments":true,"path":"2018/12/04/1-4 功能结构图，信息架构图，产品结构图的相爱相杀/","link":"","permalink":"http://yoursite.com/2018/12/04/1-4 功能结构图，信息架构图，产品结构图的相爱相杀/","excerpt":"","text":"@蓝调L 功能结构图1.定义功能结构图就是按照功能的从属关系画成的图表，在该图表中的每一个框都称为一个功能模块。功能模块可以根据具体情况分得大一点或小一点，分解得最小功能模块可以是一个程序中的每个处理过程，而较大的功能模块则可能是完成某一个任务的一组程序。（百度定义）用通俗的话来说，功能结构图就是以功能模块为类别，介绍模块下其各功能组成的图表。 2.作用产品概念设计的运用工具之一，能够对不完全确定的设计问题或相当模糊的设计要求，以一种较为简洁和明确的方法表示。在绘制的过程中，能够帮助PM思考并清晰产品的功能模块及其功能组成；梳理需求，以鸟瞰的方式对整个产品页面中的功能结构形成一个直观的认识，防止在产品需求转化为功能需求的过程中出现功能模块和功能点缺失的现象。 3.注意事项在区分功能结构、信息结构图、结构图前，有一个重要的前提需要达成共识：软件产品本身就是传递信息和提供功能的载体，完全绝对的信息类或功能类产品是不可能存的在，信息往往伴随着功能，很难划一条界限将两者彻底分开。从某种意义上，信息传递甚至就是软件产品最主要的核心功能。鉴于此，通常默认地把信息展示功能独立了出来，作为信息架构的一部分去思考，在产品功能结构时不考虑信息展示功能。 这里举一个信息与功能纠缠的例子更好理解，如微信的个人信息模块（如下图），“名字”字段在这里既是信息又提供着修改设置的功能。 所以不难理解许多功能结构图中出现了信息结构的要素，但由于功能结构图的使用目的（即上文中的作用）要求专注于产品功能这个维度，在功能结构图中最好尽量减少信息结构要素出现的可能性。 就用上面功能与信息纠缠的例子来说，在其功能结构图中许多朋友会直接用“名字”来表示其功能点，画图人可能本人清楚，但看图人就会产生疑惑：这个“名字”到底是指提供可查看名字的功能还是可查看并修改名字的功能。 在这里介绍一个小诀窍，形容一个功能点时建议多采用动词+名词的语言描述形式，这种方式不仅信息传达更加准确而且可以避免读者不必要的困惑。如上面的例子中就可以把“名字”改为“设置名字”或“查看并设置名字”来描述功能点。 4.如何绘制功能结构图在实际应用时，产品功能结构图通常在以下2种情况下绘制： 对未完成的产品在设计阶段绘制，确定产品功能结构； 对已完成的某个版本的产品绘制，用于分析并传递该产品的功能结构； （一）在产品的设计阶段，如何挖掘并确定功能结构图中的主功能模块呢？ 首先主功能模块应该是产品在完整业务流程中的各个核心功能模块，可通过业务流程中所涉及到的功能需求去提炼出主功能模块，提炼完成后再通过业务流程走查一次，看是否有遗漏的主功能模块。 举个例子，假设在微信的早期功能设计，其产品初期定位是一款移动社交软件，那么其对应的核心业务可以简化为 这样就很容易得出产品设计阶段微信的主功能模块，如下： 结合下面现有版本的微信功能结构图对比一下，经过上百次迭代，其主功能结构几乎没有发生变化，不得不佩服其功能结构的拓展性； 当通过业务流程将主功能模块确定下来后，再根据业务需求对其进行功能的详细设计即可，在此就不再展开了。 （二）对于已确定产品来说如何绘制功能结构图呢？ 对一款已确定产品绘制功能结构图，最快捷的方法便是参考产品的Tab功能模块找出产品主功能模块，然后按照层级归属关系详叙该功能模块提供的下一级功能模块或功能，如有必要，其颗粒度可一直细化到功能操作的描述程度。 那上图“微信功能结构图（V6.5.21）”的主功能模块为什么不是“微信”、“通讯录”、“发现”、“我”这四大标签功能模块？ 在这里希望传达一个概念，结构图中的主功能模块不一定就是Tab中的标签功能模块，许多时候产品受限于移动端的空间限制，不得不把功能分为3到4个Tab中，这是一种务实的妥协。当然正常情况下以Tab标签名作为主功能模块的做法没有错，只是当产品功能复杂时，产品功能结构图采用这种划分有点粗糙。而绘制已确定产品的功能结构图能够帮助去挖掘这个产品的核心功能模块，梳理产品的功能架构。建议作图人可以尝试脱离Tab标签用自己的语言去挖掘并描述主功能模块。 这样说来就可以随意将标签功能模块中的次级功能模块划分出来作为主功能模块吗？ 其实也不是，一款不管多复杂的应用其主功能模块的划分数量都不能太多（5-9个为佳），一般情况下当对产品功能结构进行分析后，仍然会采用Tab功能模块作为主功能模块然后对其下属的功能模块进行整理。只有在认为某个次级功能模块在业务上太过重要且产品价值较高时，才可以将其划分出来作为一个单独的主功能模块。 这里介绍一个小秘诀，当一个次级功能模块反复出现在不同的Tab功能模块中的时候，就可以考虑将其拆分出来作为主功能模块，因为这个时候意味着这个次级功能模块在产品的业务流程中来说十分重要，而且这也可以让产品功能结构图更加简洁清楚。如上面“微信功能结构图（V6.5.21）”中的搜索模块就同时出现在了Tab中的微信功能模块和通讯录功能模块。 最后如何确定功能结构图中的颗粒度呢？ 功能结构图中的颗粒程度需要根据具体应用场景来定，由画图人根据需要自行把控即可。比如说在产品设计的过程中，功能结构的建立是设计者的设计思维由发散趋向于收敛的过程，刚开始的颗粒度一般比较大，可能仅涉及到某个功能模块，随着设计的不断推进，功能结构图的颗粒度会不断细化，最终可以拆分至某个具体的功能操作。这里将“微信模块-个人对话”功能模块作了细化，仅供参考： 信息结构图定义：指脱离产品的实际页面，将产品的数据抽象出来，组合分类的图表。 作用： 帮助PM梳理复杂内容的信息组成，避免信息内容在展示过程中出现遗漏、混乱、重复； 作为开发工程师建立数据库的参考依据；信息结构图的绘制通常晚于功能结构图，往往是在产品设计阶段的概念化过程中，在产品功能框架已确定、功能结构已完善好的情况下才对产品信息结构进行分析设计。 在这里，需要强调的是脱离实际页面这个概念，在一些产品相关文章中，会看到作者将信息结构图完全按照页面的逻辑顺序来进行分类组合，严格意义上来说，这种图表不是一份合格的信息结构图。 用微信的个人信息模块举例，如下图所示： 其结构信息图在这部分的绘制就需要脱离产品的实际页面，如下： 最后需要强调的是：信息结构图主要适用于产品信息构成比较复杂需要考虑优化的情况，如内容型产品（博客、web门户网站等），产品的信息结构对于用户体验就十分重要，需要用信息结构图作为工具进行分析思考。 这里简单绘制了一下微信的信息结构图作为参考 产品结构图相较于功能结构图和信息结构图，产品结构图的定义就很混乱和模糊了，为什么会出现这种情况呢？ 一方面产品结构图从文字理解上来说就容易让人困惑：产品信息结构图、产品功能结构图不都可以简称为产品结构图嘛。 另一方面现有网上流传的竞品分析文档、产品体验文档、PRD文档有不少是由产品新人模仿前辈流传出来的文档模板来写的。但让人尴尬的是，有部分同学没有进行细致深入地了解。经常在一篇文章中，前面说是产品的功能结构图，结果图中是产品功能有，产品信息要素也有，没有理解功能结构图的定义。而后来的初学者又从这些文章中去了解学习产品功能结构图、产品信息结构图，导致恶性循环； 最重要的原因是：对于产品结构图，产品从业人员这个群体自身都还没有达成共识啊。作者在网上搜了搜相关文章，对于产品结构图大家的主要理解有3种： 大部分产品人认为：产品结构图即产品功能结构图的简称，可能在产品没有强调信息结构的概念时，有部分PM开始简称产品功能结构图为产品结构图，之后便默认了这种称呼，当出现产品信息结构图后，概念就产生了混淆； 一部分产品人认为：产品结构图是综合展示产品信息和功能逻辑的图表； 少部分产品人认为：产品结构图就是产品信息架构图。在这里更认同第2种观念： 产品结构图是综合展示产品信息和功能逻辑的图表，简单说产品结构图就是产品原型的简化表达。它能够在前期的需求评审中或其他类似场景中作为产品原型的替代，因为产品结构图相较于产品原型，其实现成本低，能够快速对产品功能结构进行增、删、改操作，减少PM在这个过程中的实现成本。 产品结构图就是通过信息架构设计，将功能和信息以一种合理自然的逻辑，把功能结构图和信息结构图中的内容放入产品中的每一个页面的结果。而现在许多PRD、竞品分析中提到的信息结构图、功能结构图其实大多数都是同时含有功能和信息元素的简化版产品结构图。如下图所示： 总结在一款产品的设计过程中，功能结构图是必须的，信息结构图视产品和PM自身而定，通常初步确定了产品功能结构图（产品功能框架）之后才开始绘制产品信息结构图。 在产品设计流程中，产品功能结构图是产品概念化阶段的初期输出，产品结构图是产品概念化的尾期阶段输出物，当产品结构图完成后，对产品的基本模样在心理就有了一个轮廓。同时以产品结构图作为绘制原型的依据，可以避免在产品设计中边画边改，跳进死掐细节，不见森林的陷阱。 作者：蓝调Lee，微博号：蓝调L 本文由 @蓝调Lee 原创发布于人人都是产品经理。","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"1-3 KANO模型 及 其他常用设计模型","slug":"1-3 KANO模型 及 其他.常用设计模型","date":"2018-12-03T14:49:37.000Z","updated":"2018-12-23T14:20:43.586Z","comments":true,"path":"2018/12/03/1-3 KANO模型 及 其他.常用设计模型/","link":"","permalink":"http://yoursite.com/2018/12/03/1-3 KANO模型 及 其他.常用设计模型/","excerpt":"","text":"KANO 模型1.概念kano模型是狩野纪昭教授发明的一种工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。 在卡诺模型中，将产品和服务的质量特性分为五种类型： 必备属性：当优化此需求，用户满意度不会提升，当不提供此需求，用户满意度会大幅降低； 期望属性：当提供此需求，用户满意度会提升，当不提供此需求，用户满意度会降低； 魅力属性：用户意想不到的，如果不提供此需求，用户满意度不会降低，但当提供此需求，用户满意度会有很大提升； 无差异因素：无论提供或不提供此需求，用户满意度都不会有改变，用户根本不在意； 反向属性：用户根本都没有此需求，提供后用户满意度反而会下降。 基本需求：也是基础性需求，理所当然的需求，也是用户认为“必须要有”的功能。简单的来讲，如果“没有”，用户就会很不满意，如果“有”，用户也不会为此感到满意，毕竟，此类型需求属于“理所当然”的需求。比如说，需求文档，对于产品经理而言，就是这样的基本需求，如果不会，那你的leader大概会对你极为不满，如果你会，他也不会为此表扬你。 期望需求：此类型需求与基本需求相反，简单的来讲，就是这么一个意思，如果有，则用户会感到满意，如果没有，用户也不会感到失望。比如说，需求管理，对于我们来讲，就是属于期望需求，作为产品经理而言，将我们的需求管理的越好，我们的leader 会越满意，反之，即使你不会管理需求，他也不会对你有所不满，大概就是表现平平之类的吧。 兴奋需求：兴奋需求某种含义上是期望需求的升级版本，有时候我们会提到的超越用户预期，以及 挖掘表面需求背后隐藏的需求，便是指期望需求和兴奋需求的关系。就以表面和背后来讲，期望需求是指用户表面的需求， 兴奋需求则是指背后的真实需求。我们仍然以需求文档来举例。管理需求文档是我们表面的需求，通过对需求文档的管理，让团队效率更高，有更多的需求可被复用，以及需求尽可能少的变更，始终让团队的战斗力发挥有效价值，这个便是让leader兴奋的需求。作为产品经理而言，需求反复，需求变更，遗漏需求，相信大家都不陌生，不仅仅是我们的leader，即便是对于我们自身而言，如果真的能减少反复，减少变更，同样也会让我们感到兴奋的，难道不是吗？ 无差异需求是指有没有都无所谓的这部分需求，不论提供或者不提供，对用户体验无影响，换言之，即使不做，也不会让客户不满意。这部分需求，往往是我们要避免的 “多余动作”，虽然是这样说，但在工作上，我们却极为容易做出这样的事情。这个案例算是很经典了，“登录”与“登陆” 当我们在文章里 写到了“登陆”时，如果产生了情绪，这就代表我们在工作中，会经常性的为了无差异的事情耗费时间，毕竟，这样的错别字，并不会影响用户体验。（我需要强调，我们所谓的用户，是指使用某产品的人，以需求文档为例，他在开发过程中起到指引，排查的作用，而不是阅读一篇文章，因此文档里的错别字，在一定范围内是被允许且接受的。）避免无差异需求的原因在于，其会占用我们宝贵且不可再生的资源。 反向需求是指少数派需求，我们在做需求分析时，需要考虑需求的使用面积，并且在做优先级划分时，也需要按照影响面积来考虑，以满足大部分人的需求为首要目的，与这个原则相反的，便是反向需求，只满足少部分的需求。反向需求同时也是无差异需求的升级版本，我们所谓的无差异需求，是做不做都没影响，反向需求恰恰就属于，做了就会产生负面影响。比如，在需求评审时，我们在会议上讨论某文案内容，或者说某参数的设定，这种便是反向需求。在我们的team里，大部分的成员其实不关心文案也无须关心文案，只有少部分成员会关心这个问题。正确的处理方法是在评审会议里，讨论大部分人关心的议题，比如功能的业务逻辑，或者说为什么要做某功能。作者：枯叶链接：https://www.zhihu.com/question/22989667/answer/147825674 2. 使用场景卡诺模型的主要使用场景是对用户需求分类；另一种是对多个功能点进行优先级排序。 3. 具体使用操作 3.1 步骤一：设计问卷调查表，实施有效的问卷调查KANO 模型的问卷问法，是对每个质量特性都由正向和负向两个问题构成，分别测量用户在面对存在或不存在某项质量特性时的反应。问卷中的问题答案采用五级选项分别是： 我很喜欢：让你感到满意、开心、惊喜。 理应如此：你觉得是应该且必备的功能。 无所谓：你不会特别在意，但还可以接受。 勉强接受：你不喜欢，但可以接受。 我很不喜欢：让你感到不满意。 3.2 步骤二：问卷结果整理，进行数据分析 根据问卷结果进行 KANO 模型二维属性归属分析，可得出魅力属性、期望属性、必备属性、无差异属性、反向属性与可疑结果的功能属性归类百分比。除了对属性的归属探讨外，并通过百分比计算出 Better-Worse 系数，表示某功能可以增加满意或者消除很不喜欢的影响程度。 增加后的满意系数 Better/SI=(A+O)/(A+O+M+I)消除后的不满意系数 Worse/DSI=-1*(O+M)/(A+O+M+I) 根据better-worse系数值，将散点图划分为四个象限。 第一象限/期望属性：better 与 worse系数成正比；表示产品提供此功能，用户满意度会提升，不提供此功能，用户满意度会降低，这是质量的竞争性属性，应尽力去满足用户的期望型需求。 第二象限/魅力属性：better系数值高，worse 系数绝对值低的情况。表示不提供此功能，用户满意度不会降低，提供此功能，用户满意度和忠诚度会有很大提升； 第三象限/无差异属性：better系数值低，worse系数绝对值也低的情况。即无论提供或不提供这些功能，用户满意度都不会有改变，这些功能点是用户并不在意的功能。 第四象限/必备属性：better系数值低，worse系数绝对值高的情况。当产品提供此功能，用户满意度不会提升，当不提供此功能，用户满意度会大幅降低；此象限的功能是最基本的功能，这些需求是用户认为产品有义务做到的事情。 3.3 步骤三：数据解读，将结果落地实施 KANO 模型是对功能需求的优先级进行探索，是否需开发上线还要产品负责人进行决策和落地实施。 具体实践案例说明题目：根据报警内容，“掌上运维”提供运维操作建议（如磁盘满了智能推荐执行日志清理等） 步骤一：设计问卷问题，发放问卷步骤二：问卷统计，进行 KANO 模型二维属性归属分析 步骤三：根据问卷统计的用户数据，计算出每个区域的百分比 具体计算方式是全部区域的人数相加作为分母；每个格子中的数字作为分子，即可得出每个格子的百分比出来。 具体百分比得出后，将下表中标 A、O、M、I、R、Q 的格子中百分比相加，即可得到五种属性对应的百分比。本调查结果可以得到A魅力属性占比为42.1%，O期望属性占比9%，M必备属性占比1.2%，I无差异属性占比38.9%，R反向属性占比1.8%，Q可疑结果占比7%。 步骤四：根据 Better-Worse 计算公式，得出 Better-Worse 系数，明确功能落点象限。 步骤五：多个功能需求结果对比进行优先级排序。 其他各阶段常用模型 模型一：SWOT 模型 概念SWOT分析法（也称 TOWS 分析法、道斯矩阵）即态势分析法，20世纪80年代初由美国旧金山大学的管理学教授韦里克提出，经常被用于企业战略制定、竞争对手分析等场合。在现在的战略规划报告里，SWOT分析应该算是一个众所周知的工具。来自于麦肯锡咨询公司的SWOT分析，包括分析企业的优势（Strengths）、劣势（Weaknesses）、机会（Opportunities）和威胁（Threats）。 使用场景主要用在产品前期的战略规划中；用于项目成员知己知彼，同时也能知道在行业领域自己的产品所处的位置和核心竞争力是什么；对于产品方向的定位和全方位分析有复用价值。 设计价值SWOT 分析实际上是将对企业内外部条件，各方面内容进行综合和概括，进而分析组织的优劣势、面临的机会和威胁的一种方法。优劣势分析主要是着眼于企业自身的实力及其与竞争对手的比较，而机会和威胁分析将注意力放在外部环境的变化及对企业的可能影响上 。在分析时，应把所有的内部因素（即优劣势）集中在一起，然后用外部的力量来对这些因素进行评估。 具体实践案例说明下图是阿里内部某个数据服务平台分析的案例；侧重介绍了为什么要做这个数据平台；以及做这个平台我们项目组的优劣势和机会点分别是什么。在给老板汇报产品来源&方向时是非常有效的。 最后，SWOT 分析模型其实还可以与商业画布相结合，便于更全面对项目/业务进行快速分析和深入了解；深入懂业务的设计师才能真正在团队中进行发声，提出超越 UI 层的建设性意见。 模型二：Google Design Sprint 设计方法 概念介绍Design Sprint，设计冲刺，顾名思义就是要在短时间内做出好设计；是由 Google 提出的设计方法。 设计使用场景设计冲刺这个设计方法主要适用于短时间就需要产出设计方案；例如一些 Workshop 的共建, 产品迭代周期很快的新需求/任务，需要系统化分析与输出设计方案。 设计价值可以在很短的时间内输出一套系统化的设计策略及方案；通过与不同背景的参与者进行沟通协作，能获取更多看事物的角度和差异化知识；创造更多可能；作为一种理想的设计教育工具，让非科班的设计人员完整又快速了解产品&设计。 具体实践案例说明设计冲刺的主要内容包括6个阶段： 理解（Understand）：理解要为用户解决的问题 定义（Define）：明确产品策略（数据分析，用户调研，设计原则制定等） 发散（Diverge）：探索实现方案 决定（Decide）：确定设计方案 原型（Prototype）：构建产品原型 验证（Validate）：验证产品原型 模型三：GUCDR模型 概念介绍相比前一个设计冲刺模型，GUCDR 模型在设计过程中的实用性更强，能让你快速用起来，帮你系统性梳理信息；在实际工作中，只要能够回答画布中的每个点，即可形成完整的设计推演过程，让设计思路逐渐清晰起来。 G：Goal U：User C：Condition D：Design R：Realize 使用场景GUCDR 模型很适合用于前期需求调研和整理阶段；特别是在自己不是很熟悉的领域中，把信息按照模型和画布中的点进行归类汇总；最大限度的让自己的设计思维和信息逻辑得到诠释。 设计价值对设计的需求来源及设计目标的聚焦定位，非常有价值，能快入深入了解业务背景；对设计阶段的目标拆解，从设计目标 > 设计策略 > 设计方案，层层递进，设计方案输出的逻辑性和针对性很强。 具体实践案例说明GUCDR 模型在具体的使用过程中，可以和 GUCDR 画布结合起来一起使用。信息下钻的更深入具体，从项目目标到设计落地，每个阶段都有具体的节点支撑，在使用过程中只需要把信息直接输入到对应的位置即可。下图为 GUCDR 画布模板，可直接把业务相关信息输入进来。 模型四：双钻模型 概念说明双钻设计模型由英国设计协会提出，该设计模型的核心是：发现正确的问题、发现正确的解决方案。双钻模型是一个结构化的设计方法，被很多设计师喜爱和使用。 探索/调研——透析问题（发散） 定义/合成——聚焦领域（集中） 发展/构思——潜在问题（发散） 传达/实现——实施方案（集中） 使用场景一般应用在产品开发过程中的需求定义和交互设计阶段；教我们如何对未知的可能的事物进行探索；一步步到达已知的理应的层面。 操作使用说明双钻模型的四个阶段也许很精简并且合并到两个主要的阶段。 第一阶段：做对的事（菱形1——探索和定义） 第二阶段：把事情做对（菱形2——开发和履行） 具体实践案例说明下图是对阿里内部一款移动运维产品的分析，分析其从 0-1 的方向探索和从 1-1.5 的发展历程：下图是曾经在一个设计讲座中，滴滴 CDX 一位设计师的分享，她把双钻模型利用到设计的研究和输出阶段，此模型此刻的使用场景也很贴切；不仅仅是在完整的一个项目中，在单一的某个阶段双钻模型也是理念很好的承载容器。 模型五：METUX幸福模型 概念说明为了帮助大家更好地进行“幸福设计”，卡里罗教授分享了他的一个模型——Motivation, Engagement and Thriving in theUser Experience (METUX)。 使用场景产品成熟稳定期，需对产品&用户体验进行迭代提升时；综合对产品体验进行评估分析，需提升用户幸福感，希望产品能对用户行为方式及生活质量有所影响时。 主要使用操作在考虑用户体验时，从4个层次进行考虑： 第一层是“界面”体验：用户与产品交互时的体验如何。 第二层是“任务”体验：界面之上是用户完成的任务。如利用智能手环计步，用户在完成任务时体验如何。 第三层是“行为”体验：任务之上是用户的行为。如用户购买智能手环的目的是运动，此时行为可能是跑步、骑自行车。因此 产品在任务之上应该深入关注用户行为上的体验。 第四层是“生活”体验：行为会对生活产生影响。如运动过量可能导致身体受损。 在设计过程中，应该关注“胜任力”、“自主性”和“关系”三个关键因素，这些基本心理诉求是动机、投入感和幸福感的根本。","categories":[],"tags":[]},{"title":"1-2 用户需求到产品需求","slug":"1-2 用户需求到产品需求","date":"2018-12-02T14:49:37.000Z","updated":"2018-12-23T10:06:34.575Z","comments":true,"path":"2018/12/02/1-2 用户需求到产品需求/","link":"","permalink":"http://yoursite.com/2018/12/02/1-2 用户需求到产品需求/","excerpt":"","text":"产品需求（软件需求）业务需求业务需求指的是宏观需求，即我们要提供一个什么新的解决方案，解决现有的什么行业问题。一般由企业老总或产品负责人提出，这是从顶级层面来说明，比如我们要做一个在线打车的解决方案，比如要做一个在线订餐的解决方案。有了业务需求之后，紧接着需要的就是评估产品机会。该如何评估可参考我另一篇文章《如何评估一个产品是否有价值》。 用户需求有了业务需求之后，确定了有哪些用户，紧接着就要分析具体的用户需求。比如打车软件，就要分析出租车司机、专车司机、打车用户不同的需求。用户需求是产品执行过程中，最有难度的需求挖掘。该跟随用户还是引导用户，该如何深层次的挖掘用户需求，用户的需求该如何转换为产品需求。 功能需求用户提出了需求，但用户提出的需求不可能太细，这个时候需要我们去优化完善，这个是产品经理很重要的一个职责。比如用户要一个快捷打车功能，那我们相应的要提供的功能有：家和公司常用地址的编辑更新功能；家和公司地址的快捷选取；根据时间判定是打车到公司还是打车回家，自动选择。 系统需求前面三个需求是用户能感知并参与验证的需求，但系统需求是完全隐匿于技术实现中的技术需求。比如用户登录功能，用户账户名长度字符要求，是否要加密传输。是否要用分布式服务器，是否要做redis缓存，是否要用分布式数据库等等。不过随着产品的上线，内部运营和相关人员也会提出要开发一个运营系统，这个时候又该如何看待产品需求。其实这个时候，这个运营管理系统即为业务需求，运营人员即转换为用户，他提出的需求即为用户需求。 从用户需求到产品需求的一般分析思路(一)需求本质用户需求本质来源于人的需求本质，根据马斯洛需求层次理论，可将人的需求分为五个等级：生理需求、安全需求、社交需求（爱和归属感）、尊重需求和自我实现需求。 可以通俗理解为：假如一个人同时缺乏食物、安全、爱和尊重，通常对食物的需求是最强烈的，其它需求则不那么重要。此时人的意识几乎全被饥饿所占据，所有能量都被用来获取食物。在这种极端情况下，人生的全部意义就是吃，其它什么都不重要。只有当人从生理需要的控制下解放出来时，才可能出现更高级的、社会化程度更高的需要，如工作、健康、保障等需要。 在做需求分析时，首先要思考目标用户都有怎样的需求，这些需求对应到的需求本质是哪个层级。如果这种需求能溯源到人性的本质，那么此类产品的潜在用户会非常多，如果体验足够好，就可以成为一款爆品。如微信，它的需求本质就是“社交”，人天生是喜欢社交的，一段时间不和朋友联系便会感觉孤独，生活中的喜怒哀乐都希望有人能一起分享。而微信就解决了“人性本质”的问题，再加上其良好的用户体验，在一经推出就受到热烈的欢迎。 自我发散：（一）手机车机互联这类产品满足了用户什么样的需求本质？答：安全需求、娱乐需求、社交需求（二）手机车机互联有什么意义？ 改善车机不足，增强车载环境下的用户体验 车机有哪些不足？i.触摸屏技术不够先进，不够灵敏，反应迟钝现有技术：电阻技术触摸、电容技术触摸、红外线技术触摸ii.屏幕显示技术不够先进，受光线影响大，显示分辨率、清晰度不足iii.车载导航地图数据老、旧，升级不方面iv.车载电台、音乐等体验不佳 车载环境有哪些特征？i.安全需要，不能影响驾驶或增加事故隐患（不能分散司机注意力）ii.车内环境受温度、光线、噪音、天气等影响较大iii.对数据传输速度、稳定性要求较高 将手机上有趣、有用的应用投射到汽车上使用 手机上常用的并且适合迁移到汽车上的应用有哪些？i.导航类（百度导航、高德导航、腾讯地图等）ii.媒体类音乐：网易云音乐、QQ音乐、虾米音乐、酷狗音乐、酷我音乐、百度音乐、多米音乐、豆瓣FM等电台：喜马拉雅、荔枝FM、凤凰FMiii.社交类（微信、QQ、陌陌等） 将手机上已有的操作习惯延伸到汽车上 手机上有哪些操作习惯？i.导航（不知道路线的时候会想起用手机导航，而不是去问路人）ii.听歌（想听音乐的时候只需要随身携带一个耳机，而不用去买唱片）iii.看电影（想看电影的时候可以在手机上观看，而不是去电影院）iv.购物（用手机购物，不用自己跑到商场）v.美食（用手机查询附近美食，而不是随便挑一家饭馆去尝试）这些已有的使用习惯已经培养好了，可以很顺利的迁移到车载环境，不用去重新引导。 延伸有什么意义？i.汽车保养ii.加油iii.代驾iv.救援v.车险可演变出更多的适合车主使用的O2O服务，并产生价值。 车机免安装，增强安全性a)免安装：减少对硬件和容量的要求b)不用在车机上安装第三方app，减少恶意软件带来的风险。 手机的创新速度远超车机，未来有更多的可能。 (二)需求分类1.有声需求和无声需求按照用户能否表达出的角度，需求分为有声需求和无声需求。如问用户对智能手机有什么需求，很多人都会跳过打电话、发短信这样的基本功能，直接提出对应用数量、应用质量、交互体验、硬件配置等需求。这里的打电话、发短信就是无声需求，这是被用户默认为必备的功能，是必须要有的即使不说出来；而交互体验，应用数量、硬件配置则是有声需求，即直接被用户提出的需求。 2.显性需求和隐形需求按照用户需求表达的深度，需求又可以分为显性需求和隐形需求。如亨利福特的一句经典名言：“如果我最初问消费者他们想要什么样的交通工具，他们应该是会告诉我，要一匹更快的马！”这里“更快的马”就是显性需求，因为当时还没有汽车的概念，人们所认为的更好的交通工具就是跑的更快的马，拿到这样的需求后，很多人是立刻跑到马场去选马配种，以满足客户的需求。我们通过市场调查得知的往往都是一些诸如“我要一匹更快的马”这类显性需求。客户的显性需求并不是客户真正的需求。企业需要根据所收集的显性需求信息进行深度挖掘和捕获，以了解客户的隐性需求是什么，进而分析出客户的真正需求是什么。而此时更快的马的深度需求显然是速度更快的交通工具，和马没有必然联系，可以是新生产出来的一种比马更快的交通工具，汽车或飞机等。 3.KANO模型从用户满意度的角度来分析，需求又可分为基本型需求、期望型需求和兴奋型需求。基本型需求诸如一个人饿了需要吃饭，这个时候填饱肚子就是基本需求，不管是一碗面还是两个馒头，都可以填报肚子，但不能是一碗水。这就是基本型需求的含义，如果需求分析只到这个层次，此时可以满足客人饥饿的需求，但是不能提高他的满意度，客人在吃完饭后不会给好评。所以在满足基本需求的同时，如想得到好评，还需兼顾客人的期望型需求，这里的期望型需求就是指在填饱肚子的基础上，给客人更加符合口味的饭菜，如在面里加几块牛肉，迎合客人对肉食的期望。再加上合理的价钱，顾客的满意度就会上升。在这个层面上的需求分析算是进了一步，但还是达不到满分好评的标准。此时还需继续分析客人的兴奋型需求，如客人吃碗面后是不是口渴了，要不要送上一瓶饮料，服务员服务态度怎样，饭菜是否卫生等，分析到这个层次基本就达到了满分好评的基准。这里的基本型、期望型、兴奋型就是按照用户满意度的角度来区分的。 4.普遍存在的用户需求类型笼统的说，常见的需求类型可以分为：娱乐休闲、归属感、沟通、意见领袖、利益、获取知识和资讯、自我情感表达、爱和被爱、社交、分享、安全、尊重。我们在市场上见到的大部分产品都涵盖了以上一种或多种需求，如腾讯视频满足用户的娱乐休闲、获取知识和资讯的需求；知乎满足了用户的自我情感表达、社交、知识分享、意见领袖的需求。 自我发散：1.在询问车主对车载系统有什么意见时，经常得到的反馈是地图不好用，音乐不喜欢等。 有声需求：车载导航太旧，需要更新地图数据；音乐不符合个人品味无声需求：车载导航的定位要准确，路线要清晰，数据要最新，最好有多路线规划功能；音乐最好能播放在其他平台收藏的歌曲。 显性需求：更新车载导航数据，更换SD卡歌曲库。 隐性需求：使用最新的导航地图数据，不管是车载导航还是手机导航，不额外花钱，导航准确就行基本型需求：升级车载导航数据，更换SD卡歌曲库。 期望型需求：地图数据保持最新，路线规划清晰，支持3D导航，可以播放手机中收藏的歌曲 兴奋型需求：解决导航数据老旧问题，可以随意播放手机音乐应用中的歌曲，映射的应用能后台正常运行，手机可以进行其他操作。 (三)需求获取1.把自己当成用户只有这样才能理解产品，此为体验。同时还要避免成为重度用户，以免影响自己对普通用户的判断。如在设计一款社交应用时，把某项重要功能埋的很深，想当然的认为用户可以找到它，以一个重度用户的思维来思考新用户对产品的认知。 2.利用搜索引擎、相关论坛获取举个简单的例子，分析车主对车载导航的需求，可以在百度指数中检索，搜索“车载导航”关键词出现的概率及相关的需求分布。 从图（1）中可以看出近半年来，人们对车载导航的关注呈上升趋势，并且随着私家车的拥有量增加，这个趋势会一直延续。接着看图（2），从车载导航的需求图谱中可以看到，导航的升级和下载安装是最热的需求。从图（3）和图（4）中可以看出，“车载导航升级”相关的网页数量高达3000多万个，在百度知道中网友的相关提问数量也高达30多万，这个数字仅仅是主动发问的数量，不包括看答案但没发问的网友。所以以上两个数据可以充分显示，很多车主都面临“车载导航升级问题”这样的问题。这个需求量还是很大的。 3.产品使用中发现需求一个好的产品必然是经过了很多次的迭代和更新后，才逐步完善起来的。就像微信刚提供自媒体功能时，短时间内大量的微信公众账号被申请，每个微信用户都订阅了大量的公众账号，每天都会收到很多推送信息，甚至超过了和好友的联系频率。此时的推送信息对用户而言就变成了一种骚扰。微信5.0版本更新以后，订阅号被折叠了起来，并划分到了二级目录，未读条目也被红点所代替，骚扰问题很大程度上被解决了。这种需求就是在产品发布后的使用过程中发现的。 4.在反馈中发现需求用户的反馈很重要，据说马化腾会经常将用户的反馈直接通过邮件发给其他人。但是需要注意的是用户想要什么(want)和需要什么(need)是不同的，want只是need的一种具体表现罢了。正如那个经典的例子，用户想要一匹快马，用户需要的是更快的交通工具，所以你应该给他一辆汽车。 (四)需求评估在进行需求评审时，经常会被问到这样的问题：为什么要做这个需求？为什么不做那个需求？你的判断依据是什么？那么如何判断一个需求到底要不要做呢？又有怎样的评估标准？一般来说，常用的需求评估的方法是KANO模型评估。从前面我们已经得知，KANO模型中定义了三个层次的用户需求：基本型需求、期望型需求、兴奋型需求。基本型需求是指用户认为“必须有”的属性或功能，也叫需求的痛处。期望型需求是指那些连用户自己也不确定的的，但是你提供了他们会很乐意看到的需求，也叫用户需求的痒处。兴奋型需求是指提供给用户一些完全出乎意料的产品属性，使用户感到惊喜，也叫用户需求的暗处。 第二、三象限：表示一旦实现了一定数量的必须功能，就无法再通过增加这类功能来提高用户满意度了，无论增加多少必须功能，用户满意度都不会超过中点以上。第一、四象限：表示只要实现了部分兴奋点，就可以明显提升用户满意度，苹果的产品在这方面是典型代表。第一、三象限：表示期望型需求的增加和用户满意度呈线性增长，所以这类需求越多越好。时间的衰减：用户的需求类型是随着时间变化的，也许期望型需求变成了基本型需求，兴奋型需求变成了期望型需求，需要重新挖掘用户的兴奋型需求。通过上述分析不难看出，对于基本型需求（必须完成的需求），在产品发布时就需要完成；期望型需求则要尽可能多的完成；如果时间允许，至少应该确定少量的兴奋型需求的优先级。及时跟进用户的需求状态和类型，不断挖掘用户新的需求兴奋点。 自我发散：手机车技互联产品的KANO模型分析：基本型需求：a)兼容智能手机的ios系统和Android系统；b)手机屏幕能够投射到车机屏幕中，并且可从车机屏幕反向控制手机；c)投射过去的屏幕自适应分辨率和横竖屏；d)电话、导航、音乐声音播放优先级依次降低；期望型需求：a)支持导航、音乐类应用，并能通过车机音响播放声音；b)支持数量丰富的第三方应用程序；c)一键导航d)支持有线、无线两种映射方式e)有线映射可以给手机充电兴奋型需求：a)投射过程中手机可进行其他操作，正在投射的应用不受影响；b)… (五)从用户需求到产品功能用户有需求时，怎么满足用户的需求呢？这个时候就需要产品了。一般来说，互联网产品是指能够提供给用户使用，以满足用户需求的，一系列互联网功能的组合。经过推敲过的用户需求，可以和产品功能一一对应起来。如用户有了解未来天气的需求，那么在产品功能上就可以增加“未来三天天气预报”的功能；同样，用户需要了解当前的最新天气，那么产品功能上就可以设计“实时天气”的功能。只要是经过评估过的用户需求，就可以在产品功能上设计相关模块与之对应。明确产品的核心功能，明确满足用户什么需求，然后就可以出功能列表了。当产品的核心功能确定下来后，产品的使用人数、使用频率、使用时长这三个指标可能的最大值也就基本确定下来了。产品的核心功能，决定了产品的潜在用户数。如有的人爱美食，有的人爱音乐，有的人爱健身，有的需求大部分人都有，有的需求只有小部分人有，因此用户需求可分为大众需求和小众需求。如果产品提供的核心功能满足大众需求，那么产品的潜在用户数量就会很大；反之，产品的潜在用户数量就会很有限。产品的核心同样能决定用户的使用频率和使用时长。如一款天气应用产品，用户每天可能就会打开2-3次，早上起床一次，中午吃饭一次，晚上下班一次，每次打开的时长也就是2-3分钟。所以核心功能一旦确定下来，那么它可能获得的最大市场也就确定下来了。","categories":[],"tags":[]},{"title":"1-1 需求分析方法论","slug":"1-1 需求分析方法论","date":"2018-12-01T14:49:37.000Z","updated":"2018-12-23T10:05:39.481Z","comments":true,"path":"2018/12/01/1-1 需求分析方法论/","link":"","permalink":"http://yoursite.com/2018/12/01/1-1 需求分析方法论/","excerpt":"","text":"需求分析方法论一. 需求的获取、采集与表达 需求分析是产品经理的核心竞争力，以需求的来源、采集与描述三个方面为入口，结合案例，介绍了相对应的方法和使用工具。 从哪里获取需求？需求的获取方式有很多，比如产品大牛的天马行空，用户粉丝的意见反馈，产品前期的用户调研等等，以下是几个常用的获取需求的方式。 1. 来源1.1 用户调研（1）定量调研-问卷目的：根据调查者想要获取的信息设计问卷，收集一定基数并进行数据分析。优点：结果便于统计处理与分析、可大规模的调查、效率高节省时间成本。缺点：调查结果广而不深、问卷设计对用户选择有间接影响、开放性问题少、无法引导用户深入思考。 （2）定性调研-采访目的：挖掘用户的主观因素，从宽度（体验、感受、困惑、预期）和深度（功能-结果-利益-价值观）两个维度判断他们对产品的认知。优点：深入有效，多为开放性问题，可由浅入深得知受访者的需求，进而挖掘受访者的需要和痛点。缺点：样本小、需要较多的人力、物力和时间、面对面缺乏隐秘性导致受访者回避敏感问题。 1.2 用户反馈常见的用户反馈来自于互联网社交平台（微博、贴吧、知乎、微信、QQ、app store以及产品自带的客服投诉和建议模块。一般通过以下几条判断条件筛选出有用的反馈并加以解决相应问题： （1）用户类型—什么用户提出的？（潜水用户／话题制造者／专业人士／死忠粉／VIP会员等）一般专业人士提出的反馈结合了丰富的专业知识，比较有深度；死忠粉有长期使用产品的经验，对产品理解较深；VIP会员是产品的核心用户，及时解决他们的问题十分有必要。这些用户反馈的价值性相应高于一般或短期用户。 （2）使用场景—在什么场景下提出的反馈？（地铁／公司／学校／车上／上班时／吃饭时／睡觉前等）根据用户使用场景的频率和次数判断，一般使用频率高的场景下提出的反馈可能是大部分用户都遇到的，所以解决此类问题的优先级相应较高。 （3）反馈次数—是否有同类型、重复的反馈？（单个用户多次反馈相同问题／多个用户反馈相同问题）如果同一个用户多次反馈相同问题，说明此问题已经重度影响了该用户的用户体验，而且一直没有得到解决；反馈中一个问题被不同用户反复提起，说明大部分用户受到困扰，这两种情况下的反馈应优先被解决。 老板 在产品研发初期，经常会遇到会上老板一句话直接给需求，这些需求往往来自于老板丰富的工作经验以及敏锐的市场嗅觉，不能说老板提出的一定对，但是一定是有依据的。作为产品人员应该先消化和理解老板的想法，如果还是觉得有问题，拿出相应的数据依据来说服老板。 数据分析 一般来说，产品人员可以通过一些数据网站（极光数据、百度指数、艾瑞咨询）获取市场趋势和用户喜好，进而获取用户需求；此外，运营及数据分析专员 会根据市场做的相关数据统计（访问数、停留时间、跳出率等）提出部分需求。 需求采集步骤不同的阶段需求采集可使用的方法也不一样，苏杰在《人人都是产品经理》一书提到，合理搭配定性和定量方法，一般可根据产品时间轴分为四部分： 产品规划阶段，针对性采访用户，定性分析用户需求，确定产品整体大方向 产品早期，投放问卷调研，定量分析用户需求，确认产品需求 产品上线阶段，测试并根据用户反馈获取需求，确认产品需求优先级 产品优化阶段，根据用户使用产品情况定量分析数据，确认需求优化产品 需求的构成需求不是单独存在的个体，而是与场景、用户、目标同时出现的。当描述一个需求时，需要交代时间、地点、人物、描述、需求（欲望）和方法。举个简单的例子： 在一个阳光明媚的早晨（时间），我在去地铁站的路上（地点），但是距离有点远，走路要十五分钟（描述），于是我产生了一个快点到达地铁站的想法（欲望），决定扫描二维码，骑小黄车去地铁站（方法）。 这样描述起来需求会显得具体易懂，也有利于产品人员之后的需求表达和管理。 如何完整表达需求 在需求被采集之后，需要将各种需求具象化并放入需求池中，这里提供两种方法来表达需求，一个是单项需求卡片描述单个需求，另一个是需求清单（feature list）来管理多个需求。 1.单项需求卡片此卡片的核心在于让开发人员了解每个需求的描述信息（who/where/what/when/why）以及重要紧急程度，为未经加工过的用户需求，多为需求属性陈述。下图为模版并详细解释了各个栏目要填写的内容：以小黄车为例，近来看到网上讨论是否要在小黄车APP增加导航功能（事实上笔者认为此需求为伪需求），那么它的单项需求卡片卡片填写应该如下： 2.需求清单单项需求卡片和需求清单不仅仅着重于表达需求，也涉及到部分需求管理内容。而且，面对随时都有可能蹦出来的需求，如何评估需求性价比并选择性纳入需求池也是产品经理需要考虑的，在下一部分需求管理中进行讲述。 二.需求分析的步骤 从事需求分析以来，不管是自己参与的或是完全由自己一个人需求调研的，也有过大大小小项目需求调研的经历。这周去了深圳某券商进行了为期一周的需求调研，需求调研完成之后，其实总结下来有些套路可以使用。 如果把IT比做一个江湖，无论是什么公司什么业务的需求，练好这个武功心法“四层五步五清法”，可以从宏观上以及部分微观上理解用户的需求。之所以说是部分微观，是因为具体的需求，还得具体的分析，但练好这个武功心法，在需求分析的宏观上可以说没有问题。 四层：1.第一层职能层：梳理各部门的职能。一个系统如果涉及到很多部门，那么梳理各部门的职能能帮助我们去理解他们提出需求的原因，甚至通过了解各部门的职能反过头去质疑其他部门提出的需求。 举一个很简单的例子，某券商的风控部牵头要建设信用风险管理系统，为实现监管的“同一客户，同一业务，统一管理”，风控部将其他业务部门也纳入到系统中来，在需求调研阶段，某业务部门提出在实现一个报表查询到时候，需要部门与部门的权限隔离，即固收部的看固收部的持仓数据，其他部门在看同一张报表的时候看不了固收部的持仓数据。 咋一听这个需求提的很合理，但是风控部的职能是从公司整体上控制风险并防范风险，风控部可以看所有业务部门的数据。 用户提需求的时候只是出于自身考虑，并没有想到其他部门，所以当需求涉及多个部门的时候，需求分析人员在需求调研阶段把各部门的职能弄清楚。 2. 第二层业务层：梳理业务。没有人会无缘无故去购买一个系统，对于企业而言购买系统就是想将公司的业务放在系统上去做。不同类型的企业或不同部门，业务是不一样的，业务的复杂程度决定了系统的复杂程度，若一个复杂的业务能够被梳理的逻辑清晰条理清晰，系统也不会很复杂，但前提是你很懂很懂业务。 当一个业务小白如何快速的理解业务，可以搜集业务相关的名词解释，弄懂这些名词算四分之一理解业务。每种业务都会有其特定的术语，比如在物流行业，你需要知道什么是货代、邮路、头程、预报等等，在金融行业，你需要知道什么是股票质押、债券投资、融资融券、资管计划，除此还不够，你需要理解透每一个业务以及业务与业务的差别，比如股票质押与融资融券的差别在哪？ 3. 第三层数据层：梳理信息。这需要需求分析人员懂一些技术才能梳理清楚，对需求分析人员很高要求的一个层次。对于系统的底层数据，需要梳理数据与数据的流向，数据与数据的逻辑关系，这些都梳理清楚以后，对于现在的开发或是以后的迭代都能起到很大的作用。 4. 第四层：梳理支撑环境。业务需求以及数据都弄清楚以后，还需要考虑非功能性的需求，比如系统的硬件环境和软件环境是什么，用谷歌浏览器还是IE浏览器等。 以上是四层五步法的四层，如何去实现上面的四层，做到以下“五步”： 根据组织结构梳理职能域，比如机构／部门的职能，各岗位的工作职责 根据职能域梳理业务元素，包括业务术语、名词解释等 根据业务元素梳理业务活动，如业务流程、业务环节、状态、信息等 根据业务活动梳理业务等内外联系，如业务协作、信息流向 描绘业务架构、信息架构，如用户分类、业务分类、信息分类 四层和五步做到以后，问自己几个问题，看看是否真正的理解需求： 业务对象清楚了没有？系统的用户以及各功能模块的用户是谁是否清楚。 业务流程清楚了没有？各环节的处理人以及处理动作是否清楚。 业务场景清楚了没有？每个需求的业务场景是否弄清楚，所有需求的业务场景是否能连接在一起，在脑海中完整的形成一个故事。 业务事项数量清楚了没有？一共有多少个需求，一共有多少种角色，一共有多少张报表，一共有多少个前置条件…… 跨部门的业务关系清楚了没有？这个部门与那个部门的关系以及产生的哪些业务往来是否清楚。 四层五步五清法都做到以后，你可以把一个需求故事的大纲弄明白，再加上具体细节的需求分析（请查看之前的文章有写如何去分析不同类型的需求），把细节填充在需求故事的大纲里面，一个完整的故事就出来了。","categories":[],"tags":[]},{"title":"目录及资源","slug":"目录及资源","date":"2018-11-30T14:49:37.000Z","updated":"2018-12-29T10:57:45.876Z","comments":true,"path":"2018/11/30/目录及资源/","link":"","permalink":"http://yoursite.com/2018/11/30/目录及资源/","excerpt":"","text":"用户访谈、焦点小组、文化探寻、包括问卷调查等定性、定量研究手段 第2章 需求分析2-1 实战项目定位与需求分析 2-2 从用户需求到功能需求 2-3 KANO模型 2-4 对需求做减法 第3章 功能结构图3-1 功能结构图定义 3-2 功能结构图绘制 第4章 信息架构图4-1 信息架构设计定义 4-2 信息架构设计 第5章 操作流程图5-1 操作流程图定义 5-2 用户场景设计 5-3 短视频拍摄编辑发布操作流程图绘制 5-4 短视频分流程图绘制 5-5 好友管理操作流程图绘制 第6章 产品结构图6-1 动态-产品结构图 6-2 消息中心-产品结构图 6-3 我的-产品结构图 6-4 拍短视频-产品结构图4 6-5 产品结构图查漏补缺 第7章 页面交互图7-1 页面交互图-上 7-2 页面交互图-下 第8章 产品原型8-1 好友-动态列表原型设计 8-2 附近-动态列表原型设计 8-3 短视频详情原型设计 8-4 附近-短视频详情原型设计 8-5 发布用户空间原型设计 8-6 加好友原型设计 8-7 拍摄短视频原型设计 8-8 编辑与发布短视频原型设计 8-9 拍摄短视频子页面原型绘制 8-10 编辑短视频子页面原型绘制 8-11 消息中心原型绘制 8-13 个人中心原型绘制 8-14 控件原型绘制(一) 8-16 原型页面交互图绘制 第9章 页面流程图9-1 短视频拍摄发布-页面流程 9-3 好友管理-页面流程 第10章 交互说明文档10-1 交互文档说明 10-2 项目基本说明 10-3 常用控件 10-4 网络异常 10-5 加载机制 10-6 缓存机制 10-7 手势操作 10-8 屏幕旋转与中断机制 10-9 声音控制与信息显示 10-10 原型交互说明（1 第11章 演示原型11-1 交互演示原型定义 11-2 进度条的分段 11-3 进度条的控制 11-4 进度条的删除 11-5 特效编辑交互处理","categories":[],"tags":[]},{"title":"Hackathon@华东 活动记录及反思","slug":"华东hackathon","date":"2018-11-19T14:49:37.000Z","updated":"2018-12-24T09:06:01.087Z","comments":true,"path":"2018/11/19/华东hackathon/","link":"","permalink":"http://yoursite.com/2018/11/19/华东hackathon/","excerpt":"","text":"###","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"2018微软学生夏令营记录","slug":"2018微软学生夏令营","date":"2018-08-28T14:49:37.000Z","updated":"2018-12-27T05:05:53.994Z","comments":true,"path":"2018/08/28/2018微软学生夏令营/","link":"","permalink":"http://yoursite.com/2018/08/28/2018微软学生夏令营/","excerpt":"","text":"微信图床日常不行原文首发于公众号 ： SUMSTC分为三篇：2018微软学生夏令营纪行 丨 开营日2018微软学生夏令营纪行 丨 Hackathon A & Tech Salon2018微软学生夏令营纪行 丨 Hackathon B-天马行空 ”远远地，透过高耸的行道树看到熟悉而又陌生的田牌Logo出现在视线尽头，稀稀疏疏的阳光透过窸窸窣窣的树叶打在锃亮的玻璃幕墙上。旅途的劳累瞬间褪去，拎包的手微微出汗，以往高高在上的“Microsoft”从未像现在这样触手可及。“ 第一日 开营开营前19号12点和dwx主席在南京南会面，简单地吃了顿M记后登上了前往帝都的G12次复兴号高铁。 三小时后便踏上了帝都的土地。这次夏令营的从20号到24号，为期五天。由于某些不可抗力因素，如果要和主席一同报到的话就必须提前一天到北京，得益于此，我们也获得了一天游览的时间。我们走马观花式地玩了一圈，吃了老北京卤煮，体验了后海那略带淡淡腥气的风，看了圆明园及大水法等遗址，唯一有些遗憾的便是天安门正在整修无法一窥其全貌，由此体验到帝都打车的艰辛和地铁高昂的票价。英短游客照 报道和入住20号下午13：00到达酒店，报到，入住。领取物资，依旧是老三样：信仰T恤，信仰水杯，信仰背包。这届夏令营的主题是“创动天地，绿动WE来”（似乎哪里不太对劲 （T恤颇有Supreme的风范） 关于房间：与去年只有寥寥无几的几套二层复式相比，今年有几乎一半的同学都入住了复式（微软爸爸真有钱啊嘤嘤嘤）。 （二层复式房间 体验极佳） 晚饭则让我有些意外，汉堡王双享堡+中可+中薯，反正我是没吃饱…. （晚饭） Launching Ceremony这里我真的要狠狠吐槽下去年的同学们：按照 贝贝姐的说法，去年的同学嫌弃报到当晚的kick off过于欢脱，没有coding的环节；所以今年直接开门见山，当晚就进行硬核coding。唉，第一晚就要爆肝，本是同根生相煎何太急啊！ 回到正题，下午六点我们出发前往丹棱街5号—微软亚太研发集团。盛夏的傍晚有些闷热,路上尘土飞扬，再加上拥堵的交通，让人心生烦闷。远远地，透过高耸的行道树看到熟悉而又陌生的田牌Logo出现在视线尽头，稀稀疏疏的阳光透过窸窸窣窣的树叶打在锃亮的玻璃幕墙上。旅途的劳累瞬间褪去，拎包的手微微出汗，以往高高在上的“Microsoft”从未像现在这样触手可及。（微软亚太研发集团总部） 欢迎仪式上，首先由学术合作部总监Xin Ma女士做了开幕演讲，向此次夏令营的组织者表示了谢意，回顾了18年来俱乐部的初创与壮大，最后引用习主席语录给我们提了四点要求：志存高远，德才并重， 情理兼修 ，勇于开拓。 （会场） （满屏幕的求生欲） Hackathon ALaunching Ceremony 后，Hackathon Series Part A 正式开始。 首先由《编程之美》和《构建之法》的作者邹欣老师向我们介绍了黄金点游戏：简单来说就是参与者提交规定区间内的2个数字，最接近均值*0.618（称为G值）的得分。邹老师继续引导我们深入思考下去，由此引出了博弈论及其相关应用，并邀请到亚研院高级研究员Tao Qin给我们作了博弈论和相关AI的讲座指导。黄金点游戏AI详解 开发这次的Hackathon其实非常之有趣，不仅仅考察各位选手的算法能力，更包含了竞争与博弈，每个组都不是单独作战。选手们可以合理地利用规则扰乱G值，干扰他人的算法，同时使自己的输出更靠近G值。关于方向，主要有以下3个： 1、数学方法：线性回归，均值,最小二乘法等 2、AI相关：SVM，DNN,ANN等 3、搞事：ummm 大家的算法基本都至少涉及到了一个方向或多方向并用。 我们组并未直接进入开发，而是提出了数个可行方案，经过讨论后，最终决定使用SVM作为主要方向进行开发。 讨论中 深夜爆肝 深夜的亚研院仍灯火通明 Runtime时间来到8月21日，早饭后直接开始TEST。 第一轮test,部分组在基本输入输出上出了问题导致无output。运行了200轮后，得分和黄金点分布如下；可以看出，最后黄金点基本维持在一个很小的区间内震荡，大家也都很老实，没有搞事情，除了第12组，也正是只有一个组在搞事，所以对整体影响并不大，最后反而搬起石头砸了自己的脚。 第一轮后各组得分与黄金点分布 第一轮跑完后，邹老师给了我们一小时修改，之后又进行了第二轮test。运行了400轮后，得分和黄金点分布如下。在经历了第一轮的混沌后，Group14表现优异，一骑绝尘拿到第一。根据采访，他们在提交值中加入了干扰项，用来干扰其他队伍AI的判断。除Group14外，也有其他若干组采用了相同的策略，所以相比第一轮，最后G值震荡的区间相当大。但他们在搞事的同时，却也使自己远离了G值，Group14考虑到了这一弊端并制定了相应策略，这正是Group14取得优势的原因。 第一轮后各组得分与黄金点分布 第一名Group14 奖品为2018世界人工智能大会门票另包食宿 Tech SalonAI For Good下午两点，微软亚研院政府事务总监 Geroge Liu为我们带来了主题演讲 ：AI for Good —科技的社会影响。首先为我们介绍了微软的创新文化 ，强调不断创新是唯一的生存方式唯有开放才能基业长青，保持持久的竞争力。 接着通过四个例子说明科技与公益相结合的价值所在。在他精彩的演讲中，有一句话让我印象特别深刻：“科技的力量不在于科技本身，而在于用科技成就怎样的不凡“。微软一直在微力笃行，科技赋能：从阳光校餐数据平台到帮助盲人看世界的Seeing AI,从利用认知服务帮助找回走失儿童到利用Azure为盲人免费提供有声读物，微软其实一直在激发有益于社会的创新，努力解决传统方式需要花费大量人力物力甚至无法解决的问题，用创新的工具来促进公益事业跳跃式地发展。一家科技公司不仅在技术上领先世界，更承担了大量的社会责任，我想这就是为什么微软能够被广大网友喜爱甚至成为一家伟大公司的原因。介绍利用认知服务帮助找回走失儿童 微软的使命 微软小冰Tea Break后，Richard Li —微软小冰资深PM为我们介绍了她最新的技术进展。微软小冰已经成为世界上最大的对话式人工智能系统之一，拥有6.6亿人类用户,平均每用户对话轮数达到了23，拥有57种直接用户场景。小冰还参与了25个电视台和28个电台的节目制作，产出了长达2878小时的内容，并形成包括文字，语音和融合内容的内容产出矩阵。 小冰内容产出流程 小冰参与制作的及节目 不久前，微软刚刚举行了第六代小冰的发布会，发布了小冰的全新3D形象。Richard Li 特别向我们介绍了小冰最新的基于DNN的歌唱系统。团队开发出了突破瓶颈的第四版歌唱系统，开始博采融汇各家所长，能够学习样本更多的细节甚至包括多变的与吐字相互联系的呼吸声和吐气声 ，更加接近人类的真实声线，甚至可以把一首歌唱出各种不同的风格。 小冰在声线和技巧方面的提高 歌唱系统的版本迭代 ###$ 关于饮食我只想说：我们可能被微软养成了猪。 田牌盒饭 大厦内的自助餐厅 信仰牌饼干 Hackathon B技术指导在进入开发前，来自微软亚研院云计算与人工智能事业部的首席项目经理叶海顺博士和创新孵化总监陈彪为我们进行了先期技术指导。其间详细介绍了微软Azure提供的微软认知服务与VS/VS Code的深度学习扩展框架—Tools For AI。 （叶博士利用认知服务演示Demo-识别出普京，主席正在合影） （应用微软云服务的合作伙伴） 开发与Hackathon A不同，Part A给了详细的方向，我们只需要考虑具体的算法实现。而Part B环节更需要良好的创意与合适的技术相结合才能获得较好的成绩。Part B要求必须至少使用微软认知服务和Tools For AI中任意一项，兼用则有另外加分。 （Mentor正在与我们交流创意并给予指导） （大家正在开发） 我们组经过两个小时的头脑风暴，提出了数个可行方案，最后决定利用Custom Vision和Tools For AI 制作一个全民参与有关物种识别的小程序，另一方面可以让科学家和环保主义者利用上传的物种和位置信息预防物种损失。 Presentation展示环节。一共23个项目，覆盖面极广，从海洋污染治理到智能农业，从智能教育到益智游戏，展现了同学天马行空的想象力。而且能在24小时内能够了解和利用相关技术是很了不起的，评委们给予了充分的肯定与褒奖。 （翻车现场） （项目展示） 但是，在展示环节，有很多组没有控制好既定的时间，往往因为超时不能向评委展示充分展示项目的亮点。大家只有 7分钟的时间来展示，需要注意时间的利用，要关注如何去说服大家，而不是堆砌大量的PPT。另外，评委们还指出大多数同学都是从技术来找应用，只关注技术应用其本身不仅限制了创意的空间，而且失去了一个深入了解AI与认知服务的机会。 最后力压群雄，拿到第一的是“近海小型垃圾漂浮物检测与处理系统”，该项目旨在通过利用认知服务和Tools For AI检测近海垃圾并作出相应处理。 （颁奖） 结语 图文：Tao编辑：Sherly 首发于微信公众号：SUMSTC 苏州大学微软学生俱乐部","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"设计规范 与 资源","slug":"设计规范","date":"2017-11-21T14:49:37.000Z","updated":"2018-12-24T13:07:49.689Z","comments":true,"path":"2017/11/21/设计规范/","link":"","permalink":"http://yoursite.com/2017/11/21/设计规范/","excerpt":"","text":"官方文档https://www.material.io/ MDhttps://developer.apple.com/design/human-interface-guidelines/ Apple Human Interface Guidelineshttps://ant.design/index-cn 蚂蚁金服团队 碎碎念dp sp px 的爱恨情仇https://www.ui.cn/detail/162029.html https://www.jianshu.com/p/1b406a643ad2 iOS与Android移动端设计对比 https://www.ui.cn/detail/192444.html 一稿完美适配Android/iOS及无线视觉规范http://www.shejidaren.com/examples/tools/chichun/ui-design-spec.html Android & iOS设计尺寸规范 资源http://www.niudana.com/ NIUDANA设计导航 http://so.uigreat.com/ UI设计导航 https://idesign.qq.com/#!index/feed 腾讯CDC导航 有RSS订阅 http://hao.shejidaren.com/ 设计导航 https://hao.uisdc.com/ 优设设计导航 http://www.46design.com/ 46设计导航","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"一些照片","slug":"一些照片","date":"2016-12-31T18:49:37.000Z","updated":"2019-04-13T15:12:33.783Z","comments":true,"path":"2017/01/01/一些照片/","link":"","permalink":"http://yoursite.com/2017/01/01/一些照片/","excerpt":"","text":"","categories":[],"tags":[]},{"title":"测试文章","slug":"测试文章","date":"2016-12-01T14:49:37.000Z","updated":"2018-12-20T08:18:08.798Z","comments":true,"path":"2016/12/01/测试文章/","link":"","permalink":"http://yoursite.com/2016/12/01/测试文章/","excerpt":"","text":"踩过的坑1.hexo clean，这个慎用2.重启3.删除node_modules， 再 npm install4.注意加空格 骚操作自定义网页首先新建库，把写好的网页传上去，再开启Github Pages,那么这个网页的路径就是username.github.io/新建库然后就是关键，在相应需要连接处，把URL改成/新建库，再编译上传即可。注意，在本地预览是不能看到的，因为local并不存在/新建库这个路径，但是上传到github上后，这个路径就是可以访问的了。所以，也可以直接在原来的pages里新建，理论上是没有限制的（笑。","categories":[],"tags":[{"name":"test2","slug":"test2","permalink":"http://yoursite.com/tags/test2/"},{"name":"test","slug":"test","permalink":"http://yoursite.com/tags/test/"}]},{"title":"Hello World","slug":"hello-world","date":"1979-12-01T14:49:37.000Z","updated":"2018-12-18T12:28:34.078Z","comments":true,"path":"1979/12/01/hello-world/","link":"","permalink":"http://yoursite.com/1979/12/01/hello-world/","excerpt":"","text":"Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post1$ hexo new \"My New Post\" More info: Writing Run server1$ hexo server More info: Server Generate static files1$ hexo generate More info: Generating Deploy to remote sites1$ hexo deploy More info: Deployment","categories":[],"tags":[]}]}