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

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

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

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

图2：优化后的软件订购中心首页（原来无首页）

图3：优化后产品列表页

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

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

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

2．良好的团队协作，提升UED话语权

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

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

1.1前期数据

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

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

基础数据
包括原软件服务订购页面的PV、UV，订购的交易转换率，订购的成功率、失败率等数据。
业务数据
项目在规划好时，PD会事先知会交互设计师。然后PD会写PRD（需求文档），交互设计师在此时应开始准备调取部分相关数据，在本例中，调取数据如图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的态度。大家合作也就非常愉快！