简化操作不恒等于提升体验

日期: 2010年1月25日 | 分类： 交互设计

在许多时候，简化用户的操作可以很大程度的提升用户体验，但绝不能就此视之为“金科玉律”，某些场景下，过于便捷的操作，反而会让用户产生挫败感，最近在支付方式页面，某个细节的设计上设计师们进行了激烈的讨论，讨论的过程中些许感悟和想法，草草记下。

先简单描述一下要实现的交互：用户先选择设置，然后在弹出的选择层中设置的银行账户，选定后，系统将所选信息更新到图中“未设置”区域，选择层随后自动消失。要实现的功能很简单，接下来我们看A，B两个设计方案：

收银台白板

两个方案唯一的区别就在于，用户选择单选框后，是否需要再多一步确认的操作。传统概念上，大家自然会选择简化用户操作的方案B，但是在这种场景下用户如B方案操作的话，一旦点击选择层中的任一选项，系统都会认为这是用户最终的决定，随即就会更新信息。如果用户无意识随意点选两下的话，那么当他点中一个选项时，可能会惊讶的发现信息已经被更新了。一切都在瞬间完成了，太过突然。更要命的是，选择层随后也消失了。当发现“杯具”发生后，用户只能重新点击设置，触发选择层，然后再选择一次。相比之下方案A的实现，用户虽然多了一步操作，但正是这步操作，让用户在得到系统反馈信息的时候，不至于太意外，一切都符合用户的预期……

查看全文 »

Tags： , , | 评论[6] | 共有 556次浏览

随感协作开发的JS设计模式

日期: 2010年1月1日 | 分类： 前端开发

从最原始需求出发，我们必须有一个最简单的实现类，这个类必须是可继承的。方便之后不同的业务需要做不同的扩展。我们必须确保这个类的稳定性。

简单实现类的定义：鼠标点击触发某容器，不带任何辅助效果。我们来想想，这么简单的一个类，需要包含哪些方法，搭个骨架出来：

  1. AP.widget.basic = new AP.Class({
  2.   setOptions:function(options){
  3.     //接口设置
  4.   },
  5.   initialize:function(targets,options){
  6.     //初始化方法，目的是建立targets子集元素和某方法的关联 
  7.   },
  8.   getVessel:function(target){
  9.     //获取满足target映射关系的容器 
  10.   },
  11.   bindEvents:function(target,vessel){
  12.     //这里绑定target的触发动作
  13.   },
  14.   action:function(){
  15.     //target绑定的事件触发的执行函数，包含你要执行的逻辑 
  16.   },
  17.   show:function(){
  18.     //显示容器 
  19.   },
  20.   hide:function(){
  21.     //隐藏容器 
  22.   },
  23. })

这是所有满足本文定义的简单实现类所需的基本方法，我们可以将它作为一个基础方法，方便满足简单类定义的交互形式在此基础上扩展，然后我们开始归纳常用的满足简单类定义的交互形式，如：tab切换，气泡提醒，下拉列表，xbox……

查看全文 »

Tags： , , | 评论[8] | 共有 577次浏览

有感用户体验规划与系统实现

日期: 2009年11月1日 | 分类： 交互设计

最近一直在“深山老林”中修炼“支付宝新版收银台”,经历了白板设计，视觉设计，前端开发，前后端联调各个阶段。点点滴滴……

重点谈谈对交互设计的感受吧：个人觉得设计师应该好好的思考一下收银台的设计粒度，在我们不能确定用户是否会遇到某类问题时，不妨放开怀抱，将粒度切的大一些，如果一味的把自己当作用户，患得患失，其结果只会把自己的产品绑成个大粽子，这样很可能导致在不明确具体问题的情况下，设计粒度过细。到后期再想优化，就举步为艰了。

个人非常反对，设计师总是以“我觉得用户可能”，“我觉得用户一定”的论调在设计讨论中去说服需求方，“觉得”只是一种推测，既然不能确定用户会遇到你假设的问题，那为什么不能先把设计粒度切大一些，等产品上线，观察分析用户使用的情况后，再对症下药呢？究其原因，是因为设计师太怕用户受挫，关心则乱下失去了一些设计原则。我想，在不影响用户正常操作的情况下，对于一些假设的受挫场景，不妨放手一试，用户不犯错，你又怎么知道自己的产品问题在哪里呢。知错而改之，总比一辈子都活在自己“觉得”的世界里强。更何况未必错！

说了这么多，其实只是想引出一个话题，作为一个优秀的设计师，必须学会“如何均衡用户体验和系统实现”，要知道你设计的是一款产品，你必须对他的未来有一个规划，而这个规划，用户体验和系统实现之间的关系是非常微妙的。常常听到很多设计师再抱怨“我想到个很好的体验改进点子，但是开发告诉我系统实现不了，郁闷！”有没有想过为什么？我想很大一个原因就是因为前期设计粒度过细，到后面瓜就不好切了~~呜呼哀哉！总之一句话：“该有的体验一个也不能少，该有的原则同样不能少！”粒度要怎么切，很有学问，需要在不断的实践中去体会。

说到如何均衡体验和系统实现，不妨拿新老收银台做个比较，个人觉得非常有说服力,我们从老收银台现有问题着手分析一下:

收银台白板

查看全文 »

Tags： , , | 评论[12] | 共有 584次浏览

小议javascript设计模式

日期: 2009年10月8日 | 分类： 前端开发

最近重新温习了一次《javascript设计模式》，确实是一本好书，每次看都有不同的领悟，每次领悟到的都受益匪浅，无怪古圣人都说学无止镜了，仅以“加油，好吗？”共勉！

记得早前就说过要和大家分享“javascript设计模式”,迟迟没写不是因为我懒，最近确实太忙，忙工作，忙旅游（啊哦？），好不容易这几天空闲了，接下来是兑现之前空口白话的时间了。

在讨论设计模式之前，请确认您已经有一定的脚本编程基础，如果不甚了解，建议可以先查阅本人很久之前写的这篇《浅谈javascript面向对象编程》。

讲到设计模式，不得不先重点着墨于“接口设计”，因为接口设计在设计模式中的意义太大了，大于模式本身。直观起见，先介绍一下接口定义的形式：

  1. var interface = new Interface("interface",[["getName",1],["getAge",1]]);

可以看出接口函数必须包含两个参数，接口方法定义在一个二维数组中。上例中定义了两个接口方法：getName,getAge,这两个方法都带一个参数，下面我们详细看一下Interface函数的实现代码，从而加深大家对接口的理解。

  1. function Interface(name,methods){
  2.     if(arguments.length !=2){
  3.       console.log("参数必须为二个");
  4.     }
  5.     this.name = name;
  6.     this.methods = [];
  7.     if(methods.length<1){
  8.      console.log("第二个参数不能为空数组");
  9.     }
  10.     for(var i=0;len=methods.length,i<len;i++){
  11.       if(typeof methods[i][0] !== 'string'){
  12.           console.log("第一个参数数据类型必须为字符串");
  13.       }
  14.       if(methods[i][1] && typeof methods[i][1] !== 'number'){
  15.          console.log("第二个参数数据类型必须为整数型");
  16.       }
  17.       if(methods[i].length == 1){
  18.           methods[i][1] = 0;
  19.       }
  20.       this.methods.push(methods[i]);
  21.     }
  22.   }

查看全文 »

Tags： , , , , | 评论[11] | 共有 632次浏览

量化用户体验设计讨论引发的思考

日期: 2009年7月24日 | 分类： 交互设计

本周参与了“如何量化用户体验设计”的讨论，感慨万千……

不记得什么时候曾经看过一则新闻：欧盟中国可用性巡展上曾经有个人提问：“如何量化交互设计人员的绩效”。当时国外专家给出的回答：“交互设计是一种创造性的灵感性质的工作，不宜进行具体的量化”，当然专家回答的很含糊，从中得不到我们想要的答案，但这个回答多少给了我们一些启示……

为了能够把用户体验设计量化，在部门的设计流程里面增加了“专家内部评审”的环节，评审后“专家”会给设计评分，作为量化设计的标准，对于这点，我深感疑惑。

且不论“专家”是否足够权威，“专家”的评分仅仅是个人的经验、认识和理解，过于偶然、随意，过于片面、感性，得出的量化结论未必准确。一直以来，我们都嚷嚷着提升用户体验，但很多时候还仅仅停留在已有的产品经验上做设计，事实证明，这样做并不是很靠谱的事。同样如果我们仅根据“专家”的评分作为量化用户体验设计的标准，多少有点“五十步笑百步”的感觉。

不同用户群体看待问题的出发点、角度都不太一样，打个比方：现在要设计一款产品，受重的用户群知识层级比较低，很可能在“专家”眼里非常二百五的设计，反而更容易被用户接受。当然不可否认在设计流程中加入“专家内部评审”环节是非常有必要的，但是并不能以“专家评分”作为量化设计的准绳，“专家评审 ”仅仅是为了汇聚更多臭皮匠的智慧成就诸葛亮的过程，至于成败与否，还是回归到用户吧，只有用户给出的量化结论才掷地有声。

要衡量用户体验设计要从产品的”品牌”,”可用性”,”功能”,”内容”四个方面着手,这个相信搞体验的都清除,就不多说了,接下来谈谈我对如何衡量用户体验设计的想法:

查看全文 »

Tags： , , , , , | 评论[9] | 共有 547次浏览

前后端分离开发模式初体验

日期: 2009年6月15日 | 分类： 前端开发

前后端分离的开发模式，原本觉得没什么稀奇的玩艺，在最近参与的一个大型项目中，让我有了更深的理解。

前后端分离的开发模式：系统分析阶段，系分和前端开发人员约定好页面上所需的逻辑变量，进入功能开发阶段，前端开发人员进行前台页面结构，样式，行为层的代码编写，并根据约定好的变量，逻辑规则，完成不同情况展示不同的表现。而后端开发人员，只需要按照约定，赋予这些变量含义，并提供前后端交互所需要的数据即可。

前后端分离开发模式

以前自己在php上玩过mvc开发框架，但是没有在这么大型的项目中实践过，所以过程中暴露出一些问题，也说明现实和理想还是存在一定差距的。

查看全文 »

Tags： , | 评论[7] | 共有 630次浏览

 Page 1 of 5  1  2  3  4  5 »