可用性测试实践
蜗牛邦的v1.0版网站伴着攻城狮们的娇喘上线了。网站中间层用了CI框架，前端用jQuery来异步调用API，页面用了Bootstrap的框架，通过响应式的方式来支持移动和桌面。
API按照RESTful的方式来设计，给以后移动应用留好了口子。
管理界面就直接用了CI来读取和存入数据，没有通过API（丰满的理想是所有数据交互都走API，但骨感的现实是实在TMD来不及了）
第一个版本速度是第一要务，就没有找UI设计师做设计，能精简的地方全部精简，所以这个版本就很有工程师的味道，连按钮和控件的样式都直接使用了bootstrap的默认样式。
我又当了把特种兵：从前期整理需求，到线框图，再到Web前端开发，和Web大牛Xavi同学一起死磕了n个晚上。12月份有一大半时间是睡在公司的。14年底前总算是踉跄上线，两周左右的试运营期间发现解决了各种问题，目前客服总算是能完成磨合。
但是，有众多取消订单情况发生，客服追访后发现有部分用户反应
- 难用 - 找不到自己想要的东西
- 可信度低 - 感觉是骗子网站，不敢在网站上付钱（其实我也是这么觉得的，只是需要想清楚该怎么改）
看来是时候做一次可用性测试了。我感觉我自己知道问题所在，但是，最近接受了如下教导，所以还是测测为妙。
Following conventional wisdom and replying on shortcuts can be worse than knowing nothing at all. - Ben Horowitz, "The Hard Thing About Hard Things"
先插播招聘广告一条 《PHP小牛速来! 旅游+互联网跨界合体巨兽之蛋! 错过途牛，再错过蜗牛邦吗?》
测试目标
- 寻找信任度低的症结所在
- 发现用户在关键任务路径上遇到的使用障碍
- 发现其他交互上的问题
测试参数
- 蜗牛邦网站（PC版）
- 第一次使用网站，想订购某个目的地旅游产品的用户
- 伴随焦点小组一同进行
测试任务
- （测试对象都有普吉岛旅游的经历）购买上一次去普吉岛时您没有去过但是最想去玩的当地旅游项目；出行人数同上一次出行人数；
- 鼓励用户在使用的过程中think-out-loud。
数据处理
理清楚网站最重要的功能模块
原始的测试记录 - 录音和笔记
按照模块和优先级归类排序后的用户反馈
- 由于任务设定的原因，大部分的反馈集中在产品详情页面和支付流程，其他模块和页面没有设计对应的测试
发现1 - 首页 - 搜索
用户：“我就买丛林飞跃吧”，
在搜索框输入关键词“普吉岛 骑大象”，没有搜索结果。
“没这个产品？！”，换个关键词“普吉岛”，
“靠，这么多，那就搜骑大象吧“
终于找到了
改进办法：搜索功能仅仅能按照输入的关键词做搜索，不能按照对关键词进行简单的分词（按照空格分开）做复合查询。
发现2 - 商品详情 - 走马灯图片
”图好少才4张，而且好单调“
”没有预览用的小图，如果有小图我会更愿意点“
”按照我一般的网购习惯（淘宝）我会先往下面看“，滚动鼠标，”不大会关注这个走马灯的图，但是，但是这个详情介绍未免也太简单了吧！而且都是文字，懒得看，我先看看图吧。”
发现3 - 商品详情 - 没有评价系统
“怎么没有买家的评价？！怎么没有最近成交记录？！不敢买了！”
发现4 - 商品详情 - 套餐没法放在一起比较
"套餐详情还要到产品详情里面才能看到，上下滚好麻烦啊！"
发现5 - 注册
“要登录啊？你有注册好的账号么？”
"额，还要注册啊！可以用微信登录么？尼玛，尽然没有第三方登录！" （其实已经开发好了，可用性测试的时候没有Release出来）
发现6 - 支付流程
没有用户会去关心或者填写真实姓名
“还要我手机号码！～”
“只能用支付宝么？”
P.S. 再重复插播招聘广告一条 《PHP小牛速来! 旅游+互联网跨界合体巨兽之蛋! 错过途牛，再错过蜗牛邦吗?》
