作者： 晓生

推荐系统的基本原理是从数据库中匹配到根据分析用户行为推测出的喜好，根据推荐算法的不同，可以分为以下几种：

• 协同过滤系统（collaborative filterring）
• 基于内容的推荐系统（content-based）
• 混合推荐系统（hybrid）
• 基于用户-产品二部图网络结构（network-based）

其中数学公式居多，对于没有技术功底的设计人员来说有些晦涩难懂，个人尝试从产品设计的角度依次从数据、数据外围的产品和用户三个方面去分析，在分析之前需要了解以下问题：

1.关键元数据。元数据是关于数据的数据，可以用来描述和管理数据，如歌曲的演唱者、所属专辑、发行时间、发行公司和所属类别，《黑白》出自华纳2008年12月发行的方大同专辑《橙月 Orange Moon》。对于推荐系统而言，需要找到影响用户喜好的重要元数据，假设用户是方大同的粉丝，那演唱者是关键的元数据，用户可能还会喜欢此专辑中其他歌曲《小小虫》和《100种表情》，对于喜欢听新歌的用户，发行时间可能更为重要，还有可能因为用户喜欢听R&B。

结构化数据

非结构化数据

2.结构化和非结构化。元数据之间的结构化的组织（如歌曲的演唱者和演唱者所属的国籍）可以很方便获得，但这些的元数据通常只是关键元数据之一，还有非结构化的元数据（如节奏、声调和音色）也会影响用户的选择，数据之间的隐形联系只能通过大量的分析获得。

3.关联性。和用户的行为、背景、特征等相关，分析得出数据之间的规律性特征。常见的如购书网站上，购买了这本书的用户有40%购买了另外一本书。又如通过分析大量消费者的购买单挖掘出的数据关联性，得出啤酒和尿布之间的关联性。

4.多样性。关键元数据结构化的强弱影响产品的多样性，比如图书所属的类别复杂度高导致了图书的多样性，而音乐相对单一。产品的多样性意味着数据之间隐性的关联更为复杂，会增加分析的难度，推荐系统也更复杂。

5.时效性。数据更新的快慢和用户对新数据的需求影响数据的时效性，如热门论坛中帖子比博客中的文章时效性高。如微博和新闻这样时效性较高的数据要求服务器数据更新要高，时间影响推荐系统的重要数据。数据挖掘注重实时分析，根据用户的每次操作和新的数据的导入提供最新的推荐。

6.难以明确。要求用户用几个字词明确表述自己喜好什么样的产品是比较难的，用户的喜好会随着时间变化而改变。像Google的音乐推荐，对于大部分普通用户而言，那种节奏和音色选择到自己喜好的音乐会比较困难。推荐系统的意义在于根据用户的历史记录去推测用户的喜好，而不是让用户主动去选择。

7.标签。用户添加标签是组织数据的手动解决方法，但是也会导致其他问题：

• 非自动化的解决方法会增加用户操作，难以挖掘数据之间的隐形联系。
• 用户填写标签，由于词语的模糊性会导致标签过多，数据之间的联系会减弱，降低数据之间凝聚力。
• 用户选择推荐的标签，易于理解的词语会导致数据凝聚力过强，导致数据偏向结构化，不利于用户发现感兴趣的内容。

8.打分机制。通常是五分制和两分制（喜欢/讨厌），分值越多，用户选择起来越麻烦，需要消除用户评价体系的差异性。用户协同过滤的内容偏向大众化，可以过滤到低质量的内容，但用户对小众化低分数的内容不一定就不感兴趣。通过调查问卷的方式，用户会选择每道题，而通过网络非强制性打分，用户不喜欢的内容很有可能不打分或者直接跳到下一个数据。

参考资料：

1. 推荐系统的五大问题.《Resys china》
2. 个性化推荐系统的研究进展.刘建国，周涛，汪秉宏.《自然科学进展》2009年1月第19卷第1期
3. 豆瓣在推荐领域的实践和思考.王守崑
4. 从web2.0到推荐引擎2.0.《学而时嘻之》

推荐系统（recommender systems）是利用信息过滤技术向用户推荐其可能感兴趣的信息。推荐系统是有别于信息分类和信息搜索的信息处理方式。

信息分类是有序的按照时间/主题/类别/用户/任务等方式组织结构化信息，浏览分类信息可以帮助用户理解信息之间的组织方式，但是这种信息的呈现方式是基于用户已知目标信息的所属类别，用户认知事物偏向于模糊无序，难以从有序的信息中发现未知并感兴趣的信息。

信息搜索是根据和群体行为相关的权重排序信息，带有任务的用户寄希望能快速搜索到感兴趣的内容之后再深入阅读，再带着新的任务继续搜索，而现实的情形是个体用户不得不调整关键词反复搜索处于长尾的信息。

随着信息的快速增长，信息重复和信息过多导致的被动获取的信息过载，通过搜索引擎主动获得高质量的信息也会花费更多的成本，推荐系统是解决这些问题最有潜力的方法，其作用在于：

• 帮助用户快速发现感兴趣和高质量的信息，提升用户体验。
• 增加用户使用产品时间。
• 减少用户浏览到重复或者厌恶的信息带来的不利影响。
• 提供个性化信息，信息的推荐更为精准。

如果客户端不支持像iPhone那样记载最后使用的情形，客户端开启之后，经过3秒左右的开机画面会进入首页。首页是用户使用客户端的第一界面，起到展现内容和引导用户使用的作用。如客户端的功能和内容比较简单，通常会采用“首页+设置”的单级形式，如客户端的功能和内容较多，无法一页完全展示，页面之间存在层级关系，那会采用“首页+多级页面+设置”的多级形式。

单级形式的iPhone客户端

多级形式的iPhone客户端

首页在不同的客户端中不同的功能：

1.展现功能。如人人网iPhone客户端。

2.展现内容。如腾讯微博iPhone客户端。

3.展现功能和内容。单级形式和比较复杂的多级形式的客户端的首页通常如此。

使用何种首页取决于客户端的类型和架构方式，内容为主的客户端，首页当然是展现内容。但是当客户端既有功能也有内容时，如何合理设计首页呢？是通过功能去查找内容，还是根据内容去使用功能？人人网的客户端的首页为展现功能“新鲜事/个人主页/好友……”，虽然是模仿Facebook的设计，不见得是最好的方案：

1. 九宫格的设计比较死板，是继承物理按键手机的设计，没有发挥触摸屏手机的优势。
2. 功能的切换必然要返回首页，增加操作步骤。
3. 展现功能的首页基于的假设是功能之间比较并列的，没有明显的主次之分。而使用SNS的客户端先查看是否有消息推送，然后浏览朋友分享的内容，而”发状态/查看好友/传照片”等功能较弱。
4. Android版本和iPhone版本几乎完全一样，没有发挥手机操作系统的特性，Android菜单键本可以承载更多的功能。

首页的设计最重要是引导用户使用，根据用户使用产品的需求安排或者推送用户最想看到的内容，而不是摆放几个功能让用户去挑选。就像用户进入衣服店时，看到的是整整齐齐的衣架，但没有推销衣服的广告，没有主打款式，也没有热情的服务人员。

大众点评网的iPhone客户端，标签栏“搜索”和“附件”中的内容几乎一样，都有“美食/小吃/咖啡厅”的信息分类，只是查询信息时的范围不同，这在“附件”中也有根据地理范围搜索信息，可以将“搜索”和“附件”归类成在一个标签内。大众点评网在是用户有需求再来查找内容，有分类有搜索，信息架构上比较简单。一方面要扩大数据库，完善内容，另一方面还要考虑如果向用户推送内容，精准化营销，基于LBS的客户端具有这样的优势。如何利用LBS、手机类型、用户的使用记录和偏好和好友的推荐等等手段去精准推送内容才是发展趋势。

另外，如果是手机客户端是主打的产品，不是像腾讯微博和淘宝那样属于web的衍生产品，当需要账号注册时，应该尽量放到用户看到首页，并且已经开始使用产品之后再邀请其注册。这时的首页还要起到推销产品的作用，展现内容是必不可少的了。

设计原则是做设计的标准，可用于指导设计和衡量设计方案的优劣。个人在写MRD时，会先考虑用一句话作为设计目的，描述做这个设计满足用户何种需求或者有什么作用，然后再写三至五条设计原则，满足用户这项需求时做的设计需要遵守什么。

比如在设计一个购买彩票出错页面，设计目的是为了降低用户的挫折感。那设计原则可以是：

1. 提供用户易于理解的信息。
2. 根据出错情形分别提供有用的信息。
3. 引导用户继续浏览其他页面。

以上的原则中顺带将之后的设计方法也一并说明，用于指导设计：

• 根据原则1，设计出的界面中会避免使用出错参数，普通用户并不理解这些专业术语。
• 根据原则2，需要具体研究出错的情况。比如服务器在调整，该时间段不能购买，手机由于信息原因在一定时间内未获得服务器的反馈，或者是因为用户的账号余额不足等等。
• 根据原则3，会引导用户继续使用。比如由于用于的账号余额不足，可以提醒用户充值，先购买其中一部分，使用其他信用卡支付或者返回网站首页。

基于原则做设计，思路会很清晰。如果是团队合作，先是发散性思维，之后也要将设计原则明确下来，便于团队尽早取得共识并在适当的框架下继续讨论。当做A/B方案评测时，可对照设计原则来看，如A方案满足原则1&2&3，B方案满足原则1&2，那自然选择A方案。原则也可以有优先级，如原则A方案满足1&2，B方案满足2&3，原则1比3更重要，那选择A方案。

至于什么是设计原则可以研究交互设计中已有的“常识”或者google之类大公司的设计原则，写原则的目的也是为了抓住重点，有针对性的设计，原则过多，难以把握。一些常识性或者已取得共识的内容也不必当成设计原则，比如界面要有美感和为触摸屏手机做设计要易于手指点击，除非产品定位是重点做这些工作。

设计原则也不可照搬，靠自己研究优秀产品和日常工作中慢慢积累。当设计需求点过多无法掌控现有设计思路时，再引入设计原则。设计原则可以提高工作的效率，但如果引入过早，会限制设计师的发散性思维，扼杀很多好的想法。

设计原则是受用户需求和产品定位等因素的影响，可以说是执行设计的指导性思想，会体现在产品的细节当中，有利于保持产品的一致性。写下设计原则，即使设计发生偏差，也很容易找到自己哪里犯错误了，不断锻炼自己做设计的意识。

当你掌握这个方法之后，工作重点就是研究具体的产品和如何从细节中执行这些设计原则。

Palm的返回操作是在手势区向左滑动，Android有“返回”按键，两者的共同点就是触摸屏上没有像iPhone那样的“返回”控件。因而有想法将手机客户端的界面设计中加上“返回”，是否合理呢？

加上“返回”控件有以下优点：

• 指示。界面上“返回”控件还能起到指示的作用，明确告诉用户当前界面是否是可以返回的，在不知所措的情况下，用户也不用胡乱去探索界面中是否有掩藏的操作。非触摸屏手机通常左软键为“菜单”“确定”之类的操作，右软键为“返回”“关闭”的操作，“菜单”有很多隐藏的选项，需要用户去记忆，但是“返回”却是非常明确的。
• 连贯。在使用触摸屏时，手指通常在操作“返回”和“菜单”之类的操作会离开触摸屏，操作不连贯。触摸屏的体验更好，期望用户的手指能一直停留在触摸屏上，尽量减少触摸屏和按键操作之间的频繁切换。
• 方便。触摸屏上点击控件比使用手势区和按键更方便。

但是任何元素的使用都是有条件的：

1. 有空间。界面上有空间一直放“返回”控件，要保证“返回”控件的一致性，放在固定的位置。
2. 返回操作频繁。由于界面的层级关系多，返回操作比较频繁。如果界面就两层，那用户很容易知道当前界面是否需要返回，指示的作用就没有必要了。
3. 确实方便。也许在界面上放上“返回”控件的想法来源于iPhone，设计师感觉这样用起来挺方便，在Palm和Android也要这样做，这就太主观了。iPhone的“返回”是放在界面的左上角，对于触摸屏而言，左上角是单手使用时最难以点击的区域。如果将“返回”控件放在触摸屏底部的话，对于像摩托里程碑这样的手机，返回键虽然是在触摸屏之外，但是操作的感觉和触摸屏几乎完全一样，那这时操作上方便是非常弱的。
4. 用户习惯。Palm手机属于小众化手机，也许用户是Palm的狂热分子，就喜欢手势区的操作。但也不意味着就一定需要完全遵从用户习惯，如果提供了更好的使用方式，用户的习惯也是可以改变的。

这些都是推理，任何理论都代替不了用户最终的反馈，衡量设计的好坏还是要看用户真实使用产品时的感受。