Category Archive

The following is a list of all entries from the UI & UE category.

分类VS标签

Article copyright by usabilitypost
usabilitypost版权所有
作者:Dmitry ;译者:UCD翻译小组,晓禾依树
原文地址:http://www.usabilitypost.com/2008/10/17/categories-vs-tags/

以内容为中心的网站,比如博客和在线杂志,都有各种各样的方法来组织和分类管理他们的内容。用日期或作者来分类文章通常是由内容管理系统自动完成的。除此以外,还有两个概念可用于组织管理你站点的内容:分类和标签。尽管你能同时使用这两种方式,但这样做可能会太麻烦。那么到底应该用哪种方式,又为什么要用这种方式?让我们依次研究一下分类和标签。
 
分类
分类就好比文件夹——相同主题或话题的内容通过分类收集在一起。这个定义或许并不严格,因为在数字世界,你可以为你的内容赋予不只一种分类,但它的功能是相同的——都是归类。
分类最大的优点在于有固定的分类在那儿,如果你想要好好利用分类,那你的分类不能太多,这样人们才能迅速浏览一遍分类目录,很快找到他们想看的主题。分类能给你清晰的内容结构和简单方便的浏览体验。
分类的缺陷则往往由内容发布者造成。首先,你需要确定你要使用的分类目录。这通常要比想象的困难,因为你需要确保不会造成有些分类内容太多而另一些则内容过少。如果所有发布的内容都可以归于一种分类,或者某分类下只有一篇发布内容,那就完全没有必要设置这个分类。其次,每次发布新内容的时候,你都需要确定把它放在哪个分类底下。如果你能维持一个简短的分类目录,并为同一内容赋予多个分类,那这种方法不会太难,不过仍然需要花点心思。
 
标签
标签是现实生活中真实标签的数字化形式,是你贴在物体上的小标记。标签之于分类有个优势在于它不是事先设定的。当你贴标签的时候,你需要用手去写,并且可以自由地写任何你想写的内容。如果一个标签之前不存在,那一旦你用它发布,它就存在了。不用担心找不到合适的分类来放入你要发布的内容,只需要写下你感觉最能代表你发布内容的标签就可以了。
标签的缺陷则是在浏览体验方面。一种最流行的标签浏览模式是使用“标签云”。标签云是一大片一个挨着一个的标签,每个标签链接尺寸不一,决定于使用该标签的内容条目多少。
标签云能够很形象地表现出这个站点上哪种内容发布最多,但通过标签来浏览比较困难,因为常常有太多的标签。另一个问题在于标签的不均衡——有可能一个标签下只有一个内容,而另一个标签下有数千条内容。
 
OK…那么我用哪种呢?
答案就是……看情况。它取决于你有什么样的内容以及你的搜索功能是怎样的。
如果你有个像YouTube或者Flickr那样的站点,用户可以提交自己的内容,你有成千上万用户提交的内容,那分类或许就不如标签有用了,因为每个分类底下可能会有数千条内容,这让浏览变得异常困难,而且在多数情况下无法忍受。每个标签也可能会有数千条内容,但还有更多的标签更专注于某个领域或结果;同时使用标签组合也可以大大缩小用户需要浏览的搜索结果范围。
如果你的站内搜索使用标签来检索记录,你会发现标签有明显的好处。如果你的搜索很简单,只是依赖别的搜索引擎,比如Google,然后用你的站点地址过滤结果,只显示你站点上的内容,那标签可能就没那么有用了,因为搜索引擎几乎不会理会你的标签的。
我认为就博客而言,标签没有太大意义。当然,贴标签可能比较容易,但浏览体验可能就没那么好了。有些时候你一个标签下只有一篇日志——那有什么用呢?人们通常想寻找特定主题下的日志,而那正是分类的首要功能。况且,你也不限于只使用一种分类——要是你认为这篇日志同两个主题相关,那你完全可以同时发布到两个分类下。
这只是我对于标签和分类的理解,我肯定有些人会有不同看法。我很想知道你们在博客上用分类还是标签(或者两种同时用),为什么你更喜欢它们其中一种——请在下面的评论里谈谈你的想法。


The 3 Q’s for Great Experience Design

Q1: Does everyone on your team know what the experience will be like interacting with your offerings five years from now?

5年是一个很好的分界线,太近,会受到诸多现实因素影响和阻碍,太远,又容易陷入科幻小说式的联想。5年后的产品会带给用户什么样的体验,不需要说明具体的产品,但要描述出用户的使用场景。当团队中所有人都认同相同的场景时,大家都会朝着相同的方向去思考具体产品的设计,那么距良好的体验也就不远了。

Q2: In the last six weeks, have your team members spent at least two hours watching people experience your product or service?

产品策划团队应该参与到经常性的定期的用户测试中去,测试之前,UX组需要和策划组确认测试问题,测试中,策划团队尽量派人参与,有条件的话可以设立专门的观测房间,或者观摩测试过程录像,包含环境录像和屏幕录像。这类用户测试最好是观测用户对产品的使用,而不是用调查问卷或满意度测试来代替,因为后两种测试往往不能回答用户在产品使用过程中为什么遇挫或者感到愉悦的原因。需要记住的是,团队成员自身对于产品的体验永远无法代替真实用户的体验,这两者绝对会存在大差别。

Q3: In the last six weeks, has your senior management held a celebration […]


Comparing Design Alternatives

By Jared Spool


"曲线"用户研究

   From www.ui123.com 
      在很多时候,公司未必给予我们提供充足的条件让我们专门从事用户研究;抱怨之余,我们应该积极的为设计找些支撑点。在此分享一下,我们在没有专门的用户供研究的情况下是如何做用户研究的,那就是:分析同类产品的用户。因为不是直接研究自己的目标用户,所以在此称为“曲线”用户研究。但这些方法仅适用于有经验并且有分析能力的设计师,因为有经验的设计师知道自己需要什么,有分析能力的设计师可以敏感的发现信息,并准确的分析出有用信息。
1、分析同类产品的用户案例
       在做音频编辑产品的时候,我就通过视频搜索,搜索到很多关于视频编辑的教学短片,有些是用户自录的使用视频,观看这些视频,设计师可以直观的看到用户是如何操作的,在操作的时候,那些感觉麻烦,哪里常犯错,那些功能是经常使用的,等等。通过分析之后,我们可以得到主要功能列表和简短的使用场景。在接下来的设计中,我们可以以此为支撑点,通过思考加工,变成有价值的设计依据。起码我们有靠谱的资料做支撑,比起拍脑门做设计要强很多吧!
2、分析同类产品的反馈论坛
        在同类产品的反馈论坛中,有用户反馈的许多问题,这些问题值得我们直接借鉴,就像研究历史一样,“以史为鉴”可以让我们避免犯重复的错误。要不然,我们不可避免的还要像我们的对手一样再次走这些弯路,既然我们有了可以避免的途径,为何不“以史为鉴”呢。在同类产品的反馈论坛中同样有着很多用户提出的需求,很多需求很值得采纳,还可以基于用户的描述来构建需求的使用场景,甚至勾画出简单的使用原型。同时用户提出这些需求表明,对手还未做到,我们通过“对手的信息”,以此来超越对手。对用户关注程度是根本,因为关注用户,我们能得到更贴切的功能,更多的需求,设计出更易用的产品;同时意味着产品能挣更多的钱,因为用户会因此而“买账”。
3、观察同类产品的用户
        如果是在线的产品,我们可以凭经验选择几个典型用户进行观察,观察“典型用户”使用最多的功能、操作方法、组织内容的习惯、喜好等,我们可以从中分析出那些功能对用户是有用的,那些操作更有效。如果有充足的时间,我们可以进行稍长时间的观察,通过统计,从而得出用户的使用习惯及规律,而这些在以后的设计中,将直接影响产品的结构。
小结:这些方法仅适用于你有对手,这些观察和分析,不但可以让设计师得到想要的原始用户素材,还能分析出对手的优缺点,为产品的定位和如可切入市场提供了有效帮助。


UXD——不是一个人的舞台(二)

UXD-P需要考察用户的观点,行为和交互过程,需要找到我们提供的产品和用户之间的情感联系。大多数情况下这些用户和他们的经验都是未知的,需要深度地探讨他们的人生旅程,个人历史和经验。
经验是一个集合体,它包含了线上、线下和任何微小的事情所带来的影响。这关系到去体察用户未满足的需求,能力和欲望,而这些又是相互关联的。
Peter Morville的UX 蜂巢

我们需要问用户下述的问题:
Is the application useful for the individual user and his specific task?
Is the application usable for the individual user and his specific task?
Is the application desirable for the individual user and his specific task?
Is the application valuable for the individual user and his specific task?
Is the application accessible? […]