豆瓣产品评估 之 豆列篇
豆瓣现在的豆列分为三种：图书豆列、电影豆列、音乐豆列，本文主要以图书豆列为例进行分析，电影与音乐的也很容易对号入座。
豆列的使用包括：创建、添加、修改、查找、查看。
以下的分析是目标导向，从这五类操作的任务流程进行分析。
一、豆列创建
很简单的过程，没什么好说的
二、往豆列里添加条目
有多种触发用户往豆列中添加条目的场景：
①、创建时添加
②、周期性大量更新豆列时添加
③、看过/想看某本书时添加
④、查看自己或他人的读过页面时（此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时）添加
①-③是主要场景，需要重点考虑；④是其他各种情况，没那么重要，可以适当忽略。
2.1、创建时添加：
2.1.1 创建时添加条目有增加选框功能，这确实是很实际的需要，这点不错
2.1.2 条目的添加最大的问题是，需要一个个找链接，这时候大多数用户应该会从自己的想读/读过页面或使用搜索功能查找条目，然后再一个个复制链接进去，合理吗？用户在想添加书时，心里想着的是那个书名，豆瓣系统在往豆列里添加书，考虑的是那本特定书的定向链接，应该考虑采用更好的形式将人的心智模型与系统交互流程对接。
建议：允许用户输入书名添加，使用预搜索，在用户输入的同时提供及时推荐，预搜索中可包括作者、出版社、读过人数等信息帮助用户确认与选择，减少用户输入，减少出错可能。
参照样例：
2.2、周期性大量更新时添加
2.2.1 这种情况下用户一般是获得了某些外部信息，如影志每周往自己豆瓣电影【口碑榜】中添加电影；这种情况下确实挺悲剧的，除了每次要通过搜索等方式查找条目外，还需要一本本的点击添加。
2.2.2 或者用户进行自己阶段性的整理，从自己的读过/想读页面往豆列添加图书，这种情景还是挺多的，但是还是只能在找到后，复制条目链接在豆列页一条条添加。
建议：添加条目时允许用户同时输入多条；在读过/想读的列表页增加“加入豆列”的入口，可以考虑适当隐藏，只在用户鼠标悬停时展现。
2.3、看过/想看某本书时添加
2.3.1 把一个条目添加进一个豆列还需要跳转2个页面真是个灾难。可以看看多看几个豆列，大部分人都不会添加描述或经常折腾那排序，所以，该优先考虑添加的便捷性。
建议：不要跳转啦，像G+给人加circle那样，用简单的浮层让用户直接添加；当然，也该允许那些想描述的用户进行描述。
参照样例：
2.4、查看自己或他人的读过页面时（此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时）添加
2.4.1 这确实没必要特别考虑，但是在用户鼠标悬停时提供“加入豆列”的链接也是可考虑的
三、豆列修改
两种修改：
①、豆列名称和描述的修改
②、条目位置和评语的修改
3.1 无论是这两种情况的哪种修改，现在修改的触发交互都显得麻烦了，需要点击“修改”跳转到新页面或重新刷新页面；特别是跳转到新页面，用户修改描述无法查看自己当前豆列的一些信息，相对而言会缺乏上下文的帮助。
建议：在哪里输出就允许在哪输入，可参考flickr修改照片名称和描述的交互
参照样例：
3.2 修改位置和评语时，一次只能改一个，这其实阻止了很多用户想给自己豆列中的条目添加描述的冲动，因为以下要改10个以上的描述时，那一次次的修改与确认会让人很崩溃。
建议：应该有个全局的修改控件，允许用户一次修改多个条目的位置与描述
四、豆列查找
4.1 缺少搜索功能，这是老生常谈的问题了，不纠结
4.2 喜欢用豆列的人该跟我有过类似的经历，看了某本特别喜欢的书后想再找找同类型的书时，豆列就成了种很有用的东西。按豆瓣的说法“书籍豆列将在被推荐的每一本书的介绍页里出现，以对别人的有用程度排序。”，排序规则真的是这样的吗？
看看以下案例，史蒂夫·乔布斯传页面右侧的豆列推荐：
但是点击全部之后却是：
问题是：不明白这排序规则，这显然不是按所谓有用程度排的，而且没有提供“收藏数”或“推荐数”的信息帮助用户选择与判断；对于一些冷门条目而言，在条目页右侧的5个豆列推荐就已经足够了，但是对一些热门条目来说，有很多热门的豆列，这种情况下，想要找自己感兴趣的豆列是个大灾难。
建议：在条目的豆列推荐页，按收藏数对豆列进行排序，或者至少允许用户选择这种排序规则
五、豆列查看
这可以分为：
①、查看豆列列表
②、查看豆列内的条目
5.1 看看豆列列表
5.1.1 这两种形式有个共同的问题：在豆列名称下面有创建人和更新日期的信息；当然，豆列名称和创建人都很重要，但是用户一般不会同时对这两种信息进行加工查找的，而是一般先找到豆列名再看看创建人对不对，或者先搜寻创建人，再看是否是那个豆列；这两个认知任务时需要分开加工。现在的信息呈现形式对用户扫视会造成较大的干扰。
5.1.2 头像其实是挺必要的，很多用户都难记得准确的豆列名，但可能会记得创建人，提供用户根据创建人的查找方式是不错的选择，而且人对图片的判断速度比文字快得多
建议：最好将创建人与更新时间移出与豆列名平行，减少干扰；在收藏的豆列页增加头像，在条目的豆列推荐页增加豆列的收藏数与推荐数信息。
5.2 查看豆列内的条目
5.2.1 很多人其实不会给自己创建的豆列中的条目特意写评语，这种情况信息相对匮乏，让你较难做出合适的选择判断。比方说，你想看看桃姐的2011新电影豆列中推荐的电影，但是你难以确定该先看哪部，又有哪些是已经出了下载的，这时候你可能就需要评分和看过/想看的人数等信息帮助你去判断确定。
建议：给豆列中的条目增加看过/想看的人数、评分等信息，当然为了保持简洁，可以只在鼠标悬停时展现。另外，既然有短评，该考虑允许用户以自己的短评作为豆列中条目的评语。
（PS，写这个并不奢望能有实际的用途，只是对自己的交代和记录。）
豆列的使用包括：创建、添加、修改、查找、查看。
以下的分析是目标导向，从这五类操作的任务流程进行分析。
一、豆列创建
很简单的过程，没什么好说的
二、往豆列里添加条目
有多种触发用户往豆列中添加条目的场景：
①、创建时添加
②、周期性大量更新豆列时添加
③、看过/想看某本书时添加
④、查看自己或他人的读过页面时（此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时）添加
①-③是主要场景，需要重点考虑；④是其他各种情况，没那么重要，可以适当忽略。
2.1、创建时添加：
 |
创建时添加条目 |
2.1.1 创建时添加条目有增加选框功能，这确实是很实际的需要，这点不错
2.1.2 条目的添加最大的问题是，需要一个个找链接，这时候大多数用户应该会从自己的想读/读过页面或使用搜索功能查找条目，然后再一个个复制链接进去，合理吗？用户在想添加书时，心里想着的是那个书名，豆瓣系统在往豆列里添加书，考虑的是那本特定书的定向链接，应该考虑采用更好的形式将人的心智模型与系统交互流程对接。
建议：允许用户输入书名添加，使用预搜索，在用户输入的同时提供及时推荐，预搜索中可包括作者、出版社、读过人数等信息帮助用户确认与选择，减少用户输入，减少出错可能。
参照样例：
 |
gogobot往护照里添加地点的形式 |
2.2、周期性大量更新时添加
 |
在豆列创建后，添加条目每次只能添加一条 |
2.2.1 这种情况下用户一般是获得了某些外部信息，如影志每周往自己豆瓣电影【口碑榜】中添加电影；这种情况下确实挺悲剧的，除了每次要通过搜索等方式查找条目外，还需要一本本的点击添加。
2.2.2 或者用户进行自己阶段性的整理，从自己的读过/想读页面往豆列添加图书，这种情景还是挺多的，但是还是只能在找到后，复制条目链接在豆列页一条条添加。
建议：添加条目时允许用户同时输入多条；在读过/想读的列表页增加“加入豆列”的入口，可以考虑适当隐藏，只在用户鼠标悬停时展现。
2.3、看过/想看某本书时添加
2.3.1 把一个条目添加进一个豆列还需要跳转2个页面真是个灾难。可以看看多看几个豆列，大部分人都不会添加描述或经常折腾那排序，所以，该优先考虑添加的便捷性。
建议：不要跳转啦，像G+给人加circle那样，用简单的浮层让用户直接添加；当然，也该允许那些想描述的用户进行描述。
参照样例：
 |
gogobot在地点页把该地加进旅行计划时 |
2.4、查看自己或他人的读过页面时（此场景可以延伸到查看自己或他人豆列、查看小组收藏的条目时）添加
2.4.1 这确实没必要特别考虑，但是在用户鼠标悬停时提供“加入豆列”的链接也是可考虑的
三、豆列修改
两种修改：
①、豆列名称和描述的修改
②、条目位置和评语的修改
3.1 无论是这两种情况的哪种修改，现在修改的触发交互都显得麻烦了，需要点击“修改”跳转到新页面或重新刷新页面；特别是跳转到新页面，用户修改描述无法查看自己当前豆列的一些信息，相对而言会缺乏上下文的帮助。
建议：在哪里输出就允许在哪输入，可参考flickr修改照片名称和描述的交互
参照样例：
 |
flickr，鼠标悬停时背景色的变化按时用户可直接点击修改 |
3.2 修改位置和评语时，一次只能改一个，这其实阻止了很多用户想给自己豆列中的条目添加描述的冲动，因为以下要改10个以上的描述时，那一次次的修改与确认会让人很崩溃。
建议：应该有个全局的修改控件，允许用户一次修改多个条目的位置与描述
四、豆列查找
4.1 缺少搜索功能，这是老生常谈的问题了，不纠结
4.2 喜欢用豆列的人该跟我有过类似的经历，看了某本特别喜欢的书后想再找找同类型的书时，豆列就成了种很有用的东西。按豆瓣的说法“书籍豆列将在被推荐的每一本书的介绍页里出现，以对别人的有用程度排序。”，排序规则真的是这样的吗？
看看以下案例，史蒂夫·乔布斯传页面右侧的豆列推荐：
 |
条目页右侧的豆列推荐 |
但是点击全部之后却是：
 |
点击全部后的豆列推荐 |
问题是：不明白这排序规则，这显然不是按所谓有用程度排的，而且没有提供“收藏数”或“推荐数”的信息帮助用户选择与判断；对于一些冷门条目而言，在条目页右侧的5个豆列推荐就已经足够了，但是对一些热门条目来说，有很多热门的豆列，这种情况下，想要找自己感兴趣的豆列是个大灾难。
建议：在条目的豆列推荐页，按收藏数对豆列进行排序，或者至少允许用户选择这种排序规则
五、豆列查看
这可以分为：
①、查看豆列列表
②、查看豆列内的条目
5.1 看看豆列列表
 |
查看自己收藏的豆列 |
 |
条目页的豆列推荐 |
5.1.1 这两种形式有个共同的问题：在豆列名称下面有创建人和更新日期的信息；当然，豆列名称和创建人都很重要，但是用户一般不会同时对这两种信息进行加工查找的，而是一般先找到豆列名再看看创建人对不对，或者先搜寻创建人，再看是否是那个豆列；这两个认知任务时需要分开加工。现在的信息呈现形式对用户扫视会造成较大的干扰。
5.1.2 头像其实是挺必要的，很多用户都难记得准确的豆列名，但可能会记得创建人，提供用户根据创建人的查找方式是不错的选择，而且人对图片的判断速度比文字快得多
建议：最好将创建人与更新时间移出与豆列名平行，减少干扰；在收藏的豆列页增加头像，在条目的豆列推荐页增加豆列的收藏数与推荐数信息。
5.2 查看豆列内的条目
5.2.1 很多人其实不会给自己创建的豆列中的条目特意写评语，这种情况信息相对匮乏，让你较难做出合适的选择判断。比方说，你想看看桃姐的2011新电影豆列中推荐的电影，但是你难以确定该先看哪部，又有哪些是已经出了下载的，这时候你可能就需要评分和看过/想看的人数等信息帮助你去判断确定。
建议：给豆列中的条目增加看过/想看的人数、评分等信息，当然为了保持简洁，可以只在鼠标悬停时展现。另外，既然有短评，该考虑允许用户以自己的短评作为豆列中条目的评语。
（PS，写这个并不奢望能有实际的用途，只是对自己的交代和记录。）
