由Kimi找茬想到的
Kimi的找茬贴:新版我的淘宝-已买到的宝贝页面
时间有限,也学刘韧体,简单明快的说点想法:
- “合并付款”和“批量备注”快速操作栏,这是2008年6月份加上的。最初的设计里,上面是没有这一栏的,只有底部有。但后来不断有客户反映,希望上面也有,以方便快速操作,因此加上了。可以看出:视觉设计的目的是方便操作,淘宝的做法是可取的。至于对视觉流的打断,在没有想到更好的布局前,是肯定有影响但暂时可忽略的(除了新手,感觉大部分买家不会去看表头,视觉流很可能是直接从第一个订单开始往下看。当然,具体情况如何,缺乏眼动仪等数据分析,我也只能和Kimi一样瞎猜)。
- 第二点同意Kimi. 非常希望减法在淘宝的推行,至少应该放到和加法同等重要的地位。不然设计上的局限性会越来越多,由此引发的无奈、妥协和愤怒等各种情绪也会让团队跨掉。
-
很多设计其实都是为了“购物车”功能,一个订单可以有多个宝贝,如下图:

不少目前看起来别扭的设计,等“购物车”开放后,会更容易接受一些。比如“投诉”,其实一个是投诉宝贝,一个是投诉订单。当然,对用户来说,两个投诉的确很容易混淆。这是PD们的业务需求,或许以后会简化掉。 - 这个页面的复杂度在于如何整合单个宝贝订单和多个宝贝订单的混杂显示,以及对各种交易状态的处理。如果谁有更好的想法,欢迎反馈给我,我会联系相应的交互设计师,不断的优化和改进。
对UCDChina中很多产品和交互设计师们的困惑:
- 不少文章,阐述的都是作者本人怎么看产品,怎么使用产品,怎么在产品中找茬。然而实际上,真实用户的视角有可能很不同。旺旺上一直有不少买家/卖家和我联系,反馈问题。他们对产品的期待,和UCDChina中的相关讨论有很大不同。
- 好技术未必带来好体验,好设计也未必带来好体验。彼此都不冲突,彼此也没有必然关系。好体验来源于满足用户的真实需求,任何设计师忽略了这一点,就很容易陷入自我设计。自己爽了,用户不一定买单。
- 什么才是真正的用户需求?白鸦引发的装与不装,最后也没解决这个问题。定性分析离开了定量研究,总感觉缺乏说服力。

February 27th, 2009 on 16:43
关于在集市提供购物车,我有一个想法,我过两天抽空了写出来。
到时候可以探讨一下。
February 27th, 2009 on 16:45
对了,你的博客的theme真好看。
你自己设计的?是否可以提供收费服务,帮我设计一个?^_^
February 27th, 2009 on 18:12
在合并付款这个问题上,我不同意认为“很多用户都需要”这个基调,因为不需要的声音我们听不到,需要的人嗓门太大。
这种东西,没有也不会死人,有了只是会让那些嗓门大的用户爽一些。 如果没有很好的解决方案,要冒着让不需要这个功能的用户受骚扰的风险去作他,那么宁愿暂时不做。或者隐藏起来。
这种功能的设计原则应该是:不需要的时候看不到,需要的时候可以顺利找到。 而不是摆出来展示着。
我刚写完那个百度的购物车集团某个老大就告诉我淘宝的购物车也快上了。
购物车是同样道理,我的态度还是:
作购物车可以,但如果因为作购物车影响了一次只购买一件物品的人,那么这个购物车就是失败的。
每个产品经理都认为自己作的这个新产品是整个网站最最重要的,所以每个新产品往往都最最突出的。 上了后被骂就闲置,于是又开始不停的作新产品。
其实这是目光短浅的表现。
ps:“装不装用户”的问题,我认为多数人没看明白。
February 27th, 2009 on 23:05
@白鸦:合并付款这类设计,怎么甄别是不是大部分用户的真实需求呢?你的分析里,也仅仅是猜测,没有任何证明。这种情况,经常导致的结果是,谁的官大,谁的猜测就算数。如何在没有数据的情况下,说服上级相信自己的判断?
对于购物车,同意你的观点。不少开发人员都一样,初期很抵制,但工作不能不做,做到现在看见购物车都麻木了……
再次看了一遍“装与不装”的相关博文,对用户、用户需求、为用户设计这几个概念时清晰时模糊,玄了。希望能看到实例,看到数据。
也许做开发做太久了,什么都喜欢用数据说话。或许这在设计领域是行不通的,但目前UCDChina的吵吵嚷嚷,也太感性了,极少见到定量分析,感觉也很不靠谱。
February 28th, 2009 on 22:42
只有定量没用,只有定性也没用。数据必须结合到一起才有用。
March 1st, 2009 on 1:00
UCDChina里的大部分人,很难帮淘宝做定量哦,自然只能定性的说一说感受了。如果不能说的话,那也没有讨论的意义了不是。
March 1st, 2009 on 13:08
为什么不是只有在2个或以上订单没有付款的时候才出现这个链接……?
March 1st, 2009 on 13:32
@Cloudream 每个设计师第一想到的肯定就是这个方案。
March 2nd, 2009 on 11:10
合并付款功能我觉得是很有必要的,但是目前的引导显然不够,不少用户还不知道可以使用这个功能,如果是拍下多件商品,出现可以使用合并付款之类的引导提示,那是多么美好的事啊
关于购物车功能,本人一直非常抵触,也许会给买家可能会带来一定的便利,但是这种方便充其量也就起到那么点鸡毛蒜皮的效果,以此为代价把商品的名字直接以淘宝订单编号显示对支付宝的用户体验,打击是相当大的!
作为买家,也许这也并非很可怕,哪怕我每天买1件东西,1周也就7件,我支付宝点7下查看订单详情也就解决了,而且作为买家,我直接看已买到的宝贝也省事了,没必要时刻关注着支付宝。
但是有没想过,作为卖家,特别是作为一个喜欢在支付宝管理订单的卖家,这是多么可怕的一件事?如果是皇冠卖家,1天的订单量就多达数百个,每个都要点交易详情查看到底顾客买的是什么商品,以前1小时的工作量,现在要花2小时才能处理完,烦躁带来的后果由可能是直接影响卖家的服务质量,其实也已经损害了买家的利益跟购物体验了。更何况,到底买家对购物车的期望值有多高?是不是真的每个人都需要这个功能?一次购买多件商品的行为有多频繁?值不值得这样子去追求购物车的功能?这些都是我的疑问。
可别跟我说:“你可以去已卖出宝贝那里管理订单。”我已经习惯了在支付宝查看买家买过什么商品,是否已付款,是否申请退款,几年的习惯了,现在因为购物车,我就要改变这个习惯?而且支付宝是直接与钱挂钩了,每天管理订单的同时,还可以顺便上去看看账上的余款,申请提现,已卖出宝贝根本没法提供这些附加享受,更何况,现在的已卖出宝贝页面还杂七杂八一大堆东西看得人都心烦。
淘宝购物车的功能推出是为了方便淘宝买家多次购物,一次结算,但是严重打击了支付宝,我不晓得支付宝的同学当时为何能作出这么大的让步来换取购物车的功能,以上所说可能会带些个人不满的情绪,但是出发点也是希望淘宝方面推出新产品眼光能够看得更远一些,更加人性化一点,买家重要,卖家也一样重要,顾此失彼,最后输的只会是淘宝。
March 2nd, 2009 on 14:12
淘宝经历了这么久时间,养成了各类人群,买,卖,又买又卖;养成了各式各样的操作习惯,我们没做过一个系统的调研。但是能从每次改版的巨大声音里感受到,怎么样的调整都会对用户习惯构成挑战。关键是我们改版的思路是否是清晰的,是系统的解决还是部分的解决。我的EBAY也历经多次改版,但是每次总会发觉能很快适应。在这样一个复杂的页面上,过多的技术导向和业务导向是一件可怕的事情。循序渐进,部分部分的解决现有问题,是一个思路,或者是将主要人群,区分成几类,初级买家,初级卖家,中级高级买家卖家,各给一套操作界面。很可惜的是,我的淘宝,我们的地盘,我们做不了主。
March 2nd, 2009 on 22:48
我最近在作设计的时候 也遇到单一物品订单跟多个物品订单整合类似的问题。 能不能做成 两级式第一级显示订单信息 此层的信息跟物品的详细信息剥离 然后第二级再出现每个物品的信息,也就是说如果我只是要看物品信息, 先进入点订单,然后下拉出订单里的物品? 这样看起来结构清晰一些。不是淘宝深度用户, 只是最近接触一些UI设计的东西,开始思考这方面的问题。
March 3rd, 2009 on 7:34
@小单:默认隐藏物品信息,会增加大卖家的工作量。对于淘宝大卖家来说,他们希望需要的立刻能看到,排版尽量紧凑。虽然用户可能也不清楚自己真正需要什么,但增加工作量的隐藏绝非一个好办法。
March 3rd, 2009 on 10:02
淘宝订单 – 10011000
商品标题
默认收缩,点+号展开,这种方法貌似可以接受,至少不用打开个订单详情的窗口,但不知道会否加大系统负荷。
March 3rd, 2009 on 19:40
如果给出选项 按order列出 跟物品列出呢 如果只关心order的人 就可以只看订单的状态, 如果要是查看物品又两种方式, 一是按物品列出, 还有一种就是‘没出发泄讲的’+号扩展的方式? 用户可以根据自己的习惯去进行浏览~ 更多选择更多欢笑
March 10th, 2009 on 10:38
为什么不可以分买家卖家呢?买家的界面按照买家的的需求来设计,而卖家按照卖家的来设计,这样两方面的用户都能满意。或者可以通过设置,让用户自己可以选择使用的方法啊。
April 1st, 2009 on 15:34
很简单!统计一下用户每天登陆淘宝网后会购买几个东西!
如果大量用户仅仅是:登陆——寻找商品——点击购买——付款——交易结束。放大合并付款就没意思!
或则间接的进行调查,诸如“你每个月在淘宝购买几次” “你每个月购买的商品件数” 这样根据逻辑判断用户是否需要这个功能!
我同意白鸦的观点!
May 12th, 2010 on 17:02
后面的第一条说的很对,不是我们说好就好说坏就坏的,用户买账不买账才是关键!
leave a reply