>
批评豆瓣的用户体验 批评豆瓣的用户体验 1445成员

对豆列的评估

Alchain花生 2011-11-09
配图版的请参见日记:http://www.douban.com/note/183051036/

豆瓣现在的豆列分为三种:图书豆列、电影豆列、音乐豆列,本文主要以图书豆列为例进行分析,电影与音乐的也很容易对号入座。

豆列的使用包括:创建、添加、修改、查找、查看。
以下的分析是目标导向,从这五类操作的任务流程进行分析。


一、豆列创建
很简单的过程,没什么好说的


二、往豆列里添加条目
有多种触发用户往豆列中添加条目的场景:
①、创建时添加
②、周期性大量更新豆列时添加
③、看过/想看某本书时添加
④、查看自己或他人的读过页面时(此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时)添加
①-③是主要场景,需要重点考虑;④是其他各种情况,没那么重要,可以适当忽略。

2.1、创建时添加:
创建时添加条目
创建时添加条目

2.1.1 创建时添加条目有增加选框功能,这确实是很实际的需要,这点不错
2.1.2 条目的添加最大的问题是,需要一个个找链接,这时候大多数用户应该会从自己的想读/读过页面或使用搜索功能查找条目,然后再一个个复制链接进去,合理吗?用户在想添加书时,心里想着的是那个书名,豆瓣系统在往豆列里添加书,考虑的是那本特定书的定向链接,应该考虑采用更好的形式将人...
配图版的请参见日记:http://www.douban.com/note/183051036/

豆瓣现在的豆列分为三种:图书豆列、电影豆列、音乐豆列,本文主要以图书豆列为例进行分析,电影与音乐的也很容易对号入座。

豆列的使用包括:创建、添加、修改、查找、查看。
以下的分析是目标导向,从这五类操作的任务流程进行分析。


一、豆列创建
很简单的过程,没什么好说的


二、往豆列里添加条目
有多种触发用户往豆列中添加条目的场景:
①、创建时添加
②、周期性大量更新豆列时添加
③、看过/想看某本书时添加
④、查看自己或他人的读过页面时(此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时)添加
①-③是主要场景,需要重点考虑;④是其他各种情况,没那么重要,可以适当忽略。

2.1、创建时添加:
创建时添加条目
创建时添加条目

2.1.1 创建时添加条目有增加选框功能,这确实是很实际的需要,这点不错
2.1.2 条目的添加最大的问题是,需要一个个找链接,这时候大多数用户应该会从自己的想读/读过页面或使用搜索功能查找条目,然后再一个个复制链接进去,合理吗?用户在想添加书时,心里想着的是那个书名,豆瓣系统在往豆列里添加书,考虑的是那本特定书的定向链接,应该考虑采用更好的形式将人的心智模型与系统交互流程对接。
建议:允许用户输入书名添加,使用预搜索,在用户输入的同时提供及时推荐,预搜索中可包括作者、出版社、读过人数等信息帮助用户确认与选择,减少用户输入,减少出错可能。
参照样例:
gogobot往护照里添加地点的形式
gogobot往护照里添加地点的形式


2.2、周期性大量更新时添加
在豆列创建后,添加条目每次只能添加一条
在豆列创建后,添加条目每次只能添加一条

2.2.1 这种情况下用户一般是获得了某些外部信息,如影志每周往自己豆瓣电影【口碑榜】中添加电影;这种情况下确实挺悲剧的,除了每次要通过搜索等方式查找条目外,还需要一本本的点击添加。
2.2.2 或者用户进行自己阶段性的整理,从自己的读过/想读页面往豆列添加图书,这种情景还是挺多的,但是还是只能在找到后,复制条目链接在豆列页一条条添加。
建议:添加条目时允许用户同时输入多条;在读过/想读的列表页增加“加入豆列”的入口,可以考虑适当隐藏,只在用户鼠标悬停时展现。

2.3、看过/想看某本书时添加
2.3.1 把一个条目添加进一个豆列还需要跳转2个页面真是个灾难。可以看看多看几个豆列,大部分人都不会添加描述或经常折腾那排序,所以,该优先考虑添加的便捷性。
建议:不要跳转啦,像G+给人加circle那样,用简单的浮层让用户直接添加;当然,也该允许那些想描述的用户进行描述。
参照样例:
gogobot在地点页把该地加进旅行计划时
gogobot在地点页把该地加进旅行计划时


2.4、查看自己或他人的读过页面时(此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时)添加
2.4.1 这确实没必要特别考虑,但是在用户鼠标悬停时提供“加入豆列”的链接也是可考虑的


三、豆列修改
两种修改:
①、豆列名称和描述的修改
②、条目位置和评语的修改

3.1 无论是这两种情况的哪种修改,现在修改的触发交互都显得麻烦了,需要点击“修改”跳转到新页面或重新刷新页面;特别是跳转到新页面,用户修改描述无法查看自己当前豆列的一些信息,相对而言会缺乏上下文的帮助。
建议:在哪里输出就允许在哪输入,可参考flickr修改照片名称和描述的交互
参照样例:
flickr,鼠标悬停时背景色的变化按时用户可直接点击修改
flickr,鼠标悬停时背景色的变化按时用户可直接点击修改

3.2 修改位置和评语时,一次只能改一个,这其实阻止了很多用户想给自己豆列中的条目添加描述的冲动,因为以下要改10个以上的描述时,那一次次的修改与确认会让人很崩溃。
建议:应该有个全局的修改控件,允许用户一次修改多个条目的位置与描述


四、豆列查找
4.1 缺少搜索功能,这是老生常谈的问题了,不纠结
4.2 喜欢用豆列的人该跟我有过类似的经历,看了某本特别喜欢的书后想再找找同类型的书时,豆列就成了种很有用的东西。按豆瓣的说法“书籍豆列将在被推荐的每一本书的介绍页里出现,以对别人的有用程度排序。”,排序规则真的是这样的吗?
看看以下案例,史蒂夫·乔布斯传页面右侧的豆列推荐:
条目页右侧的豆列推荐
条目页右侧的豆列推荐

但是点击全部之后却是:
点击全部后的豆列推荐
点击全部后的豆列推荐

问题是:不明白这排序规则,这显然不是按所谓有用程度排的,而且没有提供“收藏数”或“推荐数”的信息帮助用户选择与判断;对于一些冷门条目而言,在条目页右侧的5个豆列推荐就已经足够了,但是对一些热门条目来说,有很多热门的豆列,这种情况下,想要找自己感兴趣的豆列是个大灾难。
建议:在条目的豆列推荐页,按收藏数对豆列进行排序,或者至少允许用户选择这种排序规则


五、豆列查看
这可以分为:
①、查看豆列列表
②、查看豆列内的条目

5.1 看看豆列列表
查看自己收藏的豆列
查看自己收藏的豆列
条目页的豆列推荐
条目页的豆列推荐

5.1.1 这两种形式有个共同的问题:在豆列名称下面有创建人和更新日期的信息;当然,豆列名称和创建人都很重要,但是用户一般不会同时对这两种信息进行加工查找的,而是一般先找到豆列名再看看创建人对不对,或者先搜寻创建人,再看是否是那个豆列;这两个认知任务时需要分开加工。现在的信息呈现形式对用户扫视会造成较大的干扰。
5.1.2 头像其实是挺必要的,很多用户都难记得准确的豆列名,但可能会记得创建人,提供用户根据创建人的查找方式是不错的选择,而且人对图片的判断速度比文字快得多
建议:最好将创建人与更新时间移出与豆列名平行,减少干扰;在收藏的豆列页增加头像,在条目的豆列推荐页增加豆列的收藏数与推荐数信息。

5.2 查看豆列内的条目
5.2.1 很多人其实不会给自己创建的豆列中的条目特意写评语,这种情况信息相对匮乏,让你较难做出合适的选择判断。比方说,你想看看桃姐的2011新电影豆列中推荐的电影,但是你难以确定该先看哪部,又有哪些是已经出了下载的,这时候你可能就需要评分和看过/想看的人数等信息帮助你去判断确定。
建议:给豆列中的条目增加看过/想看的人数、评分等信息,当然为了保持简洁,可以只在鼠标悬停时展现。另外,既然有短评,该考虑允许用户以自己的短评作为豆列中条目的评语。
0
显示全文

查看更多有趣的豆瓣小组

回应

还没人回应,我来添加

更多相关帖子

推荐小组

值得一读

    豆瓣
    我们的精神角落
    免费下载 iOS / Android 版客户端