杂谈产品灰度上线的研发模式

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

传统的产品研发模式大致可以分为：产品调研-架构评估-产品启动-需求分析-产品设计-产品开发-产品发布七大阶段。本人在公司经历过大大小小的项目数以百计，发觉这些阶段一直以来都是以一条直线的形式串行着：从产品调研到产品发布，总是一拖到底。这样的做法对于范围比较大，周期比较长的项目，尤其是用户体验类项目而言，存在较大的弊端：我们很可能在没有足够清楚用户需求的情况下，定制了过多的辅助功能，这样即拉长了项目周期，又无谓的投入了过多的人力，在资源如此宝贵的今天，浪费资源实在太过奢侈，我代表春哥鄙视之…

言归正传，切入今天要谈的话题 —-“产品灰度上线的研发模式”。何谓“灰度上线”，简单点理解就是按产品需求优先级，抽出核心需求，在满足用户基本要求的情况下快速上线，并通过限制流量、白名单等机制进行产品试用，以此收集用户的意见，从而萃取出用户潜在的需求，形成后续更有针对性的设计方案。

和传统研发模式相比，这么做唯一的区别就在于将原先一锅粥式的需求和功能点进行了轻重缓急的排序，并以此将项目从原来的单长线作战转化为多迭代短线循环，让产品的生命周期不再昙花一现。

迭代开发

如此一来，需求分析阶段显得尤为关键，我们必须清晰的将需求按优先级归纳分类为几个序列，如：p1,p2,p3…核心功能和必备的体验在p1序列，辅助功能点和辅助型体验列在p2序列，争执不定的需求点可以放在p3序列。需求排序后，我们可以将项目发布点有序的分成（>2期），第一期只确保主要的核心功能和基础体验快速灰度上线，随后通过用户访谈、产品的tracker&session数据、业务数据等手段分析出用户对产品的真实反应，并以此调整二期需求，该加的加，该砍的砍，做到有的放矢。

查看全文 »

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

再议构建前端UI组件的新思路

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

近日，看了玉伯写的《构建前端UI组件的新思路》一文，让我追忆起去年自己分享的一篇P文《随感协同开发的JS设计模式》，有几分共鸣……

话说去年支付宝新版收银台项目中，我就小试了一把这种组件编码模式，点滴心得，这里和大家做一个交流：

回顾一下之前说到的抽象类，对设计模式有所了解的同学可能会觉得有些眼熟，没错，初一看，觉得它很像一个抽象工厂，但是结合下面的基础类来看，你会发觉我并没有在各基础类中，重写getVessel,show,hide等方法，而是直接继承了抽象类中的这些方法。一定会有人不解为什么要这么做，无他，就因为他是JS,而非JAVA。一定的偶合度换来足够的灵活在我看来一点都不过分，更何况这个抽象类是必须确保绝对稳定的，他在成形后不允许被随意修改那是必须的。

  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.   setInterface:function(){
  24.     //设置各组件共用接口 
  25.   }
  26. })

查看全文 »

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

对前端开发难舍的情结

日期: 2010年3月20日 | 分类： 生活琐事

大伯曰：每个人心里都有个做产品经理的梦。我心里也有一个梦，一个简简单单的梦，正如本人博客关于中所描述的那样，热衷前端开发，关注交互设计，希望有一天能集两者之大成，成就真正的用户体验。这是一种情结，正如两年前毅然决定离开交互设计团队，回归前端那般，因为我相信只有这个团队能让我”贪婪”的左拥右抱，也只有这个团队才兼具Designer和Developer的双重特性，舍他其谁？

“真正”的用户体验？是的，在我看来，虽然现在人人都在叫嚷着用户体验，但是用户体验的时代还没到来，这个时代在等一群能切切实实将”体验”做”实”的人。这群人身上必须具备这样的DNA：严谨+细腻+创新。看似简单的三个词，却包罗了做好体验所需的种种…

一直觉得前端开发人员比所谓的设计师更懂设计，更适合设计。他们内敛、不浮躁，身上不仅具备了开发工程师的”严谨”而且同时兼备了设计师的”细腻”，更重要的是他们有无穷的”想象力”和”创造力”。我坚信，他们终有一天将引领用户体验，画下稳重扎实的那一笔…

也一直觉得前端开发人员比终日编码的程序员们更赋逻辑感，写出的代码更形象更生动，但从未想过有一天会被冠以技术人员的美誉，所以当听到前端开发组被整合进技术部的消息时，还是不免有些许感伤，那是一种难以用言语去描述的心情…也许只有志同者，能懂！

今天很惭愧的红了眼眶，那一刻才发觉自己是多么热爱自己所执着的那个梦，那个车间，那群工友…

感伤过后回归淡定，所幸的是梦还在,车间还在,工友还在…

查看全文 »

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

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

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

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

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

收银台白板

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

查看全文 »

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

随感协作开发的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： , , | 评论[10] | 共有 1,307次浏览

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

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

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

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

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

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

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

收银台白板

查看全文 »

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

 Page 1 of 5  1  2  3  4  5 »