数据与理论结合,让交互设计更专业【碳酸饮料会】

Part of TaobaoUED 碳酸饮料会讲稿 By 用户体验分析师:晓荷 |  交互设计师:老三 [2010/7/21]

Pay.taobao.com是淘宝卖家订购增值服务的平台,但该平台的可用性和操作体验欠佳,导致客服部门收到非常多来自卖家的订购服务咨询,压力很大,需要在系统层面解决此问题。因此发起了订购流程体验优化项目,对pay.taobao.com进行前后台改版。

图1:优化前的软件服务订购页面

图1:优化前的软件服务订购页面

图2:优化后的软件订购中心首页(原来无首页)

图2:优化后的软件订购中心首页(原来无首页)

图3:优化后产品列表页

图3:优化后产品列表页

优化之后,客服部门反馈数据显示,卖家咨询量由40%下降到7%。为此,与大家分享项目的两点经验:

1. 如何利用数据指导交互设计

  • 前期数据采集
  • 上线后数据分析
  • 用户反馈数据分析

2.良好的团队协作,提升UED话语权

  • 与非UED同事协作
  • 与UED同事协作

1.如何利用数据指导交互设计

1.1前期数据

知己知彼,百战不殆。常说为中间用户设计,只有熟悉数据,了解数据,才知道谁是我们设计的中间用户。通常,公司内部都会有数据部门,也会有后台系统。作为交互设计师,你应该有不少于业务线产品经理(PD)的内部权限,这样才能为设计和决策提供各种数据作为支持。

在制作软件服务订购中心时,我采集了以下几种数据

  • 基础数据
    包括原软件服务订购页面的PV、UV,订购的交易转换率,订购的成功率、失败率等数据。
  • 业务数据
    项目在规划好时,PD会事先知会交互设计师。然后PD会写PRD(需求文档),交互设计师在此时应开始准备调取部分相关数据,在本例中,调取数据如图4所示。此份定量数据非常重要,对于后期用研的介入、设计的参考都起了很大的作用。
图4 软件服务订购用户数据图4 软件服务订购用户数据

服务订购量的人群分布服务订购量的人群分布

不难看出

  • 软件服务订购主要由拥有X个(由于保密性,该数据不能透露)服务的会员所购买,核心消费人群为拥有X个服务的会员。
  • 大多数会员拥有的软件服务数为X。

以上数据为前期设计提供了可靠的依据。访问量的多少、用户使用此页面的目标决定了页面的最后设计结果,以及设计该页面时投入的成本。同时,这些数据对于可用性测试的目标用户筛选,提供了明确的指导。

1.2上线后数据

“任务可被完成  任务在无外界影响下可以被完成。”

《交互设计实用指南》使用指南总则  by 青云

要知道我们的用户任务是否可完成,就得监控关键页面:订购成功与订购失败页面。软件服务订购中心的一个重要指标是充值的成功率和失败率。

http://pay.taobao.com/account/payError.htm充值失败页面

我们来看一下上线初始的1个多月来,出错页面的访问量:

上线初始出错页面访问量上线初始出错页面访问量

可以看到,在上线初期,用户支付的失败率非常高,我们来分析一下当时的页面流程。

第一步:输入金额,弹出浮出层

第一步:输入金额,弹出浮出层

第二步:点击去支付宝付款

第二步:点击去支付宝付款

第三步:弹出支付宝页面,付款完成后在旧有页面点击任意按钮,判断支付状态。

第三步:弹出支付宝页面,付款完成后在旧有页面点击任意按钮,判断支付状态。

看过此流程,大家不难发现,第二步有点多余,为什么不直接进入第三步呢?其实第二步的增加是为了解决支付失败率高。直觉反应应该是弹出层的问题,经 过分析,一些浏览器会阻挡非用户主动激发的弹出页面,故用户点击充值后并未弹出支付宝页面,用户就疑惑了,并随意点击一个按钮,从而导致出错页面访问量 高。

此处优化以后,错误页面的访问量有非常明显的下降。

优化后访问数据

1.3用户反馈数据

与用户对话,了解你的用户是咋想的,并逐渐的改进产品。与开发、PD、PM共同协商问卷想采集的数据后,再与用研同学合作,他们会整理出合适的题目。特别是一些设计中担心的小点,如页面载入速度、CDN速度等、信息架构等。这份在线问卷的入口放置在订购中心首页左侧。

问卷访问入口

打开后,是一份半开放、半封闭式的问卷。

问卷详情

用研同学会将这些数据整理好,并出具报告。内容包括定量与定性统计两部分。来自用户的一手反馈能证明团队的工作,还能为后续优化指明方向。

用研报告

用户反馈文字很小

用户反馈文字很小

收到用户反馈字体很小。查看页面数据,发现软件订购中心的访问者中,大分辨率的用户是1024X768用户的2倍以上!于是他们做了专门的界面优化。

访问者显示器分辨率分布图

2.良好的团队协作,提升UED话语权

2.1从非UED的角度去分析问题(与非UED同事协作)

记得一位朋友讲过,要是两情侣吵架,闹得不可开交那种。你重复她的话,她来重复你的话,两人会觉得很搞笑,自然矛盾也就和解了。

生活如是,工作上也如是。运营、PD、前端、测试、开发要求的东西,你换位思考一下,也自然理解为什么了,也不会去瞎闹腾了。如果你没有这些职位的经验,多和PD、运营交流,类似行业的变身还是很容易。

掌握与PD\PM\开发测试人员沟通的语言

为了与PD、PM、开发、架构师更好地沟通需求,笔者在完成交互设计任务之外,还专门去了解了后台复杂的计费模型、产品定义模型,这样才能更好地了解什么功能能做到,什么功能不能做到,时,其他项目组成员才不会认为你是一个啥都不知道、只会空谈体验的傻逼。

这些底层知识,在原型设计时发挥了相当大的作用。

例如,通过了解预付费模型、后付费模型。在设计计费详单、续费详单时会更加清晰,能更清楚的向用户展现整个收费过程。

站在架构师的角度讨论体验

旧版的订购列表页面将所有服务罗列出来,操作中的订购按钮无论订购与否、一直有效。用户点击订购按钮后,根据用户权限判断进入订购页面或者错误页面。用户可能多次点击均返回错误页面,体验十分糟糕。

旧版订购体验

为了减少用户的不必要操作,在新版的订购中心,用户在浏览增值产品列表页时,订购与否的逻辑判断移动到该页面(进入产品详情页前),如果你没有购买权限,会在最开始就提示不能购买原因。同时,根据是否可续费显示续费按钮状态;根据是否可升级显示升级状态,并提示用户原因。

新版订购列表操作栏

正是这样,提高了订购流程了满意度。减少订购中的咨询而增加了订购前的咨询。但页面需要根据每个用户的订购情况来分析应该显示的效果,架构师提出页面展现性能的担忧。该担忧是必要的。与前端交流后提出以下方案,并结合线上数据做分析:

方案1:页面通过后台计算好之后再返回。前端工程师无需任何工作,缺点是用户看到的页面时间会增加。列表页面是否针对每个用户做出独立计算,将其所有的服务状态读取出来。我们可以参考之前采集的页面PV数据得到以下分析:

请求量:?,000,000*1*40 = ?,000,000;不考虑网速的情况下,页面响应相比另一种方案增加200+ms。另外根据页面PV、UV数据,服务器完全可承受该压力。

方案2:页面渲染与服务订购状态异步渲染。即用户会首先看到整体界面,个性化软件服务状态在1S以内会根据用户 具体情况调整。异步获取数据在淘宝的商品详情页面有使用,适用于页面量大,用户逐步接受数据页面。缺点是前端工程师需要增加额外工作。再者,如根据是否绑 定手机来判断是否开放短信订购入口这些情况,计费系统本身无法判断,需要调取外部接口,开发成本异常高。故决定只枚举计费系统情况,覆盖了80%以上的权 限情况。

综合考虑前端、开发成本,由当前页面PV等情况,最终选择了方案1。通过后续用户反馈入口收集到的数据:只有少量用户反馈访问速度慢。这次改进是有效的。

与运营合作

设计界面时,就想到营销手段。做产品列表页面时,想想运营的同事如何在这个列表上完成他们的营销目标?其实很简单,是大家也都能想到的,在超市里面 看到特别需要促销的商品会贴上折扣的信息,于是利用UED的技能,为运营提供一些促销技巧。这不是特牛的事,但表达了UED的态度。大家合作也就非常愉 快!

促销图标

促销图标线上效果

2.2与UED同事协作

作为一个平台,当其他服务接入时,我们通常希望其他交互设计师、视觉设计师能做出符合要求的图标。当该产品转交到其他人手里时,让他们理解你的思 想,就CODING时候的注释一样,写在里面。方便他人,尊重他人,是为了自己得到尊重。因此,在我的原型里,除了页面,还加入了大量的注释。

AXURE目录树

文案说明,统一平台的介绍语言。

文案说明,统一平台的介绍语言。

图标接入说明,为接入其他软件服务时视觉统一做准备。

图标接入说明,为接入其他软件服务时视觉统一做准备。

模块规范,前端有了这个,思考全局组件时更轻松。

模块规范,前端有了这个,思考全局组件时更轻松。

3.总结……

通过前期数据采集、上线后数据分析、用户反馈数据分析等方法指导交互设计,在与UED、非UED同事的良好的团队协作,最终提升了UED话语权。让交互设计师走向专业、品质、协同

相关文章

One response on “数据与理论结合,让交互设计更专业【碳酸饮料会】

  1. 的确学到不少东东哈~

    看来交互能起到指导项目进行的作用,需要和前后端沟通交流~

Comments are closed.