戴传庆

用户与产品之间的相互可以看成是双向线性的过程，手机上输入字母“d”和界面输出显示是一次短交互，完成一次购物支付是长交互，这是使用一次产品过程中。用户体验考量的是用户使用产品的全过程，这个过程包括了从安装到放弃使用的时间轴，交互的良性循环的优秀用户体验的表现。

简单以推荐引擎为例来说明各元素是如何在时间轴上发挥作用的：

初始化。基于群体特征和用户的相关程度，将相似用户喜好的其他物品推荐给用户。在用户对产品还没有发生行为时，用户填写的个人信息（性别、年龄和收入等）可以作为初始化推荐。

内容推荐。单个用户选择某一物品，系统基于物品的元数据推荐相似的产品。这是用户个体行为对数据的过滤，当用户多次行为之后，系统可以大概估计对用户的喜好。用户的历史行为会不断影响后续推荐，形成用户和系统之间的交互循环。

协同过滤。基于用户行为发现物品的相关性。内容推荐是单个用户对系统数据的过滤，而协同过滤是基于多个用户行为的交叉结果，所以依赖于其他用户行为数据量准确度。

输入法的字词联想也可以看出一个推荐引擎。当打入字母“da”，系统从词库挑选出“da”目录下的汉字“大/达/打……”，“大”字上屏之后，系统联想与“大”组词概率比较大的字“家/学/概……”。这些联想词最早可能是从字典中筛选出来的，如用户选择了“概”字，“概”会被系统加权，下次对“大”联想时更靠前显示。用户输入词组“dagai”,选择“大概”上屏，也是对“概”字的加权。

如用户输入“daniu”，选择了“大牛”上屏，而系统词库中没有这个词组，属于用户自造词。如用户分别输入“da”和“niu”并上屏，系统智能分析“大”和“牛”有组词的概率，有可能用户下次输入“大”字，系统会联想到“牛”。

联想的交互是单个用户对系统词库的内容过滤，初始词库可以逐渐形成个性词库。如果是云端输入法，系统可以实时获得所有用户的输入字词，词库的更新频率更快，满足用户个性词库的同时也能更新最新流行词，这是多个用户对词库的协调过滤。

用户自造词会降低部分词汇的出现概率，系统甚至会从词库中删除这些词汇。从输入法的例子中可以看出用户行为是如何影响系统和其他用户，历史行为影响新的行为，实现不断的交互循环。

纯银的“显性内容决定论”可以理解为：优质用户产生优质内容，优质内容吸引优质用户，内容决定产品的魅力和气场。从系统设计的观点看，用户行为可以看成系统数据的一部分，优秀用户的行为和优质内容是同质化数据。它们之间的频繁交互是优化内容数据的组织形式，再不断向外扩展生成和吸收同质数据，版本迭代是滚雪球式的数据扩展。

如此看来，产品架构需要考虑是如何增加数据量、组织数据和数据扩展的良性循环。

切客的勋章

以手机LBS为例，增加数据量的方法简单分为三种：用户输入、导入数据和商家发布信息。需求驱动用户主动使用，LBS的勋章激励机制是引导用户行为，优惠券是刺激用户需求。用户的签到行为如果无法加以利用的话，可以认为是不断输入垃圾信息。但签到的位置、签到商家的类型和频繁程序都是可以加以分析，便于后期向用户推荐有效信息和组织用户之间的联系。

每次循环都会影响到后续的产品质量，“小步快跑”的道理也在此，用户对于产品的感受也是不断增强，但也可能达到饱和。使用豆瓣电台选择喜欢听的音乐，累计听歌近两万首时，电台猜中概率明显降低。原因可能是：

1. 已经遍历各种音乐，难以发现新歌曲，个人输入行为已经趋向于饱和。
2. 没有文艺范，不是目标用户群，对音乐缺乏探索。
3. 听到不喜欢的音乐时，可能会连续点击十次下一首，最后无奈关掉电台，对于用户的隐性反馈缺乏理解。

以思维导图式的方式理解产品会缺乏组织性，循环是产品架构的初级概念之一，以时间轴去安排产品设计的优先级。

应用程序的信息架构前首先要明确数据结构和设计重点，数据结构有两部分组成：目录（或者叫做数据结构）和正文，设计上要判断是以呈现数据结构还是正文操作为重点。

重结构轻正文。由于数据过多，数据层级关系复杂，应用程序的重点在于呈现清晰的数据结构。用户进入正文进行编辑操作时，必须先选择文件路径，但花在正文编辑的时间很少。这种方式适用于文件管理和设置型的应用程序。

iFiles

对于此类结构应用程序掩盖尽量减少层级关系的反复跳转，在用户打开改目录之前，提供必要的信息帮助用户判断是否打开。当文件格式不同时，以格式图标快速区分文件之间的差异。文件名称对图片区分作用较低，，可以直观地显示图片预览。

Numbers

重正文轻结构。数据少，数据层级关系简单，用户大部分时间用于正文。

Office

iPad版Pages/Keynote/Numbers与Office相比弱化了文件管理，只提供常用的新建和删除功能，将设计的重心放在对正文的编辑。程序提供设计模板，即使没有经过专业训练的普通用户也能做成美观的PPT和表格。

Flipboard没有像Readpad那样的文章目录，一是因为目录对于用户选择是否阅读并没有多大帮助，进入正文才可以判断是否深阅读；二是推荐算法发挥到极致时，可以满足普通用户每天深入阅读二十篇文章的需求，用户花在正文的时间更多；三是可能由于用户阅读行为对后续文章推荐有影响，程序无法显示稳定的文章目录。

Awesome note

结构和正文的均衡。数据多，对正文操作时间也很长。用户在实际操作时，不会同时关注两者，正文界面上通常不会显示数据结构，让用户集中注意力在正文。

Awesome note

Awesome note提供了复杂的数据管理和正文编辑功能，信息架构极为复杂。在横屏下操作正文时，正文会掩盖目录，利用视觉和显示空间保证正文界面最大化的同时也能保证用户能集中注意力。

导致这种情况出现的另外一个原因是由于设计重点不明确。iPhone的缺点是屏幕小，当前界面只有一个重点。而iPad屏幕大，设计不当导致界面元素过于密集，可以同时显示数据结构和正文，虽然可以减少像iPhone那样层级关系的反复跳转，但容易分散用户注意力。

iPad版迅雷看看的首页重点不突出，基本是照搬Web页面的布局，没有QQlive的简洁和有趣，同时在第一界面上区分用户使用目标。迅雷对iPad的气泡框和下拉框利用不足，导致页面元素拥挤。QQlive看电影的流程是：选择海报→查看影片介绍→看电影，迅雷的流程是：选择海报→看电影和查看影片介绍，两者在看电影前没有提供必要的信息帮助用户决策，比如用户评分和主演。

两个产品的体验很挺槽糕，难以形成很强的用户粘度。鲜果播报可能由于自身也是做阅读器的缘故，不支持Google Reader。支持多个微博，但是基本上就是个微博客户端。

打开程序时，内容不会自动更新，也没有更新按钮。为了凑版面，图片被强行拉伸，严重影响视觉效果，一张像素不高的图片会大倒胃口。

操作麻烦，增加无谓的操作，点击图片经常只会增加几行字，为什么不直接在图片下方显示，微博文字往往比图片更重要。

内容如何排版没有规律，比如设计五种排版模式，每次读取4-7条数据，从二十种排版可能性中选择最佳排版方式。设计上可以将推荐用户阅读的内容占据更大的显示空间，优化文字显示和智能提取摘要的技术。

Zaker的增加些交互操作，评论时手机移动范围很大。缺乏对链接中内容的提取，字号忽大忽小。查看下1.2版本的更新记录，都是在完善设计，缺乏核心技术。要么是更好地支持微博，要么是优化Google Reader订阅，但是这都不是用户的核心需求。

想用微博的话，可以使用官方客户端，虽然设计的也很一般。Sina微博的背景设计的比正文还要显眼。把网页版twitter布局照搬到iPad，分为左中右三部分。设计思路是呈现所有功能，而不是以80%的用户需求为准。

想用Google Reader的话，可以使用ReadPad和Reeder。ReadPad更像是数字化排版，支持多种布局方式，向上拖动正文时可以加载下一篇文章，保证阅读的连续性，还支持离线阅读模式。Flipboard追求的是返璞归真，以永不过时的平面设计体现产品的本质，但对设计和技术要求更高。

Reeder的首页可以编排订阅源，但是这种形式对增加阅读效率基本没有帮助。返回首页时，需要点击左上角的按钮，增加手指的移动范围。底部显示的广告不如穿插显示在正文底部，还可以根据关键词智能显示广告。

Flipboard阅读文章时，点击三个黑边可以关闭正文，左右手势用于翻上下页，不需要像Zaker那样精准点击“X”或者双击来关闭正文，更适合触摸屏操作，方便用户各种手持设备方式时的操作。

Flipboard有大约70%的用户连接到了Facebook或Twitter，或同时使用两者。只有约30%的用户仅用Flipboard来获取新闻源并阅读它们。微博已经成为第二大信息分享平台，社交网站和微博有可能成为信息获取的第一入口。有理由相信阅读社交新闻的人将越来越多，对社交新闻的排序和过滤才是此类产品的核心价值。

出于获取最新咨询、学习知识和消遣时间等目的，阅读一直是用户的基本需求。传统纸媒体时代，用户阅读对象局限于书籍、杂志和报纸；电脑进入互联网时代后，Web1.0增加了门户和论坛，Web2.0增加了博客、社区和微博。内容和终端的不同，阅读体验也会随之改变，那什么是移动设备的最佳阅读体验呢？

内容来源

@李开复：顾客要买的其实不是某个产品，而是他们需要运用一个产品来完成某件任务或解决某个问题。有句著名的话：“顾客不是要买钻头，顾客要买的是洞。”

用户购买电子书和安装手机客户端的目的不是喜欢产品形式，用户的核心需求是内容，是否有用户想阅读的内容是决定用户使用的主要因素。盛大Bambook的内容来源是网络文学，目标用户群是阅读网络文学的用户，电脑端、Pad类产品和手机都是内容的发行渠道。

之前讨论过iBook和小米读书的界面设计优缺点，但内容才是用户安装的决定性因素。有文章评测三大微博平台S60客户端，结果是新浪微博不如其他产品，但新浪微博的安装量肯定是远超其他客户端。

内容决定目标用户群，如掌上百度的内容来源于论坛，决定目标用户群的特征是喜欢逛论坛。

内容组织形式

RSS是聚合和输出内容的技术，掌上百度聚合主流论坛内容，电子书聚合各种格式的书籍，微博也可以看成为聚合大众言论。之所以有聚合，因为内容之间有共性并可组织，组织之后的内容形成强烈的特征。

聚合减少了用户打开多个网页查看更新所浪费的时间，去除了和主题不相关的垃圾信息，减少了内容的下载时间。

Flipboard聚合社交新闻，经过他人过滤的信息更为精准。在Google阅读器中如果订阅过多的博客，很快会被1000+的条目淹没，不得以按照文章PR值选择性阅读。PR值是通过技术手段对内容排序，而社交新闻是朋友甚至专家推荐阅读的内容，个体用户对于内容权重的影响更大。

用户在阅读器分享的常是个人没有订阅但是有价值的内容，但是关注的用户默认他人订阅了主流博客和媒体，读到喜爱的文章时会选择“喜欢”但不会“分享”。阅读器推荐的条目是根据用户喜好分析可能感兴趣的内容，但是内容质量和猜中的概率都很低。

微博上评论加转发让用户更乐意分享内容，让更多的人知道自己的看法，有助于对内容的传播和过滤，分享的信息更为全面。

电脑端还有不少阅读器在开始使用时默认为用户增加了很多订阅源，刚开始使用时就已经5000+的信息量，导致信息的价值变为极为廉价。用户关注的不是有多少信息量，而是有多少内容是值得深入阅读的。

无觅的浏览器插件试图通过用户浏览的当前页面推荐相关内容，从搜索模式的角度看是减少用户的再次搜索，推荐可能感兴趣内容。没有对用户兴趣的初始化确认，在内容相对局限的阅读器中没有完成的技术，在整个互联网中去实现过滤，其技术难度非常大。

通常为了从微博中获取有价值信息的做法是增加fo专家和媒体的数量，并将这些用户编组。增加fo的数量会带来重复信息和稀释每条信息的价值，fo的数量过少无法保证信息量。像微精微博智能过滤会有一定的使用需求，微博的元数据如评论数、转发数和该用户的粉丝数等都会是过滤的参考依据，从用户行为中建立兴趣模型。

终端产品

移动设备的兴起没有增加内容的产出，但改变了内容的展现形态。电脑端多以网页的形式展现，移动设备以客户端占绝大多数，两种产品之间的用户粘度没有平滑过渡。

用户在电脑端使用Gmail，在移动设备终端也会使用。在电脑端通过阅读器或者浏览器阅读“晓生语录”，但是在移动设备终端完全可能通过新浪微博的网页转码和MobileRSS阅读。相同的内容和用户，但处在中间的媒介产品会发生改变。

相对于电脑端的产品，提升移动设备端的用户体验需要注意以下方面：

• 延续原有电脑端的聚合需求，由于移动设备屏幕和网络的限制，聚合的需求会更强。
• 为保证下载速度和碍于操作不便，产品会更专注于内容，削弱原有产品的其他特征和噪音，比如论坛和微博的互动元素。
• 移动设备特别是屏幕小的手机上，不适合一次展示过多的内容，逐渐根据用户使用习惯显示个性化内容。
• 减少内容的层级跳转和快速切换内容，保证阅读的连续性，减少时间浪费在查找信息过程中。
• 区分已阅读内容和过滤重复内容。
• 移动设备的便携特征会保证内容传播更为及时，可利用ios/Android操作系统的特性主动推送内容。
• 利用视觉削弱影响阅读的元素，增强内容的图文混排，保证内容质量。

产品的市场占有率不会延续电脑端，移动设备端同时是快速增长的市场，对于鲜果这样的产品是新的机遇。甚至之前没有使用阅读器的使用习惯，也可以轻松学会使用。

但是现阶段还没有良好的盈利模式，移动设备上显示广告的效果不佳。一是有限空间显示广告有碍阅读；二是与电脑端相比，点击广告跳转浏览器，原程序改为后台运行，对用户操作影响更大，近半数的用户点击广告属于误操作。

看到Android版开卷有益工具栏上的小字“如果您对广告感觉不适，点击一下，我们将关闭广告”，不免会心一笑，这种形式也常见于免费手机游戏。失去广告和没有搜索带来的分成，给其他产品带来安装量或许是短期内唯一的产品价值吧。

用户使用情景

用户使用移动设备的时间不像在电脑端时间比较完整，处在移动环境并且是碎片化时间尤为明显，个人猜测约60%碎片化时间和40%整块化时间。碎片时间适合阅读短平快内容和快速的查找信息，整块时间适合深入阅读，如小说和阅读器。

适合碎片化时间使用的微博产品可以额外推荐用户感兴趣的内容，增加产品的内容时间。个人在新浪微博fo400多个用户，在手机上花2分钟即可读完1小时内微博信息，因为加载时间过长，不会打开微博的任何链接。对于我来说，微博基本不会占据我的整块时间。

某些功能性产品也通常是用户需要时随时使用，使用完之后即关闭，属于工具性产品。如能在不影响原有使用效率的基础之上尝试增加阅读性内容，增加产品的用户粘度。

对于用户使用移动设备又可分为有目的的使用和无聊时间，一般情况下，低端用户的无聊时间所在的比例更多，手机的使用率更高。根据操作系统的特性，忙碌的用户应该更倾向使用WP7和Blackberry。

学习产品设计初期肯定会遇到两个问题：第一，如何考虑更全面；第二，如何绘制交互流程图。开始产品设计前先要考虑所有可能性，如何才能以线性流程图的方法组织所需的设计元素。小郑老师的《交互设计表格》中已经介绍了非常实用的表格穷举法，适合初学者使用。

流程图是产品经理和交互设计都必须掌握的技能，一张流程图可以省去需求文档和交互设计文档的很多文字描述，让技术人员一目了然地明白设计意图，便于组织程序的逻辑顺序。

绘制流程图准从简单的原则，流程图是设计师的产出物，体现设计意图，主要给技术人员和测试人员浏览，至于自己是如何思考不应体现在流程图中。别人也要早点回家被老婆，没有时间关心你如何的细心的考虑，也不关心用户会如何思考和操作的，请直接给他们展示设计的结果。

复杂和纠结留给自己，简单留给别人。对用户是这样，对工作同伴也是如此。

图例1：手机程序开机检查更新的流程图

流程图包括以下图形：

• 矩形表示交互环节
• 菱形表示问题判断
• 箭头表示工作流方向

也有用圆角矩形表示“开始”和“结束”，个人一般不要该图形，因为从上而下的线性流程图。最顶部的图形或者箭头开始的部分是流程图的“开始”，如图例中，开启程序触发了事件，程序开始检查更新；最底部的图形或者箭头终止的部分是流程图的“结束”，如重启程序和不再提示表示本次事件结束，无须以图形区分表示“开始”和“结束”。

流程图容易和操作步骤混淆，比如《交互设计表格》中的登录框操作步骤是：

1. 点击登录，弹出登录框
2. 点击用户名输入框，输入用户名
3. 点击密码输入框，输入密码
4. 点击登录

操作步骤是用户正常情况下完成某项操作所需的操作，而交互流程图（严格意义上叫程序流程图）表达是执行逻辑的路径，通俗地将是当用户点击某个按钮之后，程序执行命令的顺序。更复杂的系统流程图可用于产品架构。

当用户点击的登录框之后，文字描述程序执行的顺序：

1. 检查用户名是否为空。如为空，提醒用户“请您输入用户名”。如果用户名设置要输入手机号码，还要检查手机号码是否是否以13/15/18开头的11位数字。
2. 检查密码是否为空。如为空，提醒用户“请您输入密码”。
3. 检查用户名是否是已用账户。程序提交数据与服务器数据进行比对。如果不是，提醒用户“用户名不正确”。疑问：用户名有误和不存在是如何判断的?
4. 检查密码是否与账户匹配。如错误，提醒用户“密码输入不正确”。

现多数登录框将4和3合并，只提醒“用户名或密码不正确”，可能是告知用户过于准确的信息之后会增加盗号风险。

图例2,wap站验证用户手机号码