关于推荐引擎的5个问题交互设计

| 收藏本文 下载本文 作者:NaiQiang

下面是小编为大家准备的关于推荐引擎的5个问题交互设计(共含5篇),欢迎阅读借鉴。同时,但愿您也能像本文投稿人“NaiQiang”一样,积极向本站投稿分享好文章。

关于推荐引擎的5个问题交互设计

篇1:关于推荐引擎的5个问题交互设计

一月,在阿姆斯特丹举行了一个名为Recked的活动,活动由Wakoopa和Strands主办,旨在讨论工程师们感兴趣的推荐系统,在活动介绍的内容中,提出了一些公司对于建造有效的推荐系统必须解决的几个问题。

1.缺少数据

或许推荐系统面临的最大问题,是需要大量的数 据,以便能形成有效的推荐。现在能给出最好的推荐的公司正是那些拥有大量数据的公司:google,amazon,Netflix,last.fm,这并不是巧合。下图是Recked活动中Strand’s的演示文档,如该图所示,一个好的推荐系统首先需要类目(种类)数据(从目录或者其它形式得到),然 后系统必须捕获并且分析这些用户数据(用户行为),然后,再应用神奇的算法工作。分析越多的类目(种类)和用户数据,系统越有可能生产好的推荐。但是,这 又是一个蛋和鸡的问题:要形成好的推荐,首先需要有大量的用户,这样才能得到大量的推荐数据。

2.不断变化的数据

这个问题由Clicktorch公司(一家做“智能推荐”的公司)的CEO:Paul Edmunds 在ReadWriteWeb网站的评论中指出。他在评论中指出:系统通常偏向于旧的数据而难以有新的改进。

这 方面的一个例子是David Reinke在StyleHop(一个时尚爱好者的社会团体)的博客上写道:“过去的用户形为并不是好的工具,因为趋势总是在不断变化”。很明显,运算方 法将很难或者不可能跟上时尚趋势。时尚-挑战人们-我接受时尚-依靠值得依赖的有时尚意识的朋友和家人,把衣服推荐给他们。

David Reinke说,“类目(种类)推荐行不通,因为有太多的产品属性,而每个属性(比如价钱,颜色,风格,面料,等等)在不同的时候对于消费者的重要程度都是不一样的”,他指出,社会化推荐可能可以“解决”这个问题。

3.不断变化的用户喜好

提出这个问题的仍然是Paul Edmunds,他认为问题在于:今天自己浏览amazon时是会有特定意图的,明天或许会有另一个特定意图,

举个典型的例子:有可能某天我会上amazon为自己买本书,但第二天我到amazon的原因可能是要为姐姐找一份生日礼物。

对于用户喜好,推荐系统也可能错误的标注。华尔街杂志有一篇文章“如果TiVo觉得你是个同性恋,这就是把你标注成同性恋的方式”

4.不可预知的类目(事项)

我们都知道,Netflix花100万美元来奖励能提升推荐引擎质量10%的人。我们注意到对于一些古怪(特别)的电影会有一些问题,有一些电影观众对它又爱又恨,比如:大人物拿破仑。这种类型的电影是很难去做推荐的,因为用户对它们会有各种反映而且无法预计。

音乐中就有很多种这样的类型。你能猜出来某个作者同时是卡彭特和金属乐的爱好者吗?Last.fm可能需要这种推荐

5.这个东西是复杂的

我们可以很简明的描述,但是从下面这张Strands的演示PPT截图可以看到,哪怕是最简单的推荐,也需要涉及到非常多的参数和变量(而且我们想象到的这些只涉及到系统表面)

到目前为止,有很多公司都已经建立起了用户满意程度较高的推荐引擎系统—amazon,Netflix,google这些名字跳入脑中。但是相对我们想 到的这些少数成功的案例,还有其它成百上千的网站和应用,都在寻找推荐新产品和新内容给用户的道路上挣扎。的确,在ReadWriteWeb,我们更希望 读者在网站上点击发现更多其它的内容,我们使用很多种插件和方法来达到这个目的,但目前我们并不满意

问题之外

推荐引擎可能发生的问题有很多,比如:给出太多最低级公共属性的推荐;对于长尾的支持不够;只推荐显而易见的内容,等等。

原文:5 Problems of Recommender Systems

本文来自:www.thinktag.cn/archives/73

篇2:关注问题,而不是解决方案交互设计

前言:本文译自 MindTheProduct 社区里的一篇文章,原名是《Focus on the problem, not the solution》,

去年有位同学在 ProdcutTank 论坛上提了个问题,让我恨不得自己跳到台上回答他。他问:“如果产品经理定义所有的产品,那何来创新与创造力呢?”停!我简直想喊出来:你错了!

很多人新听到“产品经理”的概念,便把我们当作干扰者或说是入侵者。他们以为,我们设计产品、定义解决方案,然后往墙外一扔,产品就做好了。也许前是这样,但现在我们有了更好的产品设计方法。

产品经理不应该专注于设计解决方案,而是定义问题和优先级。关注问题,而非解决方案,有着一大堆好处:

你把时间用在关注用户的需求上。即,你想解决什么,为什么要解决——而不是怎样解决

你的钻研将很自然地带你进一步理解用户

用户故事与角色的背景资料会日益丰富起来。这有助于每一位参与者建立联系,找到解决方案;虽然并不怎么明显

避免了局部过分优化。和找寻单个解决方案相反,关注整个问题,把它向团队描述清晰,能开辟更广阔的空间去思考解决办法

一旦你是这样研究、探索、描述、定义问题及其优先级,你就能和团队一起构想问题的解决办法,更好地完成工作,

如此一来,每个人的创造力都会派上用场,你当然会得到一个更好的最终解决方案。

在 Huddle 公司我最骄傲的一刻莫过于:仅仅一个写故事的时间过后,一位开发者向我走来,用10分钟演示了一个问题的解决方案;而这个问题我们原本打算花上3-5天(不是工时那种)来搞定。若不是他对用户和问题了如指掌,这根本就不可能。

所以,请不断地问自己:你想解决什么问题?

参考资料

马丁 《关注问题,而不是解决方案》(英文)mindtheproduct.com//11/focus-on-the-problem-not-the-solution/

延伸阅读

约翰 《产品管理与方案设计》(英文)johnpeltier.com/blog/2011/11/16/product-management-and-solution-design/

篇3:博客评论的排序问题交互设计

这不算是个新问题,感兴趣的可以先看看下边三篇文章:

振之:评论是倒序好还是顺序好?

秦歌:评论当然是顺序好

Harry Love:Never, Never, Ever Put Comments in Reverse Chronological Order

在上边最后一篇Harry Love的日志后面,有则留言提到了电子邮件的排序方式,我认为两者是有些相似之处的。

即日志列表和邮件列表都是按时间倒序排列的,而单篇日志后的评论和单次会话中的邮件均是按时间顺序排列为佳(见Gmail),

为什么?

因为:博客日志+访客评论=对话。评论的意义不在于抢沙发,而在于构成交流。围绕日志所提出的主题,作者和读者间发表意见,形成完整的对话。在对话中推动了主题的深入,也可能产生子话题甚至是与原文相去甚远的新话题。将评论按时间顺序排列其实也就是按逻辑顺序排列,读者可以看到对话的完整逻辑链条,易于理解,同时获得较好的用户体验。

通常在博客首页也会显示最新评论列表,该列表自然是按时间倒序排列,最新的评论显示在最前。这是因为该列表的功能不在于促成和展现对话,而是作为导航,显示最新的关注热点。

当然,如果你不习惯wordpress中默认的评论显示顺序的话,这里有改变wordpress评论显示顺序的插件。

来自:okce.net/posts/348

篇4:分页还是加载,这是一个问题交互设计

无论是在web页面还是手机应用,信息往往无法在一个页面全部展示,这就需要用到一些可以扩展页面信息的交互模式:分页(Pagination)和加载(Continuous Scrolling),分页和加载都是非常常见的交互模式,我们每天都会遇到,也正是因为太常见,我们甚至感觉不到它们的存在,浏览到页面的底部时,看到分页就顺手点一下,自动加载了就继续阅读。但正是这小小的一点,也会带给用户很不同的微妙感受。下面就来聊聊这些小差异带来的大不同。

分页

分页可以将大篇幅的内容分成小块,显示在单独的连续页面上,便于用户理解和查找。可以让用户清楚的知道,自己所要浏览的内容到底有多少、已经浏览到哪个部分、还剩余多少。分页可以使用户对所浏览的内容有清楚的预期。

篇幅较长的文章是一定会用到分页的。一是给用户内容多少的预期,二是可以给浏览者提供一个停顿。如果用户看一篇文章已经翻了十几屏,滚动条还是停留在浏览器中间靠上的位置,那该多绝望。

再来看看搜索引擎和电商网站,也一定会看到分页控件。

在搜索或是查看商品列表时,内容的多少根本无法预期,分页的第一个作用自然还是告诉用户要浏览信息的量。第二,分页可以让用户快速的跳过一些不想看的信息,或是快速跳转到首页或尾页,自主的选择想要浏览的内容。第三,分页非常便于定位和回找,也许在搜索一条裙子时,我已经翻到了第五页,突然想起第二页有条好像还不错,可以直接跳转快速找到它。

分页控件实际上是给网站的内容创造了一个自然的停顿,这个停顿运用得好的话,可以让产品更有节奏感。但是当用户浏览完一页的内容时,就必须停下正在进行的阅读,通过点击进行跳转来获取更多内容。不可否认,这个停顿会在一定程度上打断用户的思路。在遇到分页时,用户很有可能会去思考,是继续浏览呢?还是离开网站呢?所以遇到分页时,往往会流失一部分用户。

连续加载

连续加载是一个与分页相反的交互模式,信息之间没有明显的界限或是停顿。当页面滚动到底部,新的信息就会被自动加载进来。

各种社交网络就特别喜欢用这种控件,用户不会被打断,可以顺畅的一直浏览下去,沉浸其中,

但是由于信息是自动加载的,页面看起来好像没有结束,很难预测页面的内容到底有多少。一味的加载会让用户产生迷失感:这一页的内容到底有多少呢?我已经浏览了多少内容?我什么时候才能读完这一页呢?对于这种没有停顿的页面,用户想要搜寻之前看到过的信息时,也有些困难。但对于这种以休闲娱乐为主社交型的产品来说,使用不打断用户信息流的加载方式,还是非常合适的。

使用分页控件时,用户必须通过点击才能查看到更多的内容,所以说,信息获取是用户主动请求的。而使用连续加载时,新的信息是被自动加载进来,用户是被动的接受。

折中的方式

分页和加载各有利弊,如今的很多网站也会采取一些折中的方式:分页加载一起用。

如Quora,会在自动加载4次后出现一个“More”按钮,在连续的信息流之后,给用户一个停顿,让他们去主动的获取更多信息。

也采取了这种折中方式,自动加载两次后出现分页。对于大多数用户,在闲暇时浏览微博,加载两次的内容已经能够满足他们,对于需要浏览更多信息的用户,也让他们知道自己到底浏览了多少。

为了使用户可以快速看到更多图片,Google图片搜索也采用连续加载的方式,但在搜索图片时,用户也非常需要明确的自己的位置,也很有可能会回去找刚才看到过的图片,所以Google在同一页中也会标出页码,便于定位和查找。这也是另一种折中的方式。

手机客户端

在屏幕更小、使用场景更多变的手机端,滑动显然比精确点击更简单更不容易误操作。手机端产品信息架构相对简单,用户浏览时长相对较短,使用时注意力也相对分散。所以大多数app都会使用连续加载的方式。而且加载也比分页控件更省空间。

但像搜索引擎这样的产品,还是保留了分页的设计。

选择加载还是分页只是设计中一个很小的点,但出色的产品都是由无数个这样的小点组成的。根据产品的特点,选择最合适它的交互方式,就是交互设计师要做的事。

篇5:关于“用户问题”的严重程度定义交互设计

问题的定义说明:

1、用户问题:通过用户测试发现的问题,市面上也有人提“可用性问题”的,我还没想明白侧重哪个方面会更有利于产品的优化。

2、严重程度:就是某问题的严重程度- -~ 通常会和问题的解决优先级挂钩,也是问题发现者和问题解决者不断纠结的重点,初表现为产品设计者与开发者的冲突,或可用性分析师与产品设计者的冲突。

在这几年实际的应用过程,让我觉得,严重程度不仅仅是一次性问题的解决优先级,它在机制上其实应该和设计规范相辅相成,相互补充、更新。它反映的是对于某设计团队或对于某产品所要达到的设计目标中的一部分,具体的说是与用户使用相关的那部分。

所以可以说,严重程度部分反映的是,我们希望产品设计团队怎么做,关注什么,而且它所反映的设计要求是非常基础的水平,因为再往下就是“用户出问题”了!

严重程度的作用,在于:

和问题解决的优先级挂钩,让衡量标准透明化,其意义就相当于业务部门的KPI定义一样,便于大家目标一致,并且用相同语言沟通;

让产品设计师在考虑设计时,能“有依据”的“理性”的“结构化”的、考虑用户的意见;

OK,交代完背景,我可以安心的分享对于如何定义严重程度的一些小想法,只是个人想法,应用请结合当地环境哈。

严重程度的理论定义:

反映问题的影响面

反映问题对任务的影响程度

反映问题对产品目标的影响程度

使用我惯用的问卷设计方法,围绕上面三点,再结合支付宝产品需要特别解决的“新人使用难”、“使用效率低”问题,严重程度的操作定义是:

D1预估影响人数占比:依据实际样本占比+产品使用人数来预估

D2对产品成功指标的影响:产品设计师设定

D3是否导致任务失败

其次,需要关注的关键数据:

易学性:第一次使用成功率;困惑&需要帮助次数(用户问了或者自己找帮助去了);同类问题单个用户出现的次数

操作效率(需要先建立基线):时间;操作次数

当然这只是个方案框架,其中的权重、指标应用等还需要细化,本着研究的态度,我个人比较倾向于通过实际数据来不断优化这个方案,

而不是断层的依据设计目标变了,某个人想法变了就调整掉。优化的目标应该是让严重程度的指标越来越敏感,且接近研究效度。omg- -

罗嗦的再次重复,这个框架的优化非常关键的一点是与产品设计目标的协同。所以不要认为这是“用户”的单恋产品,这是用来指导产品设计的一部分。必须有产品设计规划者的参与。

最后附上我参考的同类产品做法吧,我收集的还不够多,国内关于这些细节的思考异常的低调啊。

参考1:Nielsen:影响人数+对用户体验的影响大小

一、对用户体验的影响(1-3分)

1、会让参加者心烦或沮丧,但不会导致任务失败

2、和任务失败有一定关系,但不会直接导致任务失败。(例如走弯路、影响效率和满意度)

3、直接导致任务失败

二、预计的发生频率(1-3)

三、对商业目标的影响(1-3)

参考2:

影响人数

能克服人数

单个用户发生的频次

参考3:

P1绊脚石:除非被修正,将造成严重问题

P2重度影响:对网站/应用的可用性有显著影响

P3中等影响:有造成负面影响的潜在可能

P4轻度影响:不大可能造成显著影响

其次,关键的参考数据:发生问题的人数;人们在该问题上花的时间;问题造成的结果;进度安排的影响;对易学性的影响;错误数量;整体满意度

本文来自:www.iefen.cn/?p=381

交互设计面试自我介绍

方便和交互设计

交互设计专业就业前景

不同声音,一个设计交互设计

全屏弹出广告交互设计探讨

人类文明的引擎教案

惊!Google+抄袭Facebook页面?交互设计

我是我产品的用户交互设计

发动引擎三年级作文800字

图形引擎存高危漏洞

关于推荐引擎的5个问题交互设计(集锦5篇)

欢迎下载DOC格式的关于推荐引擎的5个问题交互设计,但愿能给您带来参考作用!
推荐度: 推荐 推荐 推荐 推荐 推荐
点击下载文档 文档为doc格式
点击下载本文文档