数据与理论结合，让交互设计更专业

　　PartofTaobaoUED碳酸饮料会讲稿By用户体验分析师：晓荷交互设计师：老三〔2010721〕
　　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青云
　　要知道我们的用户任务是否可完成，就得监控关键页面：订购成功与订购失败页面。软件服务订购中心的一个重要指标是充值的成功率和失败率。
　　充值失败页面
　　我们来看一下上线初始的1个多月来，出错页面的访问量：
　　上线初始出错页面访问量
　　可以看到，在上线初期，用户支付的失败率非常高，我们来分析一下当时的页面流程。
　　第一步：输入金额，弹出浮出层
　　第二步：点击去支付宝付款
　　第三步：弹出支付宝页面，付款完成后在旧有页面点击任意按钮，判断支付状态。
　　看过此流程，大家不难发现，第二步有点多余，为什么不直接进入第三步呢？其实第二步的增加是为了解决支付失败率高。直觉反应应该是弹出层的问题，经过分析，一些浏览器会阻挡非用户主动激发的弹出页面，故用户点击充值后并未弹出支付宝页面，用户就疑惑了，并随意点击一个按钮，从而导致出错页面访问量高。
　　此处优化以后，错误页面的访问量有非常明显的下降。
　　1。3用户反馈数据
　　与用户对话，了解你的用户是咋想的，并逐渐的改进产品。与开发、PD、PM共同协商问卷想采集的数据后，再与用研同学合作，他们会整理出合适的题目。特别是一些设计中担心的小点，如页面载入速度、CDN速度等、信息架构等。这份在线问卷的入口放置在订购中心首页左侧。
　　打开后，是一份半开放、半封闭式的问卷。
　　用研同学会将这些数据整理好，并出具报告。内容包括定量与定性统计两部分。来自用户的一手反馈能证明团队的工作，还能为后续优化指明方向。
　　用户反馈文字很小
　　收到用户反馈字体很小。查看页面数据，发现软件订购中心的访问者中，大分辨率的用户是1024X768用户的2倍以上！于是他们做了专门的界面优化。
　　2。良好的团队协作，提升UED话语权
　　2。1从非UED的角度去分析问题（与非UED同事协作）
　　记得一位朋友讲过，要是两情侣吵架，闹得不可开交那种。你重复她的话，她来重复你的话，两人会觉得很搞笑，自然矛盾也就和解了。
　　生活如是，工作上也如是。运营、PD、前端、测试、开发要求的东西，你换位思考一下，也自然理解为什么了，也不会去瞎闹腾了。如果你没有这些职位的经验，多和PD、运营交流，类似行业的变身还是很容易。
　　掌握与PDPM开发测试人员沟通的语言
　　为了与PD、PM、开发、架构师更好地沟通需求，笔者在完成交互设计任务之外，还专门去了解了后台复杂的计费模型、产品定义模型，这样才能更好地了解什么功能能做到，什么功能不能做到，时，其他项目组成员才不会认为你是一个啥都不知道、只会空谈体验的傻逼。
　　这些底层知识，在原型设计时发挥了相当大的作用。
　　例如，通过了解预付费模型、后付费模型。在设计计费详单、续费详单时会更加清晰，能更清楚的向用户展现整个收费过程。
　　站在架构师的角度讨论体验
　　旧版的订购列表页面将所有服务罗列出来，操作中的订购按钮无论订购与否、一直有效。用户点击订购按钮后，根据用户权限判断进入订购页面或者错误页面。用户可能多次点击均返回错误页面，体验十分糟糕。
　　为了减少用户的不必要操作，在新版的订购中心，用户在浏览增值产品列表页时，订购与否的逻辑判断移动到该页面（进入产品详情页前），如果你没有购买权限，会在最开始就提示不能购买原因。同时，根据是否可续费显示续费按钮状态；根据是否可升级显示升级状态，并提示用户原因。
　　正是这样，提高了订购流程了满意度。减少订购中的咨询而增加了订购前的咨询。但页面需要根据每个用户的订购情况来分析应该显示的效果，架构师提出页面展现性能的担忧。该担忧是必要的。与前端交流后提出以下方案，并结合线上数据做分析：
　　方案1：页面通过后台计算好之后再返回。前端工程师无需任何工作，缺点是用户看到的页面时间会增加。列表页面是否针对每个用户做出独立计算，将其所有的服务状态读取出来。我们可以参考之前采集的页面PV数据得到以下分析：
　　请求量：？，000，000140？，000，000；不考虑网速的情况下，页面响应相比另一种方案增加200ms。另外根据页面PV、UV数据，服务器完全可承受该压力。
　　方案2：页面渲染与服务订购状态异步渲染。即用户会首先看到整体界面，个性化软件服务状态在1S以内会根据用户具体情况调整。异步获取数据在淘宝的商品详情页面有使用，适用于页面量大，用户逐步接受数据页面。缺点是前端工程师需要增加额外工作。再者，如根据是否绑定手机来判断是否开放短信订购入口这些情况，计费系统本身无法判断，需要调取外部接口，开发成本异常高。故决定只枚举计费系统情况，覆盖了80以上的权限情况。
　　综合考虑前端、开发成本，由当前页面PV等情况，最终选择了方案1。通过后续用户反馈入口收集到的数据：只有少量用户反馈访问速度慢。这次改进是有效的。
　　与运营合作
　　设计界面时，就想到营销手段。做产品列表页面时，想想运营的同事如何在这个列表上完成他们的营销目标？其实很简单，是大家也都能想到的，在超市里面看到特别需要促销的商品会贴上折扣的信息，于是利用UED的技能，为运营提供一些促销技巧。这不是特牛的事，但表达了UED的态度。大家合作也就非常愉快！
　　2。2与UED同事协作
　　作为一个平台，当其他服务接入时，我们通常希望其他交互设计师、视觉设计师能做出符合要求的图标。当该产品转交到其他人手里时，让他们理解你的思想，就CODING时候的注释一样，写在里面。方便他人，尊重他人，是为了自己得到尊重。因此，在我的原型里，除了页面，还加入了大量的注释。
　　文案说明，统一平台的介绍语言。
　　图标接入说明，为接入其他软件服务时视觉统一做准备。