设计师如何做一份以用户体验为心中的PPT?

本文将会从用户体验的角度以汇报总结的内容核心、面向对象、场景分类、内容标准等方面和大家探讨交流,设计师如何做一份以用户体验为心中的PPT?

说到以用户为中心的体验设计大家一定不陌生,通常这里的用户说的是产品面向的用户,即外部用户。然而,在职场中我们经常需要与产品运营、技术开发沟通设计方案,与领导上司述职汇报,与设计圈内同学分享思考等等,这部分用户我们暂且定义为内部用户。针对内部用户,在与他们沟通中到底讲哪些内容,如何表达出自己的工作价值,如何让别人认同设计方案呢?

针对上述问题,本文将会从用户体验的角度以汇报总结的内容核心、面向对象、场景分类、内容标准等方面和大家探讨交流。

两类设计师

A君平时工作努力且产出内容丰富,但是总是分享不出来什么,别人也很难意会,因此,在实际工作中相对吃亏,也是设计师群体中大多占比。B君缺少实干,很会做PPT,方法论、设计理念头头是道,但作品方案本身却表现平平,内行往往也能一眼甄别。

两类人群我们都不提倡,总结汇报不仅仅是工作内容陈述报告,更多的是对抽象能力、认知、全局思维的提升,而不是假大空的PPT。本文核心不是教大家怎么做PPT,而是通过这种形式,提升能力,更好的传达自己的价值。一切形式都是为内容服务。

底层岗位观(核心价值)

为什么要讲底层岗位观?

听过很多的设计师分享或者汇报,内容看起来十分丰富,但稍微斟酌,不难看出很多内容都是产品经理的职责范围,那么设计师的岗位职责边界到底在哪,设计价值是什么?却没有清晰的传递出来。众所周知,一个人的世界观决定着你的方法论,而你的方法论决定着你的行为结果。

同理,一个人的岗位观,决定着你的核心产出内容是否偏题跑纲。这点至关重要,尤其对于交互、体验、产品设计师等岗位的设计师,在日常工作中经常会和产品经理的工作范围有一定重叠。

设计师如何做一份以用户体验为心中的PPT | 汇报总结能力提升篇

所以,在做总结前,一定要明确自己的岗位观。当然,在不同的公司,岗位职责同名不同责的情况比较多,解决这个最好的办法就是查看该公司该岗位的Job model,这往往也是,未来能在该岗位上拿到好的绩效的评定标准。

目标用户与场景分类(内容范围)

岗位观明确后,我们接下来需要明确三个点:用户、预期、场景。

设计师如何做一份以用户体验为心中的PPT | 汇报总结能力提升篇

用户,即分享的听众,是老板领导还是内部同事,亦或是外部交流团队。针对不同人群,在设置分享策略上也会千差万别。比如:针对内部同事,他们对某某项目的背景很了解,就没有必要大篇幅讲背景,更多的阐述核心方案和细节。而针对外部分享,则需要比较长的铺垫,以此降低听众的认知成本。

预期,即目标听众他们想从你的分享中得到什么,每个人都不会浪费半小时到几小时听一个无趣且对自己无用的分享。那么,我们就要动用体验设计师的核心能力-同理心。站在对方的角度去审视自己的产出主要内容,到底是专业干货,还是项目流程,是经验总结,还是成果喜报。这点特别重要,经常在设计师专业分享中,听了很多的项目流程汇报,甚至在圈内较高级别的干货分享中,听到的都是成果喜报、产品广告等,与预期大相庭径。

场景,即分享的形式是什么。这里通常和观众及其预期紧密相关,也决定了内容组合表现方式。例如:专业干货分享会,PPT形式则需要展示完整细节亮点设计,并配有完整思路大图。而复盘为主的总结会,则以数据结果和趋势图为主。甚至,一些演讲性质的分享,PPT只是作为辅助引导作用。

根据以上三点,我们就能很快的限定出输出的核心内容应该是什么,用一句话表示:在某某 场景下,通过对XX核心内容的表达,满足某某听众的心理预期。

设计师如何做一份以用户体验为心中的PPT | 汇报总结能力提升篇

举个例子:在晋升述职的情况下,通过对能体现出更高层级能力的内容描述,满足评委的心理预期。因此,更高层级能力的内容就是我们要表达的核心点,在接下来的内容素材准备过程中,便可按照Job model 的标准基线来划分,决定是否添加或删除。

那么在其他情况下,满足预期的核心内容是什么呢。这里我总结了使用率较高的几种情况,仅供大家参考。

设计师如何做一份以用户体验为心中的PPT | 汇报总结能力提升篇

关键四要素(内容标准)

有的同学说了,我也是按照大致的框架做的PPT ,结果出来感觉不够激动人心。一份内容充实,令人激动的PPT ,除了核心和骨架外,需要更多更好的细节血肉串联其中。归结起来以下四点:逻辑、数据、图像、故事。

设计师如何做一份以用户体验为心中的PPT | 汇报总结能力提升篇
  • 逻辑:表达要有逻辑性,因果关系明确,所展示的素材要有其价值,不要为了凑数乱放。
  • 数据:论证最好配有数据,数据可大幅度增加内容说服力。当然,合理的多角度挖掘数据,也是一项需要不停去提升的能力。
  • 图像:这方面对于设计师的我们来说属于擅长领域。

此处建议:

  1. 核心输出物大且多,增加视觉冲击;
  2. 复杂逻辑可视化大图,降低理解成本;
  3. 合理数据可视化。
  4. 故事:故事属于分享内容的高阶玩法,通过创建虚拟(或来源真实)故事,强化核心价值,带入场景。对此感兴趣的同学可以研究下TED演讲。

以上四个要素,从基础到高阶,基础为重中之重,切不可舍本逐末。

总述

一次精彩的分享,需要我们反复的迭代审视,也更需要计划性的素材积累。通常一次分享,至少一个月前就要开始准备,而晋升答辩等关键性分享在半年前就已经开始筹备并完成拆解的目标。总而言之,让我们攀登高峰的不是奇招,而是熟能生巧的基本功!

作者:王康,网易云音乐交互设计师,主要负责直播、K歌相关产品设计,善于总结思考,致力于互动体验设计,洞见、创新、感人、美。

微信公众号:网易UEDC

本文来源于人人都是产品经理合作媒体@网易UEDC,作者@王康

题图来自Unsplash,基于CC0协议

监控产品中“告警服务”的设计及演化

在“告警服务”的设计过程中,首先明确了“告警服务”的价值,然后通过用户画像描述了“告警服务”的实际应用场景,接着通过“用户体验地图”全面梳理了“告警服务”中用户的触点、痛点、机会点,并以此分析出设计的落地策略,最后通过对“告警服务”的设计及其迭代演化,逐步完善“告警服务”的设计方案、提升用户体验。

监控,可以拆解为“监视+控制”,监视(monitor)表示用户通过观察获取数据,控制(control)表示数据变化引发的用户行为。

作为云产品的一种,监控产品构成“数据—人—行为”的闭环,满足用户两层需求:

  1. 提供准确实时的产品数据
  2. 产品数据引导正确的用户行为

数据是监控的基础,行为是监控的价值变现。本文所述的“告警服务”就是在用户处于离线状态下,监控产品仍然能构成“数据—人—行为”的完整闭环。

一、告警服务的价值

用户需求

对于99%的用户,都不能7*24盯着监控系统,当处于离线状态时(干活、吃饭、睡觉、下班、休假…),用户与监控数据之间是隔离的。

在这种场景中,如果监控数据发生了异常变化,用户仍希望能够立马获悉,进而采取措施应对、避免造成损失。“告警服务”应运而生,用户设定一定的规则,当监控数据违反规则时触发告警并发送给用户,打破“人”和“数据”的的隔离状态,瞬间构成“数据—人—行为”的完整闭环。

业务价值

“告警服务”能极大解放用户的注意力。通过对产品的业务数据设定规则,业务人员就可以7*24的掌握产品数据的健康状态,得以将更多的精力专注于业务本身。

“告警服务”能使用户第一时间获取期望的业务数据。产品的业务数据一旦违反用户设定的规则即可迅速推送至用户,帮助用户过滤99%的无效信息,使数据精准触达用户。

二、用户画像

用户画像A

任盈盈,女,25岁,产品经理

负责苏宁易购某核心产品线-XX产品线的产品工作,日常的工作主要围绕XX产品线的需求、排期、研发、上线开展,工作节奏快、强度高。每天会登录数次监控产品,查看XX产品线的监控数据,以掌握XX产品线的健康状态。

由于工作节奏快,每天难以抽出充沛的时间去分析产品监控数据,会遗漏部分关键数据从而留下隐患。希望能通过告警服务获取所有XX产品线相关的关键异常数据,既不用花费大量的时间精力去分析数据,也不会遗漏任何关键数据。

用户画像B

令狐冲,男,35岁,技术负责人

负责苏宁易购某核心研发中心-XX研发中心的技术工作,日常的工作主要是XX研发中心的技术保障,工作责任重、压力大。每天一上班就会打开监控产品,随时查看XX研发中心相关的监控数据,保证系统的稳定。

由于系统是7*24小时运行,但自身无法全天候上线查看监控数据,尤其是下班后或节假日,没法做到随时查看监控数据。希望能通过告警服务及时获取XX研发中心相关的异常数据,以便第一时间作出判断、并决定是否安排人员介入。

三、用户体验地图

通过参考行业相关产品和调研用户需求,可以将“告警服务”拆分为4个阶段:

“配置告警策略——筛选产品数据——推送告警消息——接收告警消息”

以下是“告警服务”4个阶段的用户体验地图,可以从全局视角审视“告警服务”的每一个环节。

通过洞察用户的行为和心理,梳理用户在不同阶段的情绪点,可以盘点、挖掘“告警服务”四个阶段设计的机会点,如下:

  1. 配置告警策略:简单的配置规则、合理的指标、提供默认的阈值
  2. 筛选产品数据:计算平台处理能力强、计算平台准确性高、计算平台稳定性好
  3. 推送告警消息:告警平台稳定性好、告警平台对相同告警进行合并
  4. 接收告警消息:告警内容简单易读、告警消息支持多渠道发送、告警消息支持自定义接收者

四、分析与思考

用户体验地图给出设计的“机会点”,接下来需要思考如何将其落地、形成可参考执行的设计策略。

首先,需要关注存在哪些用户触点,这是设计落地的切入点,通过用户体验地图,分析如下:

1)在“配置告警策略”阶段,存在1个触点:告警配置模块。

结合该阶段的设计机会点,可以推定:在告警配置模块,需要提供简单的配置规则,在配置规则内尽量提供用户最合适的指标或组合,并且在关于阈值的设定上可以提供默认值、或者毋需用户设定。

2)在“筛选产品数据”、“推送告警信息”两个阶段,均由后台系统自动完成、用户不会直接接触,因此不存在用户触点。

但是并不意味着设计不需要关注这两个阶段,在设计的过程中,需要根据目前的技术能力给出合理的设计方案,尽量避免凭空想象。

3)在“接受告警消息”阶段,存在2个触点:终端接收设备、告警内容。

结合该阶段的设计机会点,可以推定:

  • 针对“终端接收设备”,用户希望可以选择自己需要的渠道接收告警消息,并且告警消息发送给谁也由用户自己决定,这两项均属于配置阶段的内容。
  • 针对“告警内容”,用户希望能按照重要、紧急两个维度将告警内容从上到下排列,并且尽量减少冗余信息、提升可读性。

通过以上分析,可以清晰归纳出,设计的落地点主要由两个:

  1. 配置告警策略(支持自定义的渠道和接收者)
  2. 告警消息所推送的内容

针对这两项的设计策略如下:

五、设计及演化

配置告警策略

参考行业相关产品,告警配置模块主要分为两个部分:

  1. 告警策略的展示列表
  2. 告警策略的添加/编辑状态

本质上两者都是即围绕“告警策略”开展设计。

针对“告警策略”,一般由4种内容组成:

  1. 告警策略的名称
  2. 告警监控的对象
  3. 告警针对的指标
  4. 告警触发的条件

在本案例中,由于“终端接收设备”模块的内容合并至“告警配置模块”,因此本案例中的告警策略需要再增加一项内容:告警消息的推送。

1)告警策略的名称:指本条告警策略的名称,与人的姓名一样,是用户识别告警策略的主要标识。

2)告警监控的对象:指本条告警策略是针对哪些对象而配置的,监控这些对象的状态变化。

3)告警针对的指标:指针对哪个数据指标设立告警规则,指标可以是单个或一组,需要选择合适的指标才能更好的发挥告警服务的价值。

4)告警触发的条件:指选定的数据指标达到什么阈值即触发告警的生成,这个决定告警服务的精确程度。

5)告警消息的推送:指告警消息发送的人员,以及发送的方式,也就是解决“通知谁、怎么通知”的问题。

梳理完告警配置模块的元素,就可以根据“配置告警策略”的设计原则,开展设计:“配置规则简单、指标契合、阈值有默认值、自定义接收渠道、自定义接收者”

当用户进入告警配置模块,未配置任何告警策略,提示、引导用户开始创建。

针对“添加告警策略”,经历了3版设计方案的演变。

第一版方案,基本符合上述的设计原则。

该方案上线之后用户配置了大量的告警策略,但发生了意想不到的事情:不告警。经过排查定位,最终确认是计算平台产生了非常严重的阻塞,即“用户体验地图”的第二阶段“筛选产品数据”出了问题。复盘之后,认定有两方面的原因:

  1. 一是所选择的告警指标“影响用户占比的环比增长率”涉及大量的“去重”计算,严重消耗计算平台的性能;
  2. 二是监控对象没有做限制,多个筛选条件排列组合之后产生了大量监控对象,远远超过了计算平台的极限。

因此,决定从两个方面优化设计方案:

  1. 使用新的告警指标
  2. 对监控对象做限制

这是第二版方案,在延续第一版所遵循的设计原则基础上,针对性做了优化。

  1. 监控对象限制了可配置的数目,降低现有计算平台产生阻塞的风险;
  2. 改用新的告警指标,舍弃了“去重”计算,提供“绝对值”、“相对值”两种指标供用户选择,覆盖面更广;
  3. 精简了触发条件,减轻现有计算平台的压力;
  4. 消息推送的渠道默认值只设置“豆芽”,降低成本(豆芽是苏宁内部员工使用的IM工具)

第二版方案上线之后,告警计算平台的阻塞问题解决了,但是用户反馈:监控对象可配置的太少。这个当时已经预料到会有这个问题,但是现有的计算平台性能受限,“巧妇难为无米之炊”,只能采取这种妥协的方式。

随着新的计算平台上线,性能得到极大提升,设计方案也不用“畏手畏脚”。第三版方案在保留原有优点的基础上,主要针对“告警对象”做了重点优化。

  1. 告警名称提供默认值,解决用户对告警名称填写过程中“不愿想、不愿写”的”懒“需求;
  2. 监控对象的来源,提供用户常见的场景作为待选集合,方便用户快速选择告警对象;
  3. 监控对象的配置,让用户行为从“输入”变成“勾选”,并提供批量选择,简化用户的配置步骤;
  4. 监控对象的数目,限制数放开至200,并可通过后台配置进行动态调整。之所以将数目暂定于200,是方便用户从四个TOP异常的场景中分别选中一类,正好200。

添加完告警策略之后,告警模块至少会有一条告警策略。

  1. 支持用户对告警策略列表进行筛选、搜索
  2. 支持继续添加告警策略
  3. 将告警策略的五种主要内容(告警名称、监控对象、告警指标、触发条件、消息推送)显示在列表内
  4. 支持对单条策略的开关、编辑和删除,其中“开关”场景是用户暂时需要关闭策略、但不对其进行删除

告警消息

告警消息指的是当告警发生以后,告警平台将该条告警相关的信息推送至用户,是“数据—人—行为”闭环的重要一环,用户通过阅读告警消息获取当前系统的健康状况、从而采取对应的干预措施。

根据“告警消息”的设计原则,开展设计:

“提供关键数据、精简告警内容、减少冗余信息、提升可读性”

相比于“配置告警策略”,“告警消息”没有出现过较大版本的优化。通过参考行业相关产品和用户需求,择取了9个字段,实际的告警消息有两种模板,分别对应两种告警指标:异常数、绝对值。

  1. 告警策略的名称:用户第一时间判断和自身的相关程度,是否自己创建、是否是高优先级告警策略。
  2. 当前产生的告警等级:判断该告警的严重程度,决定了采取何种干预措施。
  3. 产生告警的监控对象:确认告警是由哪个监控对象引起,如果要采取措施可据此联系责任人。
  4. 触发告警的数据:查看现场数据,在告警等级的基础上进一步判断该告警的严重程度。
  5. 告警发生的时间:时间可用于定位告警的原因和判断时效性。
  6. 告警所属的产品:附属信息,当用户名下有多个产品时据此区分。
  7. 告警发生的来源:附属信息,当用户使用多种监控系统时据此区分。
  8. 告警消息的接收者:附属信息,用户用以判断相关干系人是谁。
  9. 告警策略的创建者:附属信息,用户用以判断该告警策略是否是正常、合法创建。

六、总结

小结

在“告警服务”的设计过程中,首先明确了“告警服务”的价值,然后通过用户画像描述了“告警服务”的实际应用场景,接着通过“用户体验地图”全面梳理了“告警服务”中用户的触点、痛点、机会点,并以此分析出设计的落地策略,最后通过对“告警服务”的设计及其迭代演化,逐步完善“告警服务”的设计方案、提升用户体验。

随着AI和大数据等技术的引入,“告警服务”会持续进行优化迭代,主要围绕3个方面:

  1. 更简单的配置。通过采取态势感知、智能化的带状阈值区间会逐步取代人工设定的阈值,能极大降低用户使用“告警服务”的成本。
  2. 更具体的对象。目前的告警策略针对的还是零散的告警对象,未来将会将围绕“场景”概念为用户提供更加具体的业务告警对象,价值更高。
  3. 更精准的决策。目前的告警服务仅仅限于将现场数据告知用户,未来将会提供给用户加精准的辅助决策,以达到智能化运维的目标。

反思

设计师都是理想主义者,设计过程就是一个理想主义者不断与这个世界妥协的过程,与用户妥协、与技术妥协、与时间妥协,但这也体现体验设计的魅力:围绕用户需求进行快速迭代。

“设计没有好与坏,只有合不合适”

作者:胡欣欣,公众号:吹拉弹唱大师(ID:cltcds)

本文由@吹拉弹唱大师 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash, 基于CC0协议

以滴滴为例:聊聊价格理论与用户体验

人本质上都是趋利的,价值创造者应该顺势而为,聚焦效用与成本,才能真正做到以用户为中心。 

产品的效用与成本

我们可以把用户使用产品看作是一种“交易”,消费者付出一定的成本,获得了一定的价值。在经济学的价格理论中,我们评估商品能否成交,是基于商品给消费者带来的效用(满足程度)。

比较“A:消费者为了获取这些效用所愿意付出的最高价格”与“B:商品的实际价格”,如果:A<B,则交易无法达成,因为消费者要获取商品效用所愿意支付的最高价格比实际需要支付的价格要低。

俞军老师将其抽象为:

用户价值=新体验-旧体验-切换成本

这个公式很容易理解:

相比微信,子弹短信提供了更有价值的语音信息,用户不需要付出“听语音的成本”,就能接收到语音消息的内容,所以这里的“新体验-旧体验”是正值。但是, 微信上海量的好友关系,聊天记录,公众号,朋友圈等等,都让“切换成本”变得非常高,所以对于绝大部分微信用户,子弹短信的“用户价值”仍为负数,用户不会放弃微信。

为了让用户价值公式更好地指导产品设计,我们继续拆“体验”。我认为:

体验=效用-认知成本-时间成本-操作成本

  • 效用:产品/服务对用户的满足程度。例:当我饿又不想做饭的时候,饿了么的外卖服务为我提供了比较大的“效用”
  •  认知成本:思考产品/服务所需花费的成本。例:这个“微信7.0的即刻视频”到底是怎么用的?(用户要花大量精力思考)
  • 时间成本:等待产品/服务所需要花费的成本。例:ZEPETO最火的一天,服务器几乎无法登陆,用户无法深度体验
  • 操作成本:获取产品/服务所需花费的行为成本。例:相比支付宝,微信支付依托于微信高频的使用,在场景下不需要再单独打开APP付款,操作成本更低

综上,设计产品、创造价值的过程,我们本质上是追求:

  • 在相同的效用下,让用户付出更低的成本;
  • 在相同的成本下,让用户获取更多的效用。

以滴滴为例

1. 效用

作为用户,使用滴滴出行的快车服务,我们能获得多少“效用(满足程度)”?

  • 随时随地快速叫车,不用再为夜晚路上没有出租车打而烦恼。
  • 等待司机找乘客,不用为了打车到处走。
  • 透明的用车价格,不用再跟黑车司机议价、拼车。
  • 严格的路径规划,不用担心导致的绕路多计费。
  • 良好的司机服务,出行属于买方市场,乘客的评价对司机的利益影响较大,该模式倒逼司机提供更好的服务。
  • …….

相比传统出租车,滴滴快车在初期通过“补贴”快速获取市场份额,培养用户习惯。在补贴退出后,产品仍然能向用户提供“更快速响应、更多元、更方便、更透明安全(综合起来就是效用)”的出行服务。

2. 成本

① 认知成本:减少用户的“不确定性”,降低思考的成本

1)提前告知重要信息

一般用户在选择目的地后,会想要知道多久能打到车,为了让用户减少“认知成本”:

  • 滴滴出行,在选择目的地后会显示“预计上车时间”。
  • 神州专车,不会显示“预计上车时间”,用户想要知道只能叫车后等待。
  • 优步中国,在未选择目的地之前就会显示“预计上车时间”。

② 操作成本:简化高频操作,降低操作的成本

滴滴快车的订单操作中,有三步是必须的:选择位置选择车型支付车费。要降低用户的操作成本,需要围绕这3个关键步骤做优化。

1)预测用户行为

在通勤、蹦迪回家的场景中,用户的OD往往是固定的,可基于用户历史的订单数据,预测目的地,减少用户的“操作成本”。

2)主动替用户选择

打开APP,第一步是定位用户位置,对比了滴滴、神州专车、优步中国:

  • 滴滴出行,在初始状态会选择基于当前定位的最佳上车点,减少了用户的“操作成本”。
  • 神州专车,在初始状态提示“定位可能有偏移,请确认您的上车地点”。实际上选择了推荐的上车地点后,上车位置几乎没有变化,说明产品对“起始点合适程度”的判断逻辑还需要改进。

3)简化关键节点

开通免密支付,每次行程结束后自动扣除车费,减少了用户的“操作成本”。

③ 时间成本:要降低用户的服务等待时间,往往就是要解决供需匹配的问题

滴滴的出行是即时的,相对同城运输、干线车货匹配,其实时性要求更高,如果平台运力与需求的匹配度低,则需要通过“配给”或者“价格机制”解决供需失衡。

需求端:

  1. 乘客动态加价(价格机制)
  2. 提高车价(价格机制)
  3. 乘客排队(配给)

供给端:

  1. 任务奖金(价格机制)
  2. 提高车价/降低抽成比例(价格机制)

由于之前滴滴的动态加价遭受舆论的谴责,目前改用先到先服务的排队机制,应对当前监管压力下的供需失衡。然而,这种机制无法保障“最需要服务的人(也就是愿意出更高价格的人)获得服务”,资源的利用效率并不是最优的。

更重要的是,排队并不比价格机制更能解决问题,因为“即使出行”的用户决策时间很短,排队实际上也是变相的挤走了部分的需求(如下图),而这些被挤出的需求可能是更需要出行资源的人(也就是愿意出更高价格的人)。

总结

很多时候我们可能会疑惑“用户为什么不愿意用我们的产品”,其实是没有关注产品为用户提供了多少效用、用户为之需要付出多少成本。人本质上都是趋利的,价值创造者应该顺势而为,聚焦效用与成本,才能真正做到以用户为中心。

本文由 @代小艺 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自网络

京东内部资料:用户体验提升模型

经过项目中不断的探索与研究,结合几个方法论,我们整合出了一套用户体验提升的方法流程——用户体验提升模型。

下面就来详细的介绍一下,希望能给到大家帮助和启发。

先问几个问题:

  1. 你知道你所负责的产品/设计方案的用户体验好还是不好?
  2. 产品/设计方案体验不好时应该怎么做?
  3. 这个产品/设计方案的体验具体有哪些问题?
  4. 怎么优化出现的体验问题?
  5. 哪些模块或页面的问题最迫切需要解决?先优化哪些?后优化哪些?

用户体验提升模型能很好的帮我们解决以上问题。

先介绍一下用户体验提升模型的流程:线上版本调研 – 协作启发式评估 – 问题分析整理 – 优化方案

这篇文章也会以这个流程一一介绍。

一、线上版本调研

也可以是设计方案,我们采用了SUS系统可用性量表进行调研,SUS是评估产品可用性的一个花费少,但十分有效的工具。该量表包含了10条定向问题,每个问题均为5分,按强烈反对(1分)到非常同意(5分)评分。(各位小伙伴可自行网上查询系统可用性量表,有很详细的介绍,在这里不赘述了)

最佳的方式是在线上直接上一个问卷调研来收集真实用户的反馈,然后对收集到的结果做如下算法:

  1. 对于奇数序号的问题,将其得分减1;
  2. 对于偶数序号的问题,将其得分被5减去;
  3. 将所有问题的减法后得分加在一起,然后乘以2.5;
  4. 计算出的结果即为我们产品可用性的得分。

那么如何通过评分看出一个产品的好坏?

上图是一个评分参考,通过数据得出,系统可用性量表最终算出的评分达到70分左右,就可以比市面上一半产品可用性要好,也就是说这个产品的用户体验算是合格了。

但是系统可用性量表的评分结果是抽象的,这个分数只能让我们大概了解产品用户体验的好坏,在具体问题上却是缺失的,那我们知道产品评分较低时我们如何聚焦产品的优化方向呢?

二、协作启发式评估

为什么是协作启发式评估而不是启发式评估?

因为启发式评估主要由几名交互专家以角色扮演的方式,来完成设置的任务给出评估结果。

优点是成本低、快捷;

缺点也显而易见:

  • 一是交互专家团队中不一定有或者很少;
  • 二是可用性问题意见一致率很低,并不能很明确的指出为什么这是一个体验问题,有很多个人因素的主观见解。

因此我们决定用协作的形式来进行评估,而且不需要交互专家,可以是用户、测试、设计、产品、运营、商务等等,只要愿意参与测试,就可以。协作启发式评估以小组为单位,能够很好的整合出更多的问题,而且更准确。你说他们也不是交互专家,能起到好的结果吗?竟然都整理出方法了,那答案当然是能啊。

为什么能,因为整个评估过程中,我们是有最新的可用性原则来给予启发的,有了这套可用性原则,一秒变专家。

说到可用性原则,了解用户体验的都知道尼尔森的十大可用性原则,但是从1995年提出到现在,已经过去了二十多年,互联网世界已经发生了巨大的变化。在这样的情况下,尼尔森的十大可用性原则明显有些不那么符合或者说不能给出针对现今产品太全面的启发。

所以,我们重新整理了一套可用性原则,这套可用性原则更针对现今互联网产品,基本可以覆盖到所有出现的用户体验问题。

我们称之为最新21条可用性原则。(重点来了,重中之重)

有了这21条,可以让任何没有用户体验知识的人参与到协作启发式评估中来了,一秒变专家了有木有。当然,这21条可用性原则我们也会迭代优化,目的是做到更符合现今产品、更全面的可用性原则。

通过什么来确定的这21条可用性原则?

首先,我们都知道用户体验五要素,这已经是做产品设计的基本常识了。

我们来看这五个层级对用户体验能产生影响的有哪些?

战略层一定不会,如果一个产品立项了、已经上线了,一定是战略层成立了,如果战略层出现了问题那就要重新考虑产品要不要做或者是改变方向了。

那么剩下的4个层级呢?

范围层、结构层、框架层、表现层,其实都会出现用户体验的问题。

那我们看看这几个层级所包含的内容,视觉呈现界面设计导航设计信息设计交互设计信息架构功能规格内容需求,这样的话就有8个大类,然后我们通过多年的经验和对尼尔森可用性原则的理解,把可用性原则对应到这8个大类中,最后得到了这分类明确的21条可用性原则。

但是分了这8个类有个啥用?读下去,你就会知道。

具体方法:

先说说调研的具体方法。我们以协作启发式评估的方法,组织好调研小组(8人以上,样本越多越好,反正最后还要去重),宣讲完流程方法和操作任务,就可以开始进行评估了。我们一般为了省时间,宣讲完就把表格发下去,让他们自己找时间完成表格,然后再收回来。

这个表格就是用户体验问题记录表,包括问题所在位置、对应的21条可用性原则、严重程度等级、问题描述。

三、问题分析整理

收集了一堆问题之后应该怎么做呢?

通过小组会议讨论,把相同、相近的问题统一成一个,可优化的问题保留下来,不是体验问题的去掉,然后整理到一起,这就是整个产品存在的大大小小、各种各样的问题了。

接下来,我们引入另一个方法,就是用户体验八阵图

这张用户体验八阵图的8个点是不是有些眼熟?

没错,就是最新21条可用性原则里的8大分类,这就是上文为什么分为8个类的原因。中心向外为问题严重等级,依次为:小问题(1)、次要问题(2)、主要问题(3)、灾难性问题(4),一一应对到“用户体验问题记录表”中的“问题严重等级”。

怎么使用呢?

首先,对记录表里的“问题位置”进行归类,以模块化区分,比如:把登录注册流程做为一个模块,用一张八阵图来表示,最终把产品的每个模块都用一张八阵图来承载所对应的体验问题。

然后,把收集到的问题以“点”的形式点到对应模块的八阵图当中。

哪个模块问题最多?问题出现在哪个方向上?是视觉?还是交互?还是内容?哪些问题很严重需要迫切解决?一目了然。

四、优化方案

  1. 通过SUS系统可用性量表知道了产品的整体体验处于什么水平。
  2. 通过协作启发式评估知道了产品的用户体验到底有哪些问题。
  3. 通过最新21条可用性原则知道了如何避免出现体验问题。
  4. 通过用户体验八阵图知道了哪些模块最迫切需要优化。

知道了这些,我们进行产品优化的时候还会不知道如何下手吗?接下来就要靠你自己了,你一定会做的更好。

当然,这套模型只能对线上产品的用户体验提升起到一定帮助,一个产品真的牛逼还要从战略层一步步做起,我们需要去清楚的知道产品的目标是什么,我们能提供什么,我们想要去得到什么。对于产品的迭代,我们可以从使用人群(目标客户),主要功能(产品的服务方向),产品特色(与竞品的差异化),商业价值(盈利模式)上深入研究。

结语

好了,到这里就为大家介绍完了这套用户体验提升模型,如果还有什么不清楚的地方,随时欢迎大家咨询,期待与大家一起探讨~

作者:FTD,公众号:FTDesign

来源:https://mp.weixin.qq.com/s/y1Ct7DQLjdk3rqkV6hxXIA

本文由 @FTD 授权发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

4000 字详解「用户反馈」的收集与分析

面对用户反馈,我们需要运用什么方法才能做到有效收集呢?在收集过程中,我们又要注意什么呢?本文将为你揭晓答案。

客户将意见反馈给产品经理、客户服务员工、分析师、营销人员以及组织中的任何人,都会为公司带来宝贵的财富。但尽管如此,最近的一项研究发现,42%的公司仍没有对客户进行过调查或意见的收集与反馈。

在本文,我们会根据不同类型的客户反馈,收集有用的反馈方法,以及分析对业务影响较为重要的反馈类型。

一、什么是用户反馈

用户(客户)反馈来自于客户,其中包含有关你的产品或服务的体验和满意度。用户反馈可以来自各种渠道,如:电子邮件、社交媒体等。

用户反馈对于未来的产品开发、改善客户体验和整体客户满意度至关重要。回应不满意用户的负面反馈,有助于有效提高用户忠诚度。

二、更好地收集用户反馈

1. 提供反馈意见的客户类型很重要

图 1. 不同类型的客户

你是否能对给你提出反馈意见的朋友持相同的关注度?

不太可能。

通常情况下,你会比较信赖和你认识时间较长的朋友,即使你在公共汽车上遇到的陌生人告诉你你应该怎样对待你的生活,你也可能不会对他们的观点给予太多的重视。

在业务情况下,客户与业务的关系会影响你参考他们提供反馈的权重。忠诚度最高的客户对你的产品有着丰富的经验,他们的意见就显得特别有价值。

2. 无论是否提示,客户的反馈都很重要

图 2. 提示和不提示的客户反馈都很重要

自动反馈值得特别关注。这是因为那些你没有注意到的、完全没有意识到的客户问题可能包含着一些你最需要听到并关注的信息。

同时,一些开放性的主动问询,也会收获比较重要的反馈信息,比如在就医结束时,医生问“你还有什么想说的吗?”,它常常会引发病人谈论他们眼下最重要的问题。

3. 顾客的动机很重要

图 3. 图片来源于网络

记住,如果人们有一个极端的经历,他们通常会主动提供非请求的反馈。这就是为什么你会看到 Yelp 餐厅的评论集中在“令人惊讶”和“令人震惊”的一端。人们认为他们可以通过告诉别人他们刚去过的好餐馆,或者警告别人不要去糟糕的餐馆来获得社会资本。

但是你的晚餐真的很特别吗?你会写一篇评论去推荐吗?

餐馆顾客反馈的例子说明了一个关于动机的重要原则。

导致这类餐厅评论数据的分布类型通常是J曲线。“J”形是指曲线最初下降,然后上升到比开始更高的点的数据。

当涉及到你收集的客户反馈时,你可以期望有一个类似的模式,你的客户更有动力告诉你他们什么时候对你的产品非常满意或不满意。

然而,这并不意味着你的客户只喜欢或者讨厌你的产品。还可能有一大群中间派认为你的产品“很好”,但这些客户通常保持沉默。可是请记住,他们也可以给你有用的反馈。如果你很聪明,你应该能找到一些方法来整理他们的反馈。

4. 数据很重要

图 4. 数据很重要

如果上个月 80% 的客户反馈都告诉你最近对核心产品的“改进”已经破坏了人们的工作流程,那么你当然应该倾听。于是,关于单个问题相对于其他问题的反馈总量很重要。它也会保护你免受“自由”偏见的影响,在这种偏见中,人们认为他们经常听到或最近听到的事情是最重要的。

5. 重复很重要

用户问题经常被工作人员忽略,理由是“哦,我们已经听说了很多遍了。”也许你打算在明年的一次大规模重新设计中最终解决这个问题,又或者这个请求已经变得如此重复,以至于变成了陈词滥调,一种没有人再听的沉闷的抱怨。

无论哪种方式,这种反馈都是非常值得倾听的,特别是当它涉及到产品质量、bug 或难以实现产品中的核心任务时。这表明你没有掌握正确的基本知识,这是你必须优先处理的事情,而不是忽视它。

6. 注意高风险反馈

图 5. 高风险反馈很重要

一些反馈是值得倾听的,是因为它正代表着客户正在经历的困难,我们可以将其称之为高风险的反馈。也许你发布的产品存在安全漏洞,或者你的产品不小心将消费者的隐私置于危险之中。在审查客户反馈时,试着建立一种机制,提醒你这种非常偶然但高风险的反馈,这样你就可以立即采取行动。

三、如何收集用户反馈

你可以使用许多工具、方法和反馈系统来了解客户的体验。这里介绍三种方式:

1. 实时聊天

实时聊天是客户与你直接沟通的一种无障碍方式。你可以询问特定的问题(提示)或被动地对反馈进行分类整理。

2. 调查

向客户询问有关特定功能、平台的某些方面或部分体验的问题是一种简单而直接的方法。

3. 社交媒体

你可能已经注意到,人们喜欢在社交媒体上表达自己的情感。虽然这通常不是建设性的,但实际上你可以在一些社交媒体上找到非常有价值的反馈。客户在社交媒体上的反馈往往要么是喜气洋洋,要么是怒不可遏。如果出现某种趋势,你应该把它纳入你的分析中。

四、分析用户反馈的 7 个步骤

1. 整理数据

首先,将你想要分析的所有开放式客户反馈,以及关于每个客户的关键元数据,整理到一个电子表格中。理想的情况下,元数据应该包括一些属性,比如这个人成为客户多久了,他们花了多少钱,反馈数据提交的日期,以及反馈的来源等等。

当然,你也可以使用其他工具来收集这些数据。表格可以呈下图:

图 6.图片来源于网络

2. 分组归类

通常情况下,可以分为 3 类:反馈类型、反馈主题、反馈代码。

(1)反馈类型

如果要处理来自客户支持团队的非机密反馈,或者客户可以在调查字段中写下他们喜欢的任何内容,那么,将反馈分成不同的类型尤其有用。

以下是一些可能会较为有用的分类:

  • 可用性问题
  • 新功能要求
  • 错误
  • 用户教育问题
  • 定价/计费
  • 一般的肯定句(例如:“我爱你的产品!”)
  • 一般的否定句(例如:“我讨厌你的产品!”)
  • “垃圾”(这样无意义的反馈非常有用)
  • “其他”

(2)反馈主题

当你试图理解大量不同的反馈时,将反馈分解成不同的主题是非常有用的,但如果你的数据集很小(比如少于 50 条),那么你可能不需要这个。

你所提出的主题对于你所收到的实际反馈数据是唯一的,并且通常与产品的各个方面有关。例如,假设你正在开发一款像 Instagram 这样的流行产品,并且收到了很多客户的反馈。你的主题可能看起来像一个特定产品功能的列表,像这样:

  • 照片流
  • 故事
  • @
  • 配置文件

这种类型的分类在你的工作环境中特别有用,因为你可以将你的反馈给多个团队来采取行动。

有时主题可能与团队相关(例如客户支持、销售、市场营销),也可能与客户正在经历的未满足的需求相关。尝试提出一些主题,看看这些类型的主题是否对你和团队有用。

(3)反馈代码

反馈代码的目的是提取客户给你的原始反馈,并以更简洁、更可行的方式重新表述。

你的目标是使反馈代码具有足够的描述性,以便不熟悉项目的人能够理解客户的观点。反馈代码也应该尽可能简洁和真实地反映原始客户的反馈。不管你是否同意,你的工作就是尽可能客观地提取反馈。

3. 快速浏览

在开始对数据进行编码之前,你需要对数据有一个初步的了解:浏览反馈,了解反馈的多样性。

一般来说,如果每个客户给你的反馈都不一样,你很可能需要分析更多的反馈,以便发现模式,并使其具有可操作性。如果你浏览了前 50 条反馈,它们都与你的产品中的某个特定问题有关,那么你可能就不需要那么多的评论了。

4. 编写反馈代码

是时候卷起袖子集中精力了。找一个你不会被打扰的地方,开始阅读每一段用户反馈,仔细编码每一行。

你创建的这些确切的反馈代码将特定于反馈所涉及的产品,但这里有一些分析代码,用于某些虚构的新功能请求:

  1. 能够将任务分配给多个客户端
  2. 能够向任务添加复杂的 HTML
  3. 能够添加或删除任何屏幕上的队友
  4. 能够发送表情符号给客户

如果一条反馈正在传达多个点(例如,两个不同的特征请求),则在单独的列中捕获这两个单独的点是很有用的。

5. 优化代码

可以从更高级的代码开始,然后逐步分解,同时注意人们使用的语言词汇。因为很多乍一看是相似的问题,但实际上可能是不同的问题。

例如,假设你最初看到许多与“电子邮件问题”相关的客户反馈。然而,当你仔细阅读更多的反馈时,你会发现这些问题可以分解为两个独立的问题:“电子邮件编写器错误”和“电子邮件发送错误”,它们是完全不同的。

有时,当你阅读更多的反馈时,你会意识到需要将一个流行的代码分解为几个更具体的代码。例如,“对视觉设计的更多控制”可以分解为“添加字体的能力”和“控制图像对齐的能力”。

6. 计算总量

编写完所有代码后,下一步是计算每个代码的反馈总量。这将帮助你了解哪些反馈是最常见的,以及客户反馈中的模式。

一个超级简单的方法是按字母顺序对“反馈类型”、“反馈主题”和“反馈代码”列中的数据进行排序,这将把类似的项目组合在一起。然后标注显示所有具有相同反馈代码的单元格,总计数将出现在电子表格的右下角。

如果你有 100-500 条反馈,请在“反馈代码”列旁边添加一个新列,并为具有相同反馈代码的每一行输入一个“1”(例如,在“裁剪图像的能力”单元格旁边添加一个“1”),然后将代码出现的次数相加,重复执行其他反馈代码。

如果你有一个较大的数据集,你可以创建一个数据透视表来进行这些计算。对于大型数据集,此时更深入地挖掘并分析收集的其他客户属性也是很有价值的。将客户属性(例如客户类型、客户支出)放入电子表格中,并查看与你收到的反馈的其他关联。

例如,哪些客户对 X 抱怨最多?客户每月对 X 新功能的需求是多少?

6. 总结与分享

现在你已经对数据进行了编码,你可以根据问题的热度创建客户反馈数据的摘要,并与你的产品团队进行讨论。

如果你有 50 条或更少的反馈,你可以在一个简单的表格或一页文档中总结可执行的反馈。如果你有一个更大的反馈集,你可以将数据分解为我们前面讨论的其他变量(“反馈类型”和“反馈主题”)。这将使你更容易地获取你所确定的不同的反馈,并将它们传递给公司中能够针对这些反馈采取行动的不同人员。

对于客户反馈,你可以做的最强大的事情之一是创建十大功能请求列表或十大客户问题列表,然后你可以使用这些列表来通知你的产品路线图。

有时候,很难知道如何分析客户的反馈,尤其是在你的公司没有研究人员或分析师可以提供帮助的情况下。然而,如果你遵循这篇文章中的建议,任何人都可以把杂乱的客户反馈变成清晰的总结。最重要的是,你可以使用文中提到的方法在你的公司做出明智的决策,从而改进你的产品。

原文来源:https://www.intercom.com/blog

原文作者:GRAHAMÓMAONAIGH、SIAN TOWNSEND

编译:研如玉,神策数据·用户行为洞察研究院,公众号(ID:SDResearch)

本文由 @研如玉 翻译发布于人人都是产品经理,未经许可,禁止转载

题图来自Unsplash,基于CC0协议