O2O模式是餐饮业在移动消费趋势下主动拥抱互联网的方向,迎合餐饮消费者从以往经验判断为主转变为依靠移动设备、lbs、社交网络进行立体决策的过程。继App客户端之后,手机web app也逐渐成为O2O中联系消费者和餐饮业的纽带,通过Html5的技术支持,web app设计可以直接适配不同平台的手机屏幕并实现类似App客户端的体验,在O2O双向流程的闭环中加深消费者对品牌的认同和感情认知。
日前必胜宅急送推出的手机订餐web正是其O2O模式的策略补充和深化。FaceUI提供的web app设计包含了对产品背后动机的挖掘和把握,随着项目团队对动机的理解和可用性测试的加深,设计思路也随之发生着变化。
产品的客户方动机
即为什么要进行这个web app设计,客户方(甲方)对此产品的定位和要求。不同定位的产品在功能或设计方向上会存在较大的差异。最常见的就是跟风型产品,如早期的各式IM、再到繁多的微博,还有如今火热的即时通讯工具,尤其移动平台的低成本高效率导致扎堆产品应接不暇。这样的产品更多是抱着分一杯羹或他有我也要有的心态定位,更注重被模仿对象的还原度,而不是个性特色。
必胜宅急送的web app则是定位于O2O方向的探索。相较于传统app客户端,手机web app可以较为轻松地实现跨平台的轻量级应用,脱离于app商店的web降低了初级用户或中老年群体的使用门槛。对客户方来说,依靠url作为入口,web app可以便利地利用公众平台、朋友圈等社交传播网络进行推广。所以虽然手机web app仍然存在一定缺陷,在扩展消费者接触面、提高品牌自身竞争力等方面也极有潜力,这也是产品的功能目标和期望。
图片1
产品的设计动机
除了实现产品功能概念外(有效性),另外的动机就是减少消费者从登录网站到预览下单的时间(效率)和让消费者接受并喜欢使用宅急送(满意度)。有效性、效率和满意度是评判产品可用性的标准,在以用户为中心的产品设计中作为衡量产品质量的指标。产品设计师基于对市场、用户、产品的理解和积累建立符合可用性诉求的价值倾向,并贯穿在产品之中。
固然好的设计师擅长如何让产品、功能与用户需求有机结合,但在有些问题上,难以避免与其他项目成员、与客户之间的分歧,这时候采用可用性测试对用户动机研究就成为判断的依据。
产品的用户动机
想要立即得到设计师、客户都满意又符合可用性要求的完美方案是不可能的,所以结合项目进度要求,设计团队引入了低保真原型的可用性测试进行循序渐进的设计迭代,力图通过探明用户的动机解决设计上的关键问题。
对于可用性测试的一个误解是,可用性测试需要花太多时间和金钱。误解的前提是一个成熟完整的测试可能需要若干天数进行准备和测试,再经过一定时间才能整理数据并得出分析结论,由此带来的时间成本和招募成本不利于项目进行。
图片2 低保真测试原型
宅急送web app设计团队在线框原型阶段利用AXURE制作手机上可以运行的低保真原型,穿插在设计中间进行快速的可用性测试。测试后的结果会及时反应在设计迭代上,成为下一轮可用性测试的材料或补充,几个额外的问题不会影响测试单元的时长。被测用户也就近从项目外的同事或朋友中筛选,测试任务结束后被测用户的满意度评价作为每轮的组成部分加以收集,最终形成有指导价值的数据样本库。
即使快速的迭代的低保真测试,招募的用户标准也非常重要,确保测试结果对产品的有效性。团队从宅急送品牌的产品特征、用户个性特征、生活方式和价值观、对技术产品态度几个方面考量,制定招募标准:年龄18-35,近半年网络订餐超过3次、智能手机使用时间超过半年、手机浏览器或app每周使用10小时以上等。
与招募同时进行的是测试脚本的设计,为被测用户赋予场景化的环境并梳理任务顺序以符合真实习惯。一种任务类型是观察,让用户熟悉界面并对界面进行反馈。另一种任务是操作,设置产品的典型任务如点三份芝香满溢比萨由用户完成。
因为线框原型在功能、视觉方面的局限性,用户的困惑点相比于上线后的测试可能更多,所以执行过程中的发声思考是非常有效的工具。比如首页某一版方案测试时,可以听到如下用户声音:
图片3 首页线框原型
“要不是看必胜宅急送的logo,我还以为是个图片类网页”
“我不清楚这个优惠活动图片跟优惠列表具体有什么分别”
“点击‘预览菜单’后以为会进入菜单,没想到还要再选一次菜品种类”
“我会首先看优惠列表中有没有自己喜欢的东西,如果有就直接订购”
其中部分困惑(1和2)是线框原型带来的测试“噪音”,难以对当前版本提供实际的启发和引导,但3和4则反应了首页在布局和任务流程上存在的问题。被测用户进行发声思考使得行为背后的内容,如理解、计划等转化成明确、能被观察或分析到的数据,沉默的内部心理行为可以帮助测试者从用户角度发现问题本质。
综合其他用户和后续迭代反馈,最终的首页方案如下:
图片4 首页效果图
设计师对原首页方案上的方向是:简洁明了,突出订餐点单的核心功能,并在首页呈现用户所需要使用的功能入口。但在测试中发现,用户进入首页后受三种不同方向的动机驱动:
(1)已有明确的订餐目的和菜品,首页需要解决的是快速完成下单流程;
(2)浏览型用户会期望还原线下餐厅一样随心所欲翻看菜单的体验,再确定菜品和下单与否;
(3)而对于利益型用户,优惠活动和优惠力度最容易勾起他们的购买欲望。
所以最终方案在保持订餐的核心功能外,对于不同的入口动机,利用web不局限一屏浏览的特点将菜品类目和优惠列表同时铺展,形成一个信息丰富的展示空间。
从测试中获得的另一项有价值的发现帮助解决了项目团队内部的分歧。点餐界面存在设计师出于不同考虑的方案:方案1(左边)从用户认知出发,点击“订购”后展现当前菜品数量并要求用户进行确认动作;方案2(右边)站在效率的思路,简化点餐的操作步骤,点击即增加一份菜品,并利用角标的方式帮助用户了解当前数量。
图片5 订餐页面线框原型
统计测试数据后,看起来更复杂的方案1的相关任务完成率较高,对比采用方案2的任务完成率较低,被测用户的发声思考也验证了这个结果:被测用户在使用方案1时更明确衔接动作,而对方案2会产生疑惑。
方案1中下单的操作比方案2多了至少2步,但整体流程上清晰明确,就像线下点餐那样,对每个菜品的数量予以确认,用户*度较小,很难从当前菜品选择中跳出去。购物车的存在允许用户前往结算界面并支付,弥补了解总体订单情况的便利性。
方案2最大的优势是在单品数量较少(一份披萨的量较大)的情况下有较高的操作效率,在熟悉操作的情况下即使多份也不逊于方案1。但是随意点击就增加菜品带来的*度让用户感觉会偏离任务,可以通过购物车减少菜品数量对用户来说也是个隐藏操作,所以用户很容易在方案2中产生困惑。
最终上线的点单界面如下:
图片6 订餐页面效果图
终版利用上方的悬浮通知优化了方案1不方便查看订单总量的缺点。用户的动机是获得需要的菜品,所以不经确认的下单动作会让用户失去安全感。对于符合用户思维模式的流程,即使步骤略多,在执行时因为习惯或直觉的引导也不会带来太多注意力的分散或负担。用户未必能感受到方案2带来的效率提高,但一旦出现不完善就会招致不满。
同样在用户不需要为单一目标集中注意力的时候,特意突出的元素也是画蛇添足。这是被否决的一个结算界面原型:
图片7 结算页面线框原型
App客户端的样式不适合web app,网站上悬浮按钮的设计让用户感受不快,过大的面积也影响清单的查看。用户并不是任何时候都准备下单,只有在核对完自己的菜品和数量,形成支付期望后,“确认下单”才会成为他们准备点击的对象。
结语
对动机的挖掘并不是非黑即白的单选项。在低保真原型测试的支持下,通过动机把握,确定产品哪些元素是有益的,哪些元素是无益的,最终形成效果显著的产品方案,获得品质和效率上的双赢。
感谢李永伦对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。
必胜宅急送Web app设计背后的思考的更多相关文章
-
聊聊Web App、Hybrid App与Native App的设计差异
目前主流应用程序大体分为三类:Web App.Hybrid App. Native App. 一.Web App.Hybrid App.Native App 纵向对比 首先,我们来看看什么是 Web ...
-
超赞!聊聊WEB APP、HYBRID APP与NATIVE APP的设计差异
编者按:这3类主流应用你都了解吗?设计师除了要有视觉功夫,对不同形式的APP也应当了然于胸,今天百度的同学写了一篇非常全面的总结,帮你迅速搞定3类主流APP的设计方法,附带一大波避雷针,带你巧妙跳过A ...
-
如何设计和实现一个web app
web app简介 web app其实不算是什么新鲜的东西,相比于传统的web和传统的app,web app这种web和app相结合的产物有的优点如下: 1. 开发上web app更有便捷性,ios开 ...
-
Web App、Hybrid App与Native App的设计差异
目前主流应用程序大体分为三类:Web App.Hybrid App. Native App. 一.Web App.Hybrid App.Native App 纵向对比 首先,我们来看看什么是 Web ...
-
对WEB前端的几段思考(一)——界面设计和性能优化(整理中)
尽管我并非艺术出生,既没有任何设计基础,又没有较高艺术涵养,也深谙在短时间内创造一定艺术造诣并非易事,但是既然当初选择从事网站前端开发,我的目光不能仅停留在前端代码上.作为一名志向在前端领域发展的人员 ...
-
聊聊Web App、Hybrid App与Native App的设计差异(转)
目前主流应用程序大体分为三类:Web App.Hybrid App. Native App. 一.Web App.Hybrid App.Native App 纵向对比 首先,我们来看看什么是 Web ...
-
[转帖]聊聊Web App、Hybrid App与Native App的设计差异
聊聊Web App.Hybrid App与Native App的设计差异 https://www.cnblogs.com/zhuiluoyu/p/6056672.html 编者按:这3类主流应用你都了 ...
-
对Native App与Web App的一些思考
前言 Native App:C/S架构,使用原生技术(Java/Objective-C/Swift)实现. Web App:B/S架构,使用浏览器技术来实现,广义上也包括phoneGap以及DP正在尝 ...
-
12步创建高性能Web APP
现在,Web App 日益重视用户的交互体验,了解性能优化的方式则可以有效提高用户体验.阅读和实践下面的性能优化技巧,可以帮你改善应用的流畅度.渲染时间和其他方面的性能表现. 概述 对 Web App ...
随机推荐
-
iOS - 分析JSON、XML的区别和解析方式的底层是如何实现的(延伸实现原理)
<分析JSON.XML的区别,JSON.XML解析方式的底层是如何实现的(延伸实现原理)> (一)JSON与XML的区别: (1)可读性方面:基本相同,XML的可读性比较好: (2)可扩展 ...
-
[iOS]ReactiveCocoa安装方法
1. 替换Ruby镜像 我们想要使用CocoaPods来安装ReactiveCocoa.由于OS X上的Ruby镜像被墙了,感谢淘宝为我们提供了国内访问镜像. $ gem sources --remo ...
-
到处都是坑的微信支付V3之 微信支付回调页面
据上次 到处都是坑的微信支付V3 后很多园友在被虐了千百遍后终于跳转到了亲切的微信支付界面,但输入密码支付后却不知道怎么处理了,接下来补上支付后的处理流程. 1. html中根据前台支付后反馈信息成功 ...
-
sql之连表查询--效率 通过分析各种连接查询的实现原理来了解
1. 左连接 2.右连接 3.内连接 4.Cross join 笛卡尔乘积
-
C# using的一些事
一.using释放资源 using不可以释放所有的对象,原因如下: 1.using可以主动释放的对象都需要实现IDisable接口. 2.即使都实现了IDisable接口,也没有必要全部使用using ...
-
opencv 在工业中的应用:二维标定
在工业中经常要检测一个零件的尺寸,但是图像处理得到的是像素值,怎么才能得到实际的毫米值呢?这就要用到二维标定,我用OPENCV写了一个利用标定板进行标定的DEMO. 很多商业软件都没有二维标定的功能, ...
-
django之uWSGI配置 +Nginx
参考文档 官方文档 安装: pip install uwsgi 启动命令: 方法一.直接命令启动 /home/zabbix/application/python/bin/uwsgi --socke ...
-
SQL去掉小数点有效数字后的所有0
原文:SQL去掉小数点有效数字后的所有0 第一种方法 select cast(2.5000000000000 as real) select cast(2 as real) select ...
-
强制修改mysql 中root的密码
/etc/init.d/mysqld stop (service mysqld stop )/usr/bin/mysqld_safe --skip-grant-tables另外开个SSH连接[ro ...
-
python线程condition条件锁应用实例
import time import threading # 吃火锅鱼丸 guo = [] suo = threading.Condition() #条件锁 # 生产者负责生产 class Produ ...