辑导语:B端产品需要重视用户体验,因为这直接影响到了B端人员的工作效率,对软件后续的合作也有重大的影响。本篇文章以作者本人亲历的实际项目进行推演复盘,总结绘制B端产品用户体验地图的一般流程与特点。希望对你有所帮助。
2021年在创业公司参与了公司一个核心项目——某省会级国家电网生产调度综合大楼数字孪生智慧楼宇1~2迭代阶段研发项目。
本人在团队内负责产品部分,主要工作内容包括需求对接、用户分析、交互定义、数据整理、原型输出等(因初创公司体量有限,产品+交互二合一也就见怪不怪了),同时也参与视觉评审、项目解说(毕竟自己挖的坑要自己填)。
项目概述:该项目是基于数字孪生技术三维可视化的智慧楼宇系统,包括:
【PS:百度百科对数字孪生的定义如下:“数字孪生是充分利用物理模型、传感器更新、运行历史等数据,集成多学科、多物理量、多尺度、多概率的仿真过程,在虚拟空间中完成映射,从而反映相对应的实体装备的全生命周期过程。数字孪生是一种超越现实的概念,可以被视为一个或多个重要的、彼此依赖的装备系统的数字映射系统。” 数字孪生对各个行业的赋能不同,由于本人自身水平有限,故不过多讨论数字孪生概念,请各位感兴趣的朋友自行查阅相关资料进入深入了解 】
在我们的实际项目中可以简单理解为在电子化办公的基础上加入三维可视化场景,例如:
在这里更多的想探讨总结如何利用“用户体验地图”这一设计方法论为B端产品进行切实有效的赋能。
在此之前,先大致总结“用户体验地图”与“B端产品”各自的特性,以及在此基础上如何在B端产品中利用这一方法论为设计工作增值,最后以本人亲历的实际项目进行推演复盘,总结绘制B端产品用户体验地图的一般流程与特点。
B端,代表企业用户商家,英文是Business,是互联网产品中的商家界面(即:管理平台)。用户通过它进行日常的商业活动,例如企业库存管理,销售统计,员工出勤考核等等。可以说,用来解决企业需求的产品,都是 B 端产品。
以上定义来自百度百科。
关于对B端的定义,各种网站论坛的帖子数不胜数,这里不做评判该定义的边界范围及对错,个人认为由于B端产品在不同行业、不同业务场景、不同客户需求以及不同产品形态之间所表现出的差异不同,故每个人对B端产品都有自己的认识。
借用文学大佬莎士比亚的话来说“一千个读者眼中就会有一千个哈姆雷特。”
就当前项目而言,本人对B端产品特性的通俗认识如下:
为产品买单的甲方不是产品的直接使用者而是管理层或领导层。公司当前项目甲方是某省级国网单位后勤公司,而产品的核心用户是基层班组及各组运维人员,二级用户是中层管理者,例如各部门主任、办公室主任等。
对于领导层而言,基本不会直接使用产品,他们关注的更多是产品上线后,节省了多少人力运维成本、提高了多少设备安全指数以及如何将事故损失降到最低值等…
对于产品需求需要深入甲方公司/团队/组织工作环境面向产品未来的直接使用者进行调研;双方达成合作共识之后,仅根据甲方领导层/决策层对于解决方案的预期与建议(当中可能包括某些隐晦的需求表述)是远远不够的。
个人认为,该类B端产品的特点在于专业领域的深度较深,往往需要巨大的学习成本,这里的学习成本指的是对特定行业/领域的认识和了解以及对客户现有业务流程的熟悉程度。
就该项目而言,当前产品模块主要是电力系统的监测与运维,对于产品人员而言需要深入基层的业务环境中去调研需求,调研之前需提前对业务场景、工作环境有一个大致的了解与认识。
例如,对于电力系统而言,产品人员需要首先了解高压/低压、变压器机组、三相电流/电压、能耗、功率等基本概念,而后根据实际需要,进行“用户访谈”、“实地调研”。
如果条件允许(开发周期、项目预算等)的话,研究人员最好可以驻场调研,实地体验运维人员的工作环境、任务流程、设备养护操作流程。
驻场调研期间,在与运维人员的沟通中可以发现更多有价值的信息。设计优劣之处自安于对细节的把控程度,正所谓当局者迷旁观者清,当产品人员在观察运维人员的动作习惯、操作细节时往往能发现很多可以优化并且值得优化的地方,而这也正是用户在描述当前工作流所存在的问题时最容易被忽略的地方。
正如福特汽车创始人-亨利福特所说:“如果听用户的,我们根本造不出汽车,用户只需要一匹快马。”
如果客户只是认为日常设备运维这一重复性动作繁琐且枯燥,我们可能只会进一步简化流程,例如从一天巡检两次优化到一天巡检一次、每隔4小时巡检优化为每隔6小时巡检、纸质签到优化为电子签到…
但是在驻场调研过程中我们发现,日常运维的根本目标是对设备实时运行状态进行监测,确保整栋楼内所有变压器机组、配电箱运行状态正常,这里我们提炼的关键词为“所有”、“实时状态”。
由此得出客户真实需求是对所有设备7*24小时运行状态的不间断检测,为解决这一问题,可以将运维人员工作范围内的所有设备安置智能传感器,通过数据传输将所有设备运行状态,实时参数等进行可视化显示,发生故障/险情时第一时间通知相关班组负责人。如此一来,既节约人力成本,又提高运维效率。
产品解决方案应尽可能满足甲方各类用户群组的需求,因为面对同一产品,不同用户群组的关注点不同。
该项目的用户群组分为三类,分别是决策层、管理层、执行层。
决策层包括国网后勤总经理、副总经理,管理层包括部门主任、办公室主任、运维班组负责人,执行层包括各班组成员。其中执行层可以归纳为产品的核心用户(高频用户),管理层成员为二级用户。
不同群组用户对产品的需求和关注点有较大差别。
决策层(相关用户)虽然对产品的使用频率较低,但其关注点在于周期性宏观把控,例如楼宇生命健康度的周期性变化、如何优化组织架构、宏观的数据分析、投入产出比等全局问题。
管理层用户关注点在于如何有效降低安全隐患、对于安全事故如何提高响应速度、各班组之间如何高效协作的问题。
执行层用户为一线工作人员,对于产品本身没有过多的话语权,但却是最能发掘用户真实需求的一组群体,从他们的实际工作流程、工作环境中可以观察到当前工作流值得优化的地方。同时他们所反映的一些情况,也是最真实、最直观的问题,对产品人员提炼用户需求有极大的帮助。在进行产品调研、构建产品逻辑架构时,应从不同用户群体出发,听取不同用户群体的声音,综合分析后得出最优解决方案。
B端产品的最终目的是解决问题,产品的核心功能可能不止一个,且各功能间相对独立,不同功能涉及不同的业务场景,其对应的设计思路也不尽相同。
该项目为国网生产调度大楼智慧后勤平台,其核心的功能应该是与电力系统密切相关,例如电气火灾监测、设备运行状态监测等,但从“后勤”的角度出发,却远不止楼宇电力系统,正所谓“水火不相容”,楼宇内部密集分布了上百个精密仪器,与之伴随的就是上百条回路信息,而回路运行过程中最危险的情况之一就是由楼内漏水引发的短路对用电设备造成的巨大损失。
而楼宇水系统(包括但不限于给排水管道、空调水管道、消防水管道等)与电力系统基本毫无关联(不可否认的是供水设备需要电力供给),但在后勤系统中确是不可忽视的一个子系统。
如果说水系统与电系统是相对独立且平行的两个子系统,那么用电设备运行状态与电力能效则可以理解为二者呈线性因果关系。
在用电设备安全运行的前提下所必须考虑的是能效的高低,能效包括用电能耗、用电负荷、同期增长率、电能质量等多个参数,这些参数又可以做进一步细分。
例如用电能耗可分按“峰平谷”用电时段分为细分或按照设备类型进行分类能耗分析,电能质量可以分为电流质量和电压质量,而电能质量问题又是由频率偏差、电压偏差、三相不平衡、谐波畸变等多个参数异常引起。
所以电能质量作为衡量能效的重要指标,虽然与“电气设备安全”同属电力系统,但二者业务场景及数据信息大相径庭,再加之政策影响:“中国承诺在2030年碳达峰,2060年碳中和”,以国企、央企为代表的的大批企业开始关注能效比(能效比即能源转换效率之比)或能源产出率(单位能源产出情况,该指数越大表面能源利用效率越高)。
由此可见,能效监测更多涉及到的用电设备的实时数据或高阶数据分析,与用电设备运行状态监测的相同之处仅在于目标对象一致,但各自模块背后的业务场景相对独立,用电设备运行状态是对变压器机组运行状态、回路状态以及用电设备运行状态进行监测,而能效监测则是对该类目标设备用能进行数据统计、数据分析以及数据预测等。
综上所述,对于国网智慧后勤项目而言,用户的核心诉求表现是多方面的,且各方之间相对独立,不存在明显的需求优先级之分。故我们在进行产品策划与设计时,需要深入了解各业务场景,以及业务场景背后的逻辑或影响因素以及不同业务场景的具体表现形式(抽象到具象or二维到三维or复杂到简单)。
由于所在领域、业务场景、用户群体、项目预算不同,B端产品竞争壁垒较高,竞品分析具有一定局限性,在不了解相关竞品的具体业务场景与用户需求的条件下盲目的做竞品分析,最终收益会微乎其微。
竞品分析是我们在进行产品设计时最常用到的一种产品分析方法。由于本人工作经验有限,对于B端产品的竞品分析方法论尚未有全面系统的实践经历,目前仅结合当前工作经验和相关文档信息对B端产品的竞品分析存在的局限性做以下概括(以下信息参考自“两只猫爸”署名文章“B端产品如何做竞品分析?”。文章链接:http://www.woshipm.com/evaluating/4250256.html。感兴趣的同学可自行查阅):
(1)B端产品的个性特征多于共性特征
因为B端产品多是公司企业根据自身组织特征、业务场景、地域特征、收益情况而深度定制的解决方案,同类产品的个性特征明显大于共性特征,同时还与产品研发团队自身水平相关。
正因为“世界上没有两片完全相同的树叶”。所以我们在定义对标产品或选择相关竞品时,不能刻板地、按部就班地对竞品的功能定义、视觉风格、交互逻辑进行评判。
该设计对于这一场景是好的设计,可能并不适用于当前场景。
(2)产品相关的有效信息匮乏
由于B端产品多面向企业组织,产品使用群体有限,仅为企业内部人员。
且B端产品的主要壁垒之一在于其价格昂贵,交付形式为一对一全流程交付(开发团队交付至甲方内部并提供一定的培训课程和技术支持,全程对第三方及以外人员进行保密)。
当我们想了解竞品相关信息时,可搜集到的信息有限,其中具有参考价值的信息更是少之又少,因此成为影响B端产品分析的重要因素。
(3)行业壁垒
因为B端产品作用于各行各业(传统制造业、医疗、教育、餐饮等),其行业特点各不相同,某些行业的行业门槛较高,例如电力行业、医疗行业等。
这就要求产品研究人员在进行竞品分析前需要具备相关行业的基础知识,而这些行业知识是需要大量的时间成本去学习,无形之中提高了产品的开发成本和开发难度。
(4)由于产品的买单者和使用者通常属于领导与被领导的关系,二者之间的需求在一定程度上可能会相互冲突
在产品设计时要尽量规避这类冲突,尽可能平衡二者需求。
如上文所说,对于该类产品而言,一个产品的不同用户群体的关注点与用户需求不同,而这些来自不同用户群体的用户需求会有一定的矛盾性。
例如从决策层出发,此类用户群体想借助该产品尽可能的实现“智慧后勤”,他们对智慧后勤的期望不仅局限于提高效率,降低成本,更希望可以借助该产品提高可量化的安全保障(稍微夸张一点的说,为满足甲方需求提高促单率,显示产品的可靠性与安全性,向决策层领导保证安全事故的最小损失范围与最快响应速度,且与律所等仲裁机构达成一致,若产品未达到对应水平可加倍赔付或有乙方承担相关法律责任)。
但根据执行层一线运维人员所反应的业务场景得知,此类数据难以量化或无法量化(也可能运维人员出于责任归属问题考虑,不愿为设备安全运行划定具体的阈值范围,毕竟安全事故事后问责要承担相关法律责任,基层运维人员出于自身角度考虑不愿为此担责或自身专业水平有限,无法为此提供有效信息)。
运维人员更多反应的是提高个人效率方面的诉求。此时,决策层所关注的可量化的安全保障这一需求,需要执行层运维人员提供真实有效的数据支持,但运维人员无法提供数据支持,且运维人员关注点在于提升运维效率。
如何平衡两类需求的矛盾也是B端产品设计时需要特别注意的一个方面。毕竟要同时兼顾多用户群组的用户需求,不仅要满足产品直接使用者(执行层运维人员)的需求,也要兼顾最终为产品买单的决策层(总经理/副总经理)对产品的期望和诉求。
我个人对于用户体验地图(Customer journey map, CJM)的理解是将自己(产品设计人员)带入用户的工作环境中并以上帝视角不带任何感情色彩的体验用户真实的工作流程,观察并记录用户的每一步动作直至该流程结束。
绘制用户体验地图可以简单理解为以上帝视角看故事并真实还原的过程,并最终将所看到的故事演绎到合适的载体中。
用户体验地图通常由以下几部分组成:人物特征、阶段、目标、行为、接触点、想法感受、情绪曲线、痛点(爽点)。
这里我借用记叙文写作五要素:时间、地点、人物、事件、结果来概括用户体验地图方法论。
用户体验地图示例
(1)时间即用户体验地图的时间线(阶段)
根据爱因斯坦相对论所说,我们生活所面对的三维空间再加上时间构成所谓四维空间。
三维空间是静止不动的,不能构成完完整的故事情节,是影视动画中所谓的静帧。虽然静帧也可以极具表现力,但是不能构成一个完整的故事。
在用户体验地图中,时间作为第一要素,时间线贯穿了用户体验过程的始终,是我们分析用户体验的线性依据。
以网上订餐为例,订餐过程可以分为以下几个阶段,分别是:
整个流程中,用户故事是线性展开的,时间是整个故事分步进行的基本依据和参考。
(2)地点是一个故事(用户体验地图)中的客观因素
依然拿订餐举例,用户周围的环境特征会影响订单成交率,用户所处的位置周边有多少商家提供外卖服务、饭菜种类是否齐全、商家出餐时间、饭菜质量、配送时间以及是否免配送费等一系列客观因素都会影响用户故事的走向。
言归正传,产品设计人员在以上帝视角体验用户工作流的时候,应该提前了解业务场景或故事环境。以便理解用户动作的前因后果,防止片面孤立的看一副静帧图像。
(3)人物是整个故事中除时间之外的第二个贯穿始终的元素(人物特征)
人物是推动故事发展的主观因素。什么人做了什么事,带来了怎样的结果和影响,这个过程中又发生了什么意想不到的情况…
还是以订餐为例,用户故事走向客观上收到环境因素影响,主观上收订餐用户的人物特征(年龄、职业、收入、消费观念、口味偏好、文化程度等)影响,比如在校大学生与职场人士的订餐时间会略有不同,职场人士一般订餐集中在中午,在校大学生可能会集中在晚上。学生群体可能更加关注优惠力度,高收入职场人士可能偏向于菜品质量等。
相同的客观条件下,不同的主观意向也会带来不同的故事走向。用户在一定范围内(客观限制)内具有比较灵活的选择或想法,所有这些都是以人物为载体去表现。
“以人为本”的设计,说的正是以人为主体,优化体验过程,也印证了人在用户体验地图中的主体作用。
在叙述用户故事时,要先将各个用户的故事背景区别开来,不同的人物有不同的剧情。区别“人物背景”这一操作对应在用户体验地图中就是创建用户模型。用户模型应该是具有代表性的、容易引起大众共鸣的且符合故事背景的,而不是个性的、特立独行的。
(4)事件就是剧情(行为与触点)
一个剧本,确定好时间、地点、人物之后,就可以开始写剧情了。
还是以订餐为例,在订餐过程中你进到一家感觉还不错的店里,你会联系商家确认菜品口味或菜品多少,但由于店家回复消息特别慢导致你失去耐心选择了另一家。
又或者当你下单之后从店家处得知好评返现活动,你在用餐之后感觉饭菜口味符合预期并积极参与互动领取返现或平台积分,增加了对卖家或订餐平台的好感度,促使你下一次订餐优先考虑该商家,从而逐渐商家成为稳定的客源之一。
在绘制用户体验地图时,对于故事的内容要尽可能的细致,“细节决定成败”说的没错,用户对产品体验的感受往往藏在细节里(例如平台积分、服务评价等活动),而这些细节往往就是用户自身难以表达的痛点,痛点的背后就是需求,需求就是产品功能的来源。
所以在叙述事件(用户体验流程)时,做到“事无巨细”总是好的。
(5)结果是人物动作的反馈
在用户体验地图中,我倾向于将“结果”理解为用户反馈(想法、情绪曲线、痛点爽点),用户在行径过程中每一个行为动作的反馈都可以理解为是一个“结果”。每个动作的反馈结果串联起来构成用户整个故事(工作流)的心路历程,包括心理变化、对产品的认识、印象以及是否实现自我满足(达成预期目标)。
依旧拿订餐举例,你在产生订餐想法(需求产生)后会选择订餐平台、筛选商家别、比较价格等一系列操作。此时你的同事or同学向你推荐了一款订餐平台,因为该平台会定期向用户发放优惠券。此时你的情绪可能会被调动起来带着又便宜不占王八蛋的想法选择该平台。
但是进入之后你发现该平台商家种类有限,没有你喜欢的商家或菜品,现在你的心态是领了优惠券又没地方花的爆炸心态,在看了几个商家的口碑评价之后,你迈出勇于尝新的第一步,在送达之前心里默念不要迟到不要迟到,尝过之后发现没有翻车是长舒一口气的心里窃喜(捡到宝藏卖家)。
在用户体验地图中,面对一个故事不同阶段中用户的情绪波动曲线,要做到有则改之无则加勉,那些让用户感觉舒适愉悦的反馈要继续做的更好,让用户感觉不爽想吐槽的反馈要努力优化体验细节,抚平用户心理。
“结果”作为最后一个要素,是前面四个要素共同作用的结果。
前面四个要素中任意一个出现问题,都会影响结果的反馈。在前面四个都梳理清晰之后,反馈结果就会自然而然的浮出水面。
产品设计人员根据不同阶段的反馈结果分析产品可以优化改进的地方。当然,优化过程不会是一步到位的,因为影响结果的4个因素中,既有主观因素也有客观因素,二者都不是一成不变的,任何一个出现变化都会影响用户故事的走向。
最后结论:大家在绘制用户体验地图时就想象成初中写作文(当然没有800字的字数要求),文章内容越生动、越细腻,判卷老师就(开发团队和老板)越喜欢(因为越具说服力)。
“对于任何一款产品的用户体验,无论你关注与否,他就在那里。”——非著名UX从业人员沃兹基硕德。
在网上查了很多资料后发现,看到一种呼声还是比较高的,“B端产品重功能、轻体验”、“B端产品的用户体验不是重点”等声音。孰对孰错,在这里不做评判(本人也不具备评判的能力)。
但是不可否认的是任意一款新产品的出现,应该是首先解决了已存在的产品所不能解决的问题。但是随着中(hu)国(xiang)速(mo)度(fang)越来越快,你的用户群体可能会被别的同类产品挖墙脚,挖墙脚的原因有两个:
总结下来就是“人无我有,人有我优”,否则就不能怪用户喜新厌旧(用户都是渣男渣女,产品人员默默流泪)。
“人无我有”的重点在于产品功能的创新,“人有我优”的重点在于用户体验的创新,这么说应该还是容易被理解的。
对于创新类产品(市面没有的产品或功能),只要做到人无我有就算成功,毕竟是第一个吃螃蟹的人。但是在市场中同类产品或功能>1的条件下,“人有我优”的重要性显而易见。
对于创新类产品在这里不做讨论,毕竟第一个吃螃蟹的都是少数人,况且用户体验是一个“人有我优”的过程。那在这个过程中,用户体验的好坏,很大程度上影响了用户忠诚度。
“你做的不好,就不要怪被人做的好”。从这个角度看的话,无论对B端产品还是C端产品,用户体验都对用户留存产生重要影响。
我认为二者区别在于:B端的用户体验建立在解决客观问题、提高工作效率的基础上,C端的用户体验是建立在满足大众需求和帮助用户实现自我价值的基础上。
二者的作用基础不同,研究人员也就没有必要从产品属性的角度对用户体验做“即决高下,也决生死”的判定…
如果B端产品的用户体验是建立在伪需求或理想需求的基础上,不要说用户体验了,就连交付都过不了就被甲方一顿喷,做的再花里胡哨也没有用。
但是人的欲望是满足不了的,基本需求被满足后会进行“需求升级”,从产品功能的“能用”到“好用”,从“一尺宽”到“ 万丈宽”(需求升级的过程可能是甲方自知自觉的,也可能后知后觉的,还可能是产品人员自我反省的结果)。
在这个过程中,如果是纯粹的新功能的产生,对应的是新需求(说明产品团队前期需求的挖掘广度不够),如果是在已有功能上的迭代升级或拓展,可以理解为就是优化用户体验的过程(前期需求挖掘的深度不足)。
无论是对新需求的挖掘还是对现有功能的优化,“用户体验地图”是一个都是一个不错的选择。
本人查了很多资料,也看了很多产品大佬关于用户体验地图的文章之后发现,大部分关于用户体验地图的案例分析都是基于C端产品,同理,用户体验也被更多用在讨论C端产品身上,那么用户体验对于B端和C端的价值区别在哪里。
如上文所说,B端的用户体验建立在解决客观问题、提高工作效率的基础上,C端的用户体验是建立在满足大众需求和帮助用户实现自我价值的基础上。
这个结论是通过分析产品定位和产品功能之后得出的。如果我们再向深处分析,市场上无论哪一种产品,其本质都是商业产品,不论是产品团队还是设计团队都服务于商业目标1,产品团队的焦点在于发现商业价值并论证该价值点的真伪,设计团队的焦点是利用设计为商业价值增值。
同样是服务于商业目标,但是B端和C端的受众对象以及实现商业目标的手段却是不一样的,导致用户体验的关注点也不一样。
C端产品服务于个体对象,其商业目标是通过提供某种服务并吸引用户产生消费行为为其买单(充值、下单、订阅等),其本质是吸引用户“花钱”买服务。
B端产品服务于商业公司,其商业目标是通过提供某种服务来提高效率,减少成本(例如各种管理后台),其本质是帮助用户“省钱”,省到就是赚到,B端产品其实是变相的为用户“赚钱”。
这样看来,“用户体验重C端轻B端”也就见怪不怪了。
C端产品吸引用户花钱,为产品提供的服务买单,例如充值VIP享受特权。所以C端产品需要高频迭代,不断优化用户体验,因为用户花钱了,从用户角度出发花钱了就要享受最好的服务。
B端产品帮助客户省钱,省到就是赚到。甲方领导是想花一块的钱办两块的事,无论是为了降低成本还是提高效率,购买某产品就是为了花最少的钱办最大的事。
那为什么B端的用户体验难做呢?根本原因在于“花钱容易赚钱难”。
谁都想花钱,花钱带来的快感多爽啊,何况C端产品有100种让你花钱的方法(就是不断优化用户体验的过程)。
那省钱怎么办呢?最简单的办法就是开源节流。
B端产品其实就是一个省钱的手段,但是问题就在于大家(B端客户)都想省钱,怎么省钱可以最有效并且最舒服(花100省20还是花150省50),这就是B端产品用户体验的价值所在。
即便用户体验差,客户也可以接受,大不了这个省钱的过程不太舒服,省的少一点。但是如果用户体验越好,省钱过程就越舒服,省下的钱也就越多。
所以也就不怪B端产品用户体验总被吐槽,根本原因可能在于甲方的选择。
以财务管理系统为例,假设该系统价值100块,甲方经评估后发现花100块购买该产品后可以减少20块的人力成本,意味着产品的单位价值比是5:1,当系统优化过后,系统总价值变为150块,如果客户购买新系统,则可以减少50块的人力成本,产品的单位价值比是3:1。
同样是节约成本,甲方可能会觉得既然已经实现是花100省20的目标,何必多花50买新系统只为多省30。
从这里不难看出,甲乙双方对于产品价值的计算方式是不同的,在甲方眼中只做差价计算,而忽略了产品的单位价值比。而提升产品单位价值比的过程,恰好就是提升产品用户体验的过程。
以上述项目为例,推演绘制用户体验地图的流程。该项目的用户需求来自于用户访谈、实地观察以及用户反馈。
首先根据利益相关者地图的理论,将用户分为“核心用户”、二级用户和周边用户分别对应为“执行层”、“管理层”、“决策层”。在开始创建用户体验地图之前,先根据用户群体分别创建用户模型。
“智慧后勤”平台的设计指导原则:
基于上述用户模型将分别创建与之对应的用户体验地图,这里以核心用户群体,运维班组负责人为代表进行示例。
由于时间关系,用户体验地图以文本形式进行展示,以1-5表示情绪节点(3表示初始值,向下表示情绪负增长,向上表示正增长)
(1)运维班组负责人的“用户体验地图”
用户任务目标:查看各子系统运行状态和实时参数、向各班组成员派发工单。
通过用户体验地图总结归纳的痛点与机会点,结合用户行为的情绪值,可以对进行需求优先级进行排列,最后根据开发周期、开发成本等因素综合考虑是否进行优化。
用户体验地图的绘制过程确实需要消耗大量时间,并且最好是在有一定数据支撑或用户研究的基础上进行,否则其赋能作用十分有限。
用户体验地图作为产品设计过程中的一个工具,应当注重对产品的思考与逻辑的表达,切忌本末倒置过度注重视觉效果而忽略产品背后的逻辑。
本文由 @第一生瓜蛋子 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议。
达哥拉斯说:万物皆数,万物皆可用整数或分数来表示。
希帕索斯(Hippasus,公元前5世纪)不以为然:一个腰为1的等腰直角三角形的斜边的长度是多少?由此引发了第一次数学危机,自此,几何学强势崛起。
中国人发现计算时需要记忆中间结果很是麻烦,发明了算盘和珠算法,计算的中间结果用不同的算珠的组合来表示。
纳皮尔发现一些大数的乘除实在是太费时间了,发明了对数,化乘除为加减。(1614年)
虽然对数表实现了计算降维,但查阅起来毕竟眼花缭乱,厚厚的书册也不便携带。不多久,一位叫甘特的英国数学家想到:既然对数表是把两个数的求积问题转换为两个对数的求和,那么,如果把一个对数视为一段可以用直尺丈量的长度,对数之和不就可以利用直尺直接量出来了吗?1620年,甘特将对数表刻到一把尺上,借助圆规一类的辅助工具,实现了这种想法。这样的工具被称为计算尺。
施卡德(Wilhelm Schickard)从时钟的齿轮技术获得灵感,建造出世界已知的第一部机械式计算器,这部机械能进行六位数的加减,并经由钟声输出答案,因此又称为「算数钟」。该机器利用11个完整的、6个不完整的链轮进行加法运算,并能借助对数表进行乘除运算。但不幸在即将完成时被毁。(1623年)
1642年,帕斯卡建造了可以实际使用的能做加减的计算器,是一种由齿轮+刻度盘组成的机器。
笛卡尔找到了坐标系这个神器,说:数形是可以合二为一的。(1637年)
莱布尼茨说,我的计算器不仅要能做加减,还要能做乘除。莱布尼茨在加减法计算器的基础上加了一个叫“步进轮”(“Stepped Reckoner”)的装置。
步进轮是一个有9个齿的长圆柱体,9个齿依次分布于圆柱表面;旁边另有个小齿轮可以沿着轴向移动,以便逐次与步进轮啮合。每当小齿轮转动一圈,步进轮可根据它与小齿轮啮合的齿数,分别转动1/10、2/10圈……,直到9/10圈,这样一来,它就能够连续重复地做加减法,在转动手柄的过程中,使这种重复加减转变为乘除运算。(1671年)
同时,莱布尼茨和牛顿两人各自独立地找到了求曲线下面积的一般方法。莱布尼茨说,求面积不过是求和,求面积的变化率不过是求差。求面积与求变化率是两个互逆的过程,这就是微积分。
巴贝奇说,为什么只把蒸汽机用于纺织业,为什么不用它来驱动计算器呢,于是发明了用蒸汽驱动的专用计算用途的差分机(由齿轮、转轮、杠杆、拉杆组合而成)。更进一步,构思了具有通用性的分析机,可以运行包含“条件”、“循环”语句的程序,有寄存器用来存储数据,但成千上万个啮合的十齿齿轮过于复杂,思想太过超前,最后以失败告终。但是,程序存储与控制的思想由此萌芽。(1837年)
布尔说,逻辑学可以和数学相结合,逻辑学的真”与“假”可以用二进制的0和1来表示。用两个字符进行组合便可以表示世间万物,只有有足够的数字位即可,这就是二进制和布尔代数。(1847年)
1854年,George Boole在《An Investigation of the laws of thought,on which are founded the mathematical theories of logic and probabilities》一文中,第一次向人们展示了如何用数学解决逻辑的问题;布尔代数简单得不能再简单了,运算的元素只有两个:1、0;或True、False,基本的运算只有“与”(“and”)、”或”(“or”)、”非”(“not”),全部的运算只用几张真值表就能表达清楚。
图灵(Alan Mathison Turing,1912-1954)头脑大风暴,用一条纸带来存储指令,用一个读写头来读写纸带上的指令并可改写纸带上的数据,这样的机器似乎可以解决自动计算的问题,这就是后人所谓的“图灵机”,存储程序概念与实现呼之欲出。
香农发现真”与“假”、0和1不就是电路系统的“开”与“关”吗,电学中的并联电路和串联电路似乎与布尔代数的逻辑与和逻辑并有点关系,既然逻辑学和数学可以相互结合,再与电学结合一下怎么样,这就是开关电路。(1938)
可以通过开关的组合来构建逻辑门(非门、与门、或门),
通过逻辑门来构建半加器、加法器:
构建记忆电路(循环电路):
计算机中的计算主要包括逻辑运算和算术运算,逻辑运算可以用计算机的门电路很自然地实现,而算术运算则皆可以以加法器为基础:
减法:减法转换为加法,减数用补码表示。
乘法:用加法和移位来计算。
除法:用加/减法和移位来计算。
以一个或多个ALU(或加法器)为核心,加上移位器和存放中间临时结果的寄存器组,在相应逻辑控制下,可实现各种运算
楚泽(Zuse)认为,计算机最重要的部分不一定是计算本身,而是过程和计算结果的传送和储存,同时发现了继电器这种更好的逻辑开关,发明了Z型系列计算机。(1940年代)
1820年,奥斯特发现电流的磁效应。1831年,美国科学家约瑟夫·亨利 (Joseph Henry 1797-1878)制造了一个电磁铁,继而利用磁铁制作了继电器。继电器是在机电式计算机第一个派上用场的电气元件。但电的作用不是作为信号而是电磁感应原理的利用。
阿坦那索夫和贝利找来了真空管作为存储与运算元件发明了ABC计算机(Atanasoff Berry Computer)。(1942)
1903年,弗莱明在真空中加热的电丝(灯丝)前加了一块板极,从而发明了第一只电子管。他把这种装有两个极的电子管称为二极管。电子管的开关特性做为计算机的逻辑部件,开关切换速度当然比继电器来得更快。此时电真正作为信号的功能而存在。
1941年6月,莫齐利拜访了阿坦那索夫并详细向其了解ABC,不久,莫齐利离开厄辛诺前往宾夕法尼亚大学的摩尔学院任教。1941年秋天,他遇到该学院电气工程系毕业的研究生艾克特。两人得到了美国军方的支持,领导开发了Eniac,号称史上第一台可变程序电子计算机。程序虽然可变,但却没有实现程序存储,只能通过开关和连接电缆(插线或插线板)来改变模块计算模块的组合,实现不同的任务。
冯·诺依曼早就认识到了Eniac不够自动,手工摁开关和连接电缆(插线)的工作似乎也可以交给计算机去做,这样的操作不都是对应于电路的通与断来实现模块的不同组合吗?不就是对应一个0和1的指令序列或者一串电信号吗?如果存储到计算机内,再按顺序读出来,然后处理为控制电信号,不就实现了不同模块的自由组合?于是1945年6月写出了长达101页的《关于离散变量自动电子计算机的草案》,提出了程序和数据一样存放在计算机内存储器中,并给出了通用电子计算机的基本架构,后来这些思想被称为存储程序控制概念和“冯·诺依曼结构”。存储程序控制也就是存储程序和程序控制,对应于硬件,也就是要实现存储器(内存)和控制器(由其进行取码、译码、发出控制信号)。存储程序控制概念是计算机理论和实践方面最重要的思想之一,可以理解为“图灵机”的具体实现,现在绝大多数计算机都是存储程序控制概念的实现或“冯·诺依曼结构”。
威尔克斯(Maurice Vincent Wilkes)使用了水银延迟线作存储器,利用穿孔纸带输入和电传打字机输出,领导、设计和制造了EDSAC(Electronic Delay Storage Automatic Calculator,电子延迟存储自动计算机),终于将存储程序控制的思想实验变成了现实。
从此,摁开关和连接电缆的工作由程序员来代替。程序员查阅计算机能够实现的指令集,将解决问题的全过程通过指令集中的指令来做排列组合,这就是程序,是一个0和1的序列,执行时加载到内存的代码区,表示指令时由控制器取指、译码、产生控制信号。指令中描述的数据存储到内存的数据区,按数据的编码规则(如补码、ASCII码等)进行解释。所以,数据和指令都由0、1的组合来表示,都存储到内存,只是做不同的解释而已。
0、1序列直接对应硬件的的两个状态,直接与电信号相对应,所以机器能直接识别,称为机器语言。
用机器语言描述程序的0、1序列,难写、难读、难改。指令集可不可以用一些单词、短语或其缩写来描述,使用名字来指代特定的内存位置,然后再用这些单词、短语或其缩写来编程,最后再翻译成机器语言?这是可行的,而查找、替换的工作也正是计算机所擅长的。用单词、短语或其缩写来描述的指令称为汇编程序,这样的翻译程序称为汇编器,将源程序翻译成机器语言的0、1序列。由此开始了程序控制程序的思想(由程序来翻译或解释另一程序)。
汇编指令与机器直接相关,一一对应,不具有通用性,且汇编指令的抽象程序过低,是否可以将一些常用功能的汇编指令组合用一些关键字、操作符来表示,地址可以用标识符来表示,以实现更高程度的抽象和封装,答案是可以的,这就是高级语言。其翻译程序称为编译器或解释器,由其来翻译由该语言规则编写的程序到机器语言。当然,对应于不同的硬件系统和操作系统(提供最基础功能,更底层的一系列程序),相同的高级语言可以实现不同的编译器或解释器。在实际当中,编译器在内部可能会被分成一个“前端”和多个“后端”。“前端”负责把高级语言的程序转换为中间形式,而“后端”则负责把中间表现形式转换成不同体系结构的汇编指令。这种做法要比使用多个完全不同的编译器更简单。
顺序、分支、循环三种控制结构便是更高程度的抽象,分支、循环的本质也是顺序结构,只不过是不同地址的跳转而已。
1958年,供职于IBM的约翰·巴库斯领导开发了世界上第一个高级语言,FORTRAN。FORTRAN说,科学计算和公式翻译交给我好了。
一些高级语言设计者觉得,区分数据类型是一个不错的选择,数据类型可以选择要求先声明,后使用,也可以选择由编译器来推断,也就是强类型与弱类型的区别,各有优劣。
另外,不同的领域可以设计出不同侧重点的高级语言,自此,各类高级语言百花齐放。
面对复杂性和需求的变动性,高级语言的设计者还面临代码如何组织的问题。
C语言说,一切都是函数。(1972年)
Smalltalk说,一切都是对象,一些数据和操作这些数据的函数因为者关系紧密,需要封装,组织成类与对象的方式。(1980年)
C++说,我是带类的C,我还可以通过模板将函数或类,让其独立于具体数据类型的。我是集成面向过程、面向对象、泛型编程思维的瑞士军刀。(1983年)
面对复杂性和需求的变动性,程序员在构建系统时还总结出来诸多的设计模式。
为了实现代码重用,常用的功能、数据结构、算法实现成了函数库、类库。所以,一个成熟的编程语言,不但具有语言的部分,编译器或解释器的部分,还要集成库、框架,以实现效率、稳定的使用需求。所以编程语言通常包含三部分,一是语言本身,二是库,三是其运行环境,也就是后面要提到的操作系统,而javascript则还有其宿主环境,也就是浏览器,浏览器也是一个应用程序,运行于特定的操作系统之上。
按照冯诺依曼结构,程序需要加载到内存(RAM)才可以被CPU随机访问。RAM是电存储,速度相对硬盘快很很多,但断电则会丢失数据,是否可以既是电存储又可以断电不丢失数据呢?答案是ROM或单片机的烧录或bios固件。程序中的0表示这条熔丝要烧断,1表示这条熔丝不烧,以此方法记录二进制信息,也是相当于逻辑电路的重新组合。程序烧录好后,芯片就有了逻辑功能。包括一次擦写的PROM和可以反复擦写的EPROM。
所以说,逻辑电路的重新组合,可以是硬连接,如Eniac的开关与连接电缆,也可以是软连接,如程序,也可以是处于中间状态的固件,如单片机的烧录或bios固件。也就是说,硬件与软件其实是硬币的两面,有时两者的界限很模糊,相应功能可以用硬件实现,也可以用软件实现。
现代系统越来越多地采用通用硬件(如处理器、内存,以及与外界相连接的接口),同时靠软件来实现特定的行为。人们普遍认为,软件更便宜、更灵活,比硬件更好修改(特别是跟已经出厂的设备比)。例如,如果用一台计算机来控制汽车的动力和刹车,那么防抱死和电子稳定控制显然应该是软件的功能。
硬件和软件一样也需要不断进行更高层次的抽象,并封装抽象。后面提到的集成电路IC、CPU都是其具体体现。
1959年,IBM制造了第一台晶体管计算机7090,使用穿孔卡片。有32K内存,系统用5K,用户用27K,用户数据在内存和一台磁鼓之间切换。计算设备的逻辑部件,从齿轮到继电器是一大进步,电的功能是产生磁,从继电器到电子管是一大进步,电开始作为电信号的功能而存在,但电子管是用玻璃管抽成真空制造而成的,所以又叫真空管,太脆弱了,想微型化很困难,功耗太大,寿命太短,不稳定。晶体管就不同了,是固体的半导体,真空管上述的一些毛病皆可克服。
1947年12月,美国贝尔实验室的肖克利、巴丁和布拉顿组成的研究小组,研制出一种点接触型的锗晶体管,晶体管特别适合用作开关,因为其固体特性。而电子管体积大、功耗大、发热厉害、寿命短、电源利用效率低、结构脆弱而且需要高压电源。
早在1952年,达默早就认识到电子线路中的分立元器件与密密麻麻的连线的不足,如何缩小元件体积,降低成本,也许封装是一种更好的选择。
1958年,供职于德州仪器公司的伊利诺斯大学毕业生杰克·基尔比渐渐形成一个天才的想法:电阻器和电容器(无源元件)可以用与晶体管(有源器件)相同的材料制造。另外,既然所有元器件都可以用同一块材料制造,那么这些部件可以先在同一块材料上就地制造,再相互连接,最终形成完整的电路。9月12日,基尔比研制出世界上第一块锗集成电路(Integrated Circuit, IC)。
1959年7月,另一位科学界和商业界的奇才罗伯特·诺伊斯(Robert Noyce)研究出一种二氧化硅的扩散技术和PN结的隔离技术,并创造性地在氧化膜上制作出铝条连线,使元件和导线合成一体。
封装成组件的集成电路相互之间以及与其它电子元件之间还是需要连接,而早在20世纪初,人们为了简化电子机器的制作,减少电子零件间的配线,降低制作成本等优点,开始钻研以印刷的方式取代配线的方法。三十年间,不断有工程师提出在绝缘的基板上加以金属导体作配线。而最成功的是1925年,美国的Charles Ducas 在绝缘的基板上印刷出线路图案,再以电镀的方式,成功建立导体作配线。直至1936年,奥地利人保罗·爱斯勒(Paul Eisler)在英国发表了箔膜技术,他在一个收音机装置内采用了印刷电路板(printed circuit boards, PCB)。
印刷电路板通过图形电镀,蚀刻出电路,还可以多层高温压制到一起:
PCB 可以大规模生产,无需焊接或用一大堆线。通过蚀刻金属线的方式,把零件连接到一起。
把 PCB 和 IC 结合使用,可以大幅减少独立组件和电线,但做到相同的功能,而且更小,更便宜,更可靠。三赢!在制成最终产品时,其上会安装集成电路、电晶体、二极管、被动元件(如:电阻、电容、连接器等)及其他各种各样的电子零件。借着导线连通,可以形成电子讯号连结及应有机能。自此,告别了传统了分立元件和传统布线。
许多早期 IC 都是把很小的封装成的独立单元,为了实现更复杂的设计,需要全新的制作工艺,于是,光刻登场!1960年,H H Loor和E Castellani发明了光刻工艺。通过多轮光刻,可以掺杂出晶体管,光刻出电阻、电容,蚀刻出细小金属导线,连接不同晶体管。光刻工艺让更微小化的集成电路成为可能。
电脑的输出可以远程做为另一台电脑的输入吗?答案就是局域网或互联网,最初建成的网络就叫做ARPANET。1969 年10 月29 日,ARPANET 上的第一条消息从加州大学洛杉矶分校发出,到达550 公里外的斯坦福大学。这一天可以看成互联网的诞生日。提供输出的称为服务器,接收输出做为输入的称为客户端。通过网线、光纤实现物理连接,通过分层的网络协议规定通信规则,由网络程序实现逻辑连接,如FTP、SMTP、Telnet、HTTP、HTML等:
1971年,全球第一个微处理器4004由Intel公司推出,采用的是MOS工艺,这是一个里程碑式的发明。
1975年,爱德·罗伯兹Ed Roberts设计了Altair 8800,采用Intel 8080处理器。事实上,微软公司的创始人比尔·盖茨和保罗·艾伦发迹,也是始于为Altair 微型计算机编写BASIC 编译器,这个编译器是微软公司的第一个产品。今天,Microsoft Visual Basic 作为BASIC 的一个主要分支,仍然被微软公司积极地维护着。
随着电脑系统的日益复杂化、以及利用电脑速度快的特点而发展出的多任务(多程序)运行方式,靠手工管理这些软、硬件资源显然不现实,唯一的办法就是用程序来管理程序,这就是操作系统,如unix、ninux、windows、ios等,操作系统本身也是许多程序的集成,相互配合完成电脑系统软、硬件的管理,实现电脑系统基础的功能支持。
20世纪50年代初,还没有应用程序与操作系统之分。计算机的能力非常有限,每次只能运行一个程序,这个程序会接管整台机器。而程序员要使用计算机,运行自己的程序,必须事先预约时间段(身份低微的学生只能预约在半夜)。随着计算机变得越来越复杂,再靠非专业人员使用它们效率就会很低。于是,操作计算机的工作就交给了专业操作员。计算机操作员的任务就是把程序输入计算机,然后把计算结果送交相应的程序员。操作系统最初就是为了代替人工操作员完成上述工作才诞生的。硬件不断发展,控制它们的操作系统也日益完善。而随着硬件越来越强大、越来越复杂,就有必要集中更多的资源来控制它们。
操作系统通常都需要管理数十个同时运行的进程或任务。其中有些是由用户启动的程序,但大多数还是一般用户看不到的系统任务。这些进程或任务(程序),要共享同一台电脑的CPU、内存、硬盘和其它输入输出设备,由操作系统统一进行控制和分配。
这些操作系统大都由C或C++来编写,是一个十分复杂的系统工程,如Windows 7 拥有大约1 亿行代码。
操作系统提供了硬件(其功能由驱动程序定义)和其他软件之间的接口。有了这个接口,硬件就好像能听懂人的话了,而程序员编程因此就会变得简单。用这个圈子里的行话说,操作系统提供了一个平台,在这平台上可以构建应用程序。
操作系统为应用程序定义了一组操作(也叫服务),提供不同编程语言的API,比如将数据存储至文件或者从文件中取出数据、建立网络连接、获取键盘输入、报告鼠标移动和按钮点击、绘制屏幕,等等。
1979年,Intel推出5MHz 8088微处理器,之后,IBM基于8088推出全球第一台PC,逐渐地,随着电脑器件的微型化,价格的逐步降低,电脑逐步普及。
最后,通用的数字系统无所不在。在整合多领域技术进步的基础上,数字设备向着小型、廉价和高性能的方向发展。某一领域的技术进步,比如存储密度,经常会影响到所有数字设备。
计算机硬件系统把大型、复杂系统切分成小型、易管理(可独立创建)的组件,软件分层、API、协议和标准莫不如此。
化学有100 多个元素,物理有十几个基本粒子。而数字计算机只有两个元素,0 和1,其他一切都由此衍生出来。比特可用来表示任何信息,从最简单的真假、是否、对错之类的二元选择,到数字、字母,乃至一切事物。复杂的事物比如购物、浏览和手机历史中关于你生活的点点滴滴,则是由简单的数据项组成,后者又可以用更简单的形式来表示,如此往复,直到表示成一个一个的比特。
计算机是操作比特的数字设备。告诉处理器做什么的指令,被编码为比特,而且通常与数据保存在同样的存储器中。改变指令可以改变计算机行为,而这也正是计算机之所以成为通用机器的原因所在。比特的含义取决于上下文,一个人的指令可能是另一个人的数据。虽然有适合处理某种数据的特定技术存在,但复制、加密、压缩、错误检测等等操作全都可以在比特的层面上执行,与比特所表示的事物无关。运行通用操作系统的通用计算机取代各种专用设备的进程还将继续。未来很可能出现根据生物计算原理设计的其他处理器,或许还会出现量子计算机。但是,数字计算机还会伴随我们很长时间。
数字网络中从一个处理器传输到另一个处理器的数据和指令,同样也都是比特。
最后,我们可以简单理解:
1 组合的概念,晶体管组合成逻辑门电路,门电路构建半加器、加法器、记忆电路。上亿个晶体管组合成一个集成电路,完成一个功能,再由数量不等的集成电路、电子元件、PCB板组合成更复杂的功能模块,通过不断抽象、分层、封装,最后组合成一台单机,通过网络组合成局域网、互联网。软件也是如此,由CPU指令抽象(组合)出高级语言的关键字、运算符、控制结构,由这些再构成语句或语句块,再组合成简单的函数或类对象完成一个小功能,不同函数或类组合到一起完成一个较大的功能,再通过接口,实现更大的功能,也是不断的抽象、分层、封装,如windows 7就有上亿行代码,包含众多相互提供接口的程序,构成一个庞大复杂的系统。
2 软硬件的逻辑等价性。
软件是可以转化为硬件的,首先是在操作系统之上的应用软件,这里主要指编译软件,它将高级语言或者汇编语言编译、解释为目标程序,也就是我们所说的机器码,然后机器码被分解为微程序,微程序再分解为微指令,而微指令就是一段定长的二进制数字,再由数字逻辑里的知识被硬件所利用。
程序还可以固化,就是将程序读入只读存储器,做成固件。对于固件,更是模糊了软件和硬件的边界。
晶体管开关的连线组合能完成一定功能(如加法机、记忆电路),就是硬件,而能完成一定功能的软件的指令序列(0、1序列)相当于晶体管开关的重新连线,因而具备了新的功能;复杂的逻辑功能单元都是由简单的逻辑电路搭建而成的,硬件就是逻辑电路的硬连接,软件就是这些逻辑电路的软连接(软件的指令序列也就是0、1序列而已)。
3 了解了Eniac的编程方式是摁开关和连接电缆(插线)来实现功能模块的组合,后续硬件的改进和存储程序控制的方式,都只是对这一手工方式的改进,所以你也可以理解,程序和其二进制的0、1序列都只是为了实现功能模块的自动组合而已,或者说是一种特殊方式的摁开关和连接电缆(插线)。所以说,相同的功能模块,可以用硬件实现,也可能由硬件+软件来实现,只是组合或连接的方式不同而已(硬连接、软连接)。
4 不管是纸带、磁带、键盘、硬盘输入,都是通过一定的技术手段转换为电信号,对应逻辑开关的通、断或高、低电平。加载到内存后,就可以被CPU的控制器取码、译码来产生控制信号,读取数据,执行算术或逻辑运算,输出数据。
ref:
I Brian W·Kernighan《世界是数字的》
II 激动人心的信息技术诞生与成长简史
III 集成电路的光刻法:半导体掺杂(晶体管)与金属层蚀刻(连线)
IV 一张图认识电脑主板(多层PCB印制电路板)的主要制作工艺
-end-
语:需求,大家再熟悉不过了。在产品设计的时候,什么是产品需求?什么是用户需求?什么是商业需求?到底怎么进行产品需求分析?看到这一些列问题你是否一脸懵逼?这是因为你对需求分析和理解的不够透彻。本文作者为大家分享了关于产品设计需求分析研究,希望可以帮助大家做好需求分析,理解需求分析。
在工作中我们经常提及需求,谈及需求分析,但就一个简单的需求,我们真的了解吗?真的知道什么是真正的需求吗?天天被客户说你没有理解我的意思,你没有了解我的需求。
那么什么是需求?百度百科中解释需求指人们在某一特定的时期内在各种可能的价格下愿意并且能够购买某个具体商品的需要。
而关于需求也有人解释为需求是由个体在生理上或心理上感到某种欠缺而力求获得满足的一种内心状态,它是个体进行各种活动的基本动力。
产品是为了满足人们的需求而被生产出来的,因为需求的驱动,才会使得用户需要产品。因此需求,既不是功能,也不是产品,不能把功能和需求混为一谈。需求是用户面临的某一个问题,产品或者产品功能只是为了解决用户需求的解决方案。
产品的需求都有那些类型呢?
需求按照产品属性可以划分为:idea、新增、优化、Bugfix;按照产品职能可以划分为:功能类需求、运营类需求、数据类需求、设计类需求;按照产品价值划分为用户需求和商业需求;按照产品性质划分为显性需求和隐性需求。
马斯洛需求层次理论(hierarchical theory of needs),马斯洛,可以说是我们需求理论界的祖师爷,他认为,人的需要由生理的需要、安全的需要、归属与爱的需要、尊重的需要、自我实现的需要五个等级构成。
下面我们看看产品设计中的应用:生理需求方面应用、安全需求方面应用、社交需求方面应用、尊重需求方面应用和自我实现需求方面应用。
1)生理需求方面应用
生理需求即满足人类的最底层,最基本的生活需求,包括衣、食、住、行、用等。生理需求是推动人类生存的动力,只有生理需求得到满足,人们才会追求更高层次的需求。
比如:唯品会、饿了么、美团外卖、百度地图、WiFi万能钥匙。
2)安全需求方面应用
安全需求即在满足人类的生理需求的情况下,满足人类的安全和社会保障,包括健康、社会秩序、法律、和平、医疗、教育等,人类需要安全感。
比如:支付宝、360、查悦社保、优健康、全民反诈。
3)社交需求方面应用
社交需求即归属与爱的需求,体现在个人渴望得到家庭、团体、朋友、同事的关怀爱护理解,包括友情、爱情、熟人社交和陌生人社交等的社交需要。
比如:微信、Soul、珍爱网、探探、陌陌。
4)尊重需求方面应用
尊重需求即较高级别的需求,满足前几种需求的前提下,用户开始关注高级需求,包括内部尊重和外部尊重。自尊和希望受到别人的尊重。
比如:朋友圈和抖音的点赞、评论,电脑开机助手。
5)自我实现方面应用
自我实现需求即最高级别的需求,实现自己的理想抱负,实现自己的追求,成为伟大的或具有影响力的人物。在人生道路上自我实现的形式是不一样的,每个人都要创造机会去完善自己的能力,满足自我实现的需要。
比如:微博认证、知乎认证、网易云音乐会员、QQ会员、抖音认证
圣经人性七宗罪
圣经人性七宗罪(seven deadly sins),天主教称七罪宗,或称七大罪或七原罪,属于天主教教义中对人类恶行的分类。
最本质的需求是人类原始的本能欲望,在《圣经》中,人类有七宗罪:色欲(lust)、暴食(gluttony)、贪婪(greed)、懒惰(sloth)、愤怒(wrath)、嫉妒(envy)和傲慢(pride)。
一款好的产品,需要对人性做透彻的分析,才能完成其设计。
比如:快播、王者荣耀、拼多多、狼人杀、大众点评。
需求是不变的,变得是满足需求的产品。从古至今,人类的需求几乎没有发生改变,如为了满足人类移动的更快的需求,历史上有马车、自行车、汽车、火车、飞机,互联网的产品则是摩拜单车、哈罗单车、滴滴出行、12306、携程。
传统产品:
互联网产品:
因此,在进行产品设计中一定要把控需求来源,提高需求质量。
聊了这么长的需求,那么需求到底如何进行获取?都有那些渠道和方法呢?看了相关的视频和书籍进行了一定的了解,只要路子野,就不会有悲伤!关于需求也有相关的获取渠道和方式。
需求的获取渠道,包括内部渠道和外部渠道,通过多种渠道来获取用户需求。内部渠道包括产品、老板、同事和自己,外部渠道包括市场、用户、竞品和合作伙伴。
外部获取渠道:
需求的获取方式,包括内部方式和外部方式,通过多种方式来获取用户需求。内部方式也同样包括产品、老板、同事和自己,外部方式包括市场、用户和竞品。
不仅我们需要了解需求,同时各种各样的需求也要规范的进行记录,我们通过需求卡片来进行需求记录,包括需求编号、需求类型、需求来源、需求内容、需求场景、记录时间、记录人员等。
需求也有真伪,获取了需求,接下来我们需要进行需求分析,分析哪些需求是真需求,哪些需求是伪需求;哪些需要是必须要做的,哪些需求可以不用做;哪些需求先做,哪些需求后做;如何进行筛选需求等,常见的需求分析包括:需求筛选、需求透视、需求排序。
初步进行需求筛选,包含有4个分析纬度,真实性、一致性、价值性和可行性。
需求透视就是从获取的表面需求中提炼出用户的本质需求,理解用户的本质需求,则有利于我们更好地提出产品需求,分析表面需求、本质需求和产品需求。
再来一个小案例:有一天大冰哥和朋友去看电影,走在了街上突然发现没吃饭饿了,大冰哥想吃火锅,但由于要和他的朋友一起看电影,时间来不及,于是它们一起吃了山西刀削面,解决了吃饭问题,然后两人一起去看电影了。
那么上面小大冰哥的用户描述需求是想吃火锅,但用户实际想要的只是没有吃饭,只要吃饭了就行,而他们的潜在需求有饮料,啤酒和水果等。
根据企业的战略定位、产品规划和用户需求,我们需要对记录的产品需求重要性进行优先级排序。具体而言,通过需求类型、需求频率、需求强度和需求逻辑来进行需求的优先级排序。
1)需求类型
依据KANO模型对需求做出的分类,考察需求的类型,包括基本型需求(痛点)、期望型需求(痒点)、兴奋型需求(兴奋点)。
如微信产品,用户的基本需求(痛点)是聊天,微信表情则为用户的痒点(期望型需求),没有表情包也照样聊天撕逼,而微信红包则是用户的兴奋点(兴奋型需求),在撕逼完后还可以发红包互相伤害!
2)需求频率
用户在单位时间内使用产品的次数即为需求的频率,频率越高,需求对用户越重要。如产品设计时,把高频率的功能放在一级,把低频率的产品功能放在二级甚至于三级等。
3)需求强度
需求的强度可以参考马斯洛需求层次理论,包括必要性、高频次和持续性。
4)需求逻辑
需求之间也存在着一定的逻辑关系,需有也有先后,先完成第一步需求,才能完成第二步需求。如微信视频,必须先有微信好友,才可进行微信好友视频。
需求不变,变得是适应需求的产品,把控需求来源,提高需求质量。
本篇文章为大家介绍了产品与需求、需求理论知识和应用、需求获取和分析研究,相信基于以上需求分析理论和方式方法,在以后大家对需求分析的处理能够有所新新思路,高效打造出一个有价值的优秀产品。希望能给到小伙伴建立自己的产品需求分析体系一些启发。
参考文献:
本文由 @Hello_大冰 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
*请认真填写需求信息,我们会在24小时内与您取得联系。