做更好的自己 网站,中山建设银行招聘网站,煤棚网架公司,微博通 for wordpressO2O模式是餐饮业在移动消费趋势下主动拥抱互联网的方向#xff0c;迎合餐饮消费者从以往经验判断为主转变为依靠移动设备、LBS、社交网络进行立体决策的过程。App成为联系消费者和餐饮业的重要纽带#xff0c;承载着在O2O双向流程的闭环中加深消费者对品牌的认同和感情认知的…O2O模式是餐饮业在移动消费趋势下主动拥抱互联网的方向迎合餐饮消费者从以往经验判断为主转变为依靠移动设备、LBS、社交网络进行立体决策的过程。App成为联系消费者和餐饮业的重要纽带承载着在O2O双向流程的闭环中加深消费者对品牌的认同和感情认知的作用。 FaceUI与必胜宅急送合作推出的手机订餐web版是对其O2O策略的补充和深化通过Html5的技术支持手机web可以直接适配手机屏幕并实现类似App客户端的体验。整个产品的实现过程就是对产品背后动机的挖掘和把握随着项目团队对动机的理解设计思路也随之发生了转化。 产品的客户方动机 即为什么要做这个产品客户方对此产品的定位和要求。不同定位的产品在功能或设计方向上会存在较大的差异最常见的就是跟风型产品如早期的各式IM、再到繁多的微博还有如今火热的即时通讯工具尤其移动平台的低成本高效率导致扎堆产品应接不暇。这样的产品更多是抱着分一杯羹或他有我也要有的心态定位更注重被模仿对象的还原度而不是个性特色。 必胜宅急送的手机web则是定位于O2O方向的探索。相较于传统本地app手机web app可以较为轻松地实现跨平台的轻量级应用脱离于app商店的web降低了初级用户或中老年群体的使用门槛。对客户方来说依靠url作为入口手机web可以便利地利用公众平台、朋友圈等社交传播网络进行推广。所以虽然手机web app仍然存在一定缺陷在扩展消费者接触面、提高品牌自身竞争力等方面也极有潜力这也是产品的功能目标和期望。 产品的设计动机 除了实现产品功能概念外有效性另外就是要减少消费者从登录网站到预览下单的时间效率和让消费者接受并喜欢使用宅急送满意度。有效性、效率和满意度是评判产品可用性的标准在以用户为中心的产品设计中作为衡量产品质量的指标。产品设计师基于对市场、用户、产品的理解和积累建立符合可用性诉求的价值倾向并贯穿在产品之中。 固然好的设计师擅长如何让产品、功能与用户需求有机结合但在有些问题上难以避免与其他项目成员、与客户之间的分歧这时候对用户动机的研究就成为判断的依据。 产品的用户动机 想要立即得到设计师、客户都满意又符合可用性要求的完美方案是不可能的所以结合项目进度要求设计团队引入了低保真原型的可用性测试进行循序渐进的设计迭代力图通过探明用户的动机解决设计上的关键问题。 对于可用性测试的一个误解是可用性测试需要花太多时间和金钱。误解的前提是一个成熟完整的测试可能需要若干天数进行准备和测试再经过一定时间才能整理数据并得出分析结论由此带来的时间成本和招募成本不利于项目进行。 宅急送手机web的设计团队在线框原型阶段利用AXURE制作手机上可以运行的低保真原型在中间阶段进行快速的可用性测试。测试后的结果会及时反应在设计迭代上成为下一轮可用性测试的材料或补充几个额外的问题不会影响测试单元的时长。被测用户也就近从项目外的同事或朋友中筛选测试任务结束后被测用户的满意度评价作为每轮的组成部分加以收集最终形成有指导价值的数据样本库。 即使快速的迭代的低保真测试招募的用户标准也非常重要确保测试结果对产品的有效性。团队从宅急送品牌的产品特征、用户个性特征、生活方式和价值观、对技术产品态度几个方面考量制定招募标准年龄18-35近半年网络订餐超过3次、智能手机使用时间超过半年、手机浏览器或app每周使用10小时以上等。 与招募同时进行的是测试脚本的设计为被测用户赋予场景化的环境并梳理任务顺序以符合真实习惯。一种任务类型是观察让用户熟悉界面并对界面进行反馈。另一种任务是操作设置产品的典型任务如点三份芝香满溢比萨由用户完成。 因为线框原型在功能、视觉方面的局限性用户的困惑点相比于上线后的测试可能更多所以执行过程中的发声思考是非常有效的工具。比如首页某一版方案测试时可以听到如下用户声音 “要不是看必胜宅急送的logo我还以为是个图片类网页” “我不清楚这个优惠活动图片跟优惠列表具体有什么分别” “点击‘预览菜单’后以为会进入菜单没想到还要再选一次菜品种类” “我会首先看优惠列表中有没有自己喜欢的东西如果有就直接订购” 其中部分困惑1和2是线框原型带来的测试“噪音”难以对当前版本提供实际的启发和引导但3和4则反应了首页在布局和任务流程上存在的问题。被测用户进行发声思考使得行为背后的内容如理解、计划等转化成明确、能被观察或分析到的数据沉默的内部心理行为可以帮助测试者从用户角度发现问题本质。 综合其他用户和后续迭代反馈最终的首页方案如下 设计师对原首页方案上的方向是简洁明了突出订餐点单的核心功能并在首页呈现用户所需要使用的功能入口。但在测试中发现用户进入首页后受三种不同方向的动机驱动 1已有明确的订餐目的和菜品首页需要解决的是快速完成下单流程 2浏览型用户会期望还原线下餐厅一样随心所欲翻看菜单的体验再确定菜品和下单与否 3而对于利益型用户优惠活动和优惠力度最容易勾起他们的购买欲望。 所以最终方案在保持订餐的核心功能外对于不同的入口动机利用web不局限一屏浏览的特点将菜品类目和优惠列表同时铺展形成一个信息丰富的展示空间。 从测试中获得的另一项有价值的发现帮助解决了项目团队内部的分歧。点餐界面存在设计师出于不同考虑的方案方案1左边从用户认知出发点击“订购”后展现当前菜品数量并要求用户进行确认动作方案2右边站在效率的思路简化点餐的操作步骤点击即增加一份菜品并利用角标的方式帮助用户了解当前数量。 统计测试数据后看起来更复杂的方案1的相关任务完成率较高对比采用方案2的任务完成率较低被测用户的发声思考也验证了这个结果被测用户在使用方案1时更明确衔接动作而对方案2会产生疑惑。 方案1中下单的操作比方案2多了至少2步但整体流程上清晰明确就像线下点餐那样对每个菜品的数量予以确认用户自由度较小很难从当前菜品选择中跳出去。购物车的存在允许用户前往结算界面并支付弥补了解总体订单情况的便利性。 方案2最大的优势是在单品数量较少一份披萨的量较大的情况下有较高的操作效率在熟悉操作的情况下即使多份也不逊于方案1。但是随意点击就增加菜品带来的自由度让用户感觉会偏离任务可以通过购物车减少菜品数量对用户来说也是个隐藏操作所以最终用户很容易在方案2中产生困惑。 最终上线的点单界面如下 方案1缺少了解订单总量的缺点利用上方的悬浮通知优化。用户的动机是获得需要的菜品所以不经确认的下单动作会让用户失去安全感。对于符合用户思维模式的流程即使步骤略多在执行时因为习惯或直觉的引导也不会带来太多注意力的分散或负担。用户未必能感受到方案2带来的效率提高但一旦出现不完善就会招致不满。 同样在用户不需要为单一目标集中注意力的时候特意突出的元素也是画蛇添足。这是被否决的结算界面原型 本地app的样式不适合web app网站上悬浮按钮的设计让用户感受不快过大的面积也影响清单的查看。用户并不是任何时候都准备下单只有在核对完自己的菜品和数量形成支付期望后“确认下单”才会成为他们准备点击的对象。 结语 对动机的挖掘并不是非黑即白的单选项。在低保真原型测试的支持下通过动机把握确定产品哪些元素是有益的哪些元素是无益的最终形成效果显著的产品方案获得品质和效率上的双赢。转载于:https://www.cnblogs.com/helenR/p/web_app_zhaijisong.html
