导航作为用户体验重要组成,仅仅是达到目的的一个手段——目的就是
消费内容。这就是为什么用户对内容和导航会有不一样的期望。内容应该是独一无二的、令人惊讶的、令人激动的,导航应该是简单的、尽可能符合预期。
这个系列文章,分为两个部分,是一个「四步走」的指南,用于简化导航的体验。通过分析内容的类型和数量,选择并精心设计正确的导航菜单。
「四步走」——理想的导航系统
要做一个可用的导航系统,网页设计师必须按顺序回答以下4个问题:
- 如何组织内容?
- 如何解释导航的选项?
- 哪种导航菜单最适合容纳这些选项?
- 如何设计导航菜单?
前两个问题关注构建和便签内容,通常称为信息架构。信息架构师通常用网站地图(site map diagram)来可视化他们的工作成果。
sitemap<small>网站地图给出一个网站的导航结构。(图片:Web Tuts)</small>
然而,由于某些原因(后面会详细解释),用网站地图来并不能提供最好的体验。设计一个定制导航菜单,容纳、整理、逐步揭开它们的选项也是很重要的,所以要让用户舒适地浏览、寻找、忽视选项。
成功设计这样一个导航菜单,还需要回答后两个问题,这关乎到导航体验的交互设计。前两个问题会在Part 1里谈到,后两个问题在Part 2。(Part 2还没写!!)
构建内容
要恰当地构建网站的内容,首先要考虑用户是如何寻找信息,然后用与之适应的方法来构建内容。
用户是如何寻找信息
当用户找些什么东西的时候,如,车、食谱、财务服务、衣服…… 他们不一定知道这些东西的确切名字。如果我们假设用户知道它们的确切名字,那么我们就认为最近的方法就是提供一个A-Z的索引表,又或是提供一个搜索框。
事实上,事情并不是这么简单。即使用户知道确切的名字,A-Z的索引表和搜索都会有先天的交互问题,它们不能成为主导航,这个放到Part 2中再讨论。然而,用户通常不知道确切的名字,他们也不关心这些名字;他们有关键字或是关于物品的特征描述。
指引用户找到正确内容的第一步,汇集并分类网站的内容。
元数据(META DATA)是导航系统的基础
元数据就是收集内容的信息——信息的信息。
不需要理会具体内容,每个条目都归属于不同的元数据类别,如:政治类文章、屏幕尺寸、视频的导演、衣服的领口……当然,还有一些类别是大家共有的,如:价钱、受欢迎程度……
通过这些元数据类别,用户可以浏览内容。然而,给用户提供所有的可能方式去浏览内容时不现实,也没好处。这样会让界面混乱,让导航的过程变复杂,甚至会混淆用户,以至于他们会抛弃这个网站。
小心地考量是否要,或是在哪个阶段展示这些类别。
元数据类别的3种类型
决定什么时候展示元数据类别,首先把类别划分成3个组别:重要的,可选的,无关的。
信息架构的一大挑战就是按照重要的,可选的,无关的来分类,这很大程度上取决于目标用户的偏好,网站的目的,内容的量。一旦你选定了适合的分类标准,这里有一些简单的规则来帮你决定什么时候展示什么类别。
重要的类别
重要的类别是指对所有目标用户的很重要。这样的类别一般较少,但至少每个条目都会有一个重要的类别,这可以简化设计师的工作,同时提供更好的导航体验。
决定重要类别
对食谱来说,元数据的类别可能是“过程”、“原料”、“特殊饮食”、“场合”、“烹饪方式”、“烹饪时间”。在这些类别中,最重要的可能是“过程”。不是每个人都有特殊饮食喜好,也不是每顿饭都会有特别的场合,但是几乎每个人都会把他们的餐饮分为开胃菜、主菜、配菜、沙拉、甜点等。
由于“过程”对每个人来说都是如此重要,首先提供的类别就应该是“过程”。
courses1<small>食谱中,“过程”是最重要的元数据类别。(图片:Our Best Bites)</small>
就像前面提到的,目标用户或是网站目的会影响分类,特别是小众网站(niche websites)。
例如,“烹饪方式”与一般人去食谱的网站的目的没有联系。但是如果有一个网站收集了地球上最好的烹饪食谱,“烹饪方式”可以成为重要类别,你可以增添这样一个重要类别,也可以取代“过程”成为唯一的重要类别。无论如何,“烹饪方式”才是这个网站的主题,先展示它才是最适合的做法。
cusine<small>小众网站会有不一样的重要类别。(图片:Recipes by Nation)</small>
整理重要类别
上面的例子是有一个重要类别。然后,当你有一大堆条目,就会有各种不同的重要类别。
拿衣服做例子。衣服的类型是一个重要类别,如:“衬衫”、“裤子”、“鞋”、“毛衣”……还会有其他类别,性别、场合,如:“休闲”、“工作”、“舞会”。我们还能找到更多的重要类别。
一开始,把所有的重要类别放在同一个层级似乎很有逻辑。事实上这样做完全不符合逻辑。重要类别应该一个接一个,有顺序地出现。看下下面这个网站信息架构,你大概就明白。
information1<small>水平的导航栏通常会列出所有种类的商品。(图片:LL Bean)</small>
这个导航栏列举了商品的种类,“居家配件”、“打猎&钓鱼”、“户外工作”、“鞋”、“衣服”。但是,对于“衣服”这个类别,设计师做了一点不一样的处理。衣服被划分成“男士”、“女士”,而不是把各种类型的衣服都列举在这个水平的导航栏上,设计师决定用更少的分类。用户从“男士”、“女士”开始,然后才在下拉菜单中看到衣服的所有种类,从而提供更多的选项。
clothes1<small>用更少的分类来腾出空间。(图片:LL Bean)</small>
这样的处理方式产生的问题就是,两个分类放在同一个层级里面。“鞋→男士”和“男士→鞋”两种路径,它们处于相同的层级,使得用户要在其中做出选择,这破坏了两种分类都很重要的假设。因此,其中一条路径应该会去除——大概是“鞋→男士”吧。
可选的类别
如果有多个重要类别存在,那么其中一些条目就无需纳入其中。如果一个网站只有十多个衣服条目,那么只需要简单地提供“男士”、“女士”的选择就好。
在很多案例中,事情走向了另一个方向。即使使用了所有的重要类别进行筛选,还是出现很多条目。所以,需要额外的类别,让用户进行进一步筛选内容。可选类别就是出现在这种情形。
可选分类对部分用户有用。例如,“汽车”的两个元数据类别,“门的数量”、“燃料类型”。一些人可能对燃料特别感兴趣,不太介意是几门的汽车,而另一些用户可能会有相反想法。
重要类别优先于可选类别
可选类别应该出现在用户使用主要类别进行筛选之后。
然而,很多零售网站,譬如卖电子产品或是时装,会把品牌(可选类别)放到和产品类型(重要类别)一样的层级。
brands1<small>重要类别和可选类别应该放在不同的层级。(图片:Flipkart)</small>
这个方法会出现的问题:如果用户选择了一个品牌,然后就会出现上百个条目,他就必须选择衣服类型进行进一步筛选。所以把可选和重要放在同一个层级会增加多余的路径,添加选择的复杂性、导航的混乱度。
提供各种过滤器不是坏事,但是不要在一开始就把各种导航选项提供给用户,先提供重要的选项,重要的选修都用完了,再引入可选的。
所以,上述的案例,在这个层级里去掉品牌,先让用户选择衣服类型。再下一个层级中,才提供品牌的选择。
optional_categories1<small>只有在用户已经选择重要类别后,可选类别才能出现。(图片:Flipkart)</small>
动态过滤器
前面提到,重要类别应该一个接一个,有顺序地出现。所有可选类别最好是同时提供。
除了一种例外情况,如果可选类别互斥,那么它们就应该像重要类别那样处理(前面提到“男士”、“女士”就是一组互斥的类别),出现在下一个层级的同一菜单中。如果可选类别可能会被合并,它们就应该做成动态过滤器。
在下面的截图中,可以看到Sears在面包屑路径中列出了重要类别,可选类别就成为冬天过滤器。
crucial<small>可选类别被合并成为动态过滤器。(图片:Sears)</small>
重要类别和可选类别之间的差异可以这样解释。每一个类别都是一个内容的过滤器,动态过滤器之所以动态是因为它允许用户选择和改变多个多个值。相反,在传统的层级化导航系统里面,用户只有在不同的层级才能选择值。如果是重要类别,像之前的例子,就不会出现问题;但是可选类别,情况就不一样了。
当用户寻找一件衬衫,很多可选类别都会发挥作用:“品牌”、“衣领类型”、“袖长”、“布料”、“图案”、“口袋数”、“折扣”、“价钱”、“评价”、“受欢迎程度”等等。了解用户纠结对哪个类别感兴趣是很困难的,有的人可能都没兴趣,有的人会对多个、甚至全部都感兴趣。
与其一个接一个地给出可选类别,设计师应给提供一个动态的可选过滤器。这样,用户就可以只选择感兴趣的类别。
相反,下面的网站就没有明确区分出重要类别和可选类别。它把所以类别,包括重要类别都做成动态过滤器。
filters1<small>重要类别不应该做成动态过滤器。(图片:Nike)</small>
区分的缺失会导致一系列问题。第一,占据了大量竖直空间,使其他可选类别往下移,让用户经常滚动才能看到,并做出选择。
第二,动态过滤器是一个“重型装备”:它很厉害,但是很耗费资源。当用户选择一个值,整个列表的值也会随之改变。这个提供了及时反馈,但是交互却变慢了。用传统的导航菜单,选择重要类别也能得到相同的结果,而且也会更快。
事实上,Nike的设计师的确提供了这样一个菜单,让我们验证了这个假设,在同一个界面里面测试两种方式的方式,比较他们的速度和效率。
menu_bar11<small>重要类别还是应该做成传统的导航菜单。(图片:Nike)</small>
互斥类别
动态过滤器只有在可选类别可以被合并时才能使用。如果可选类别是互斥的,那么它们就应该放在主导航菜单的下一个层级。
下面的截图,Daily Express在最开始就问了用户一个问题:选择一种新闻的类型,如:“财经”、“娱乐”、“生活”。然后在主页的选择部分,会给出这个类型的一些新闻摘要,几乎所有用户都会去看其中3~4篇新闻。对于那些想要看特定主题的读者,在第一层导航下面列举了子栏目。
news11<small>互斥的可选类型最好放在主导航菜单的下一个层级。(图片:Daily Express)</small>
上面的子栏目可以视作互斥类别,应为一个娱乐项目不会既是一本书,又是一个电影。当然,合并也是可以的;书也可以放到电影栏目里面,但是文章摘要又怎么匹配这种分类方式?如果不能匹配,那动态过滤器就有意义。
这个问题的答案,取决于条目的数量和多样性,而不是类型,当然也取决于目标用户的偏好。
譬如,用户不会寻找中式、低脂、圣诞主题的早餐;相反,他们会去找一个既不中式,也不低脂,也不是圣诞主题的早餐。可选类别就很难合并在一起,如果一个网站有上千个食谱,而目标用户又会有各自的偏好,动态过滤器就会很有用。
mutually_exclusive1<small>一大堆不同种类的内容+个性化的用户偏好,就需要动态过滤器。(图片:Food52)</small>
最后,第3个元数据组别。
无关类别
无关类别就是目标用户不看的内容,但是它们也是交互中的一部分。
文章的元数据类别里面“字数”、“图片数”。这些类别都会在数据库中占据位置,内容策划者可能会查看这些类别,来推断文章是否过长,是否太少图片。这可能是用户没看完内容就关闭网站的原因。内容策划者就会与设计师或者客户讨论这些可以提升内容质量的东西。这些类别对设计师很有价值,但是用户不会因为“字数”、“图片数”来选择文章。
简单来说,无关类别不应该出现在页面,它们会被忽视,会照成界面混乱,甚至混淆用户。但是,无关类别可以转化为可选类别。
例如,“字数”可能是个无关类别。但是下面的网站就积累了大量文章,因此设计师觉得有必要增加“文章长度”作为内容的过滤器。
figures1<small>无关类别可以转化为可选类别。(图片:Time)</small>
上面展示食谱、衣服的网站也可以用来解释优化类别的重要性,因为它们对元数据类别有需求。但是它们没有谈到一个很多设计师都会遇到的问题,特别是设计公司网站时会遇到。
公司产品分类
很多食谱网站会不加选择地收集食谱,然后让设计师去分类。但是公司通常都有内部的产品分类方式。这就可能会与需求冲突。
譬如说汽车的元数据类别。你可能会根据尺寸或是生活方式,如:“紧凑型”、“旅行车”、“运动型”、“轿车”、“豪华型”。这样的分类很重要,因为每种车都是根据特定的生活方式设计出来,几乎对每一个驾驶者来说都是如此。紧凑型,就是小巧、便宜、易于驾驶和方便停车;旅行车就很适合家庭;运动型……
很多汽车公司都会有自己的分类方案。宝马,就是按数字来进行分类。
car<small>有时这种分类方案很有效。(图片:BMW)</small>
这种公司的内部分类方案会导致可用性问题,宝马的方案在信息架构上的确很好。这种方案知名度也很好,数字与车的尺寸相匹配,某种程度上也算是典型的以“紧凑型”、“轿车”、“豪华型”进行分类。在这个案例中,换成其他分类方式反而会让用户不适。
下一个例子就没那么直白。Opel用自己的内部命名约定来列举车。
corporation1<small>内部分类对外部用户就不够直接。(图片:Opel)</small>
这种产品线的架构不清晰,而且这样的滑动浏览汽车的交互也很麻烦(唔……这是一个交互问题)。用户不能理解车与车的区别,也就不能按照喜好来过滤。
如果分类方案本身不够好,那么一个让人熟悉的外部类别的优先级应该更好。
注意到,大众也有自己的名称分类:“Jetta,” “Passat,” “Touareg,” etc. 但是公司最注重常见的外部方案。结果就是,菜单更容易被理解,用户也能更专注于他们喜欢的产品线。
cars1<small>优先使用常见的外部方案使导航菜单更容易被理解。(图片:Volkswagen)</small>
客户可能不喜欢他们的分类方案归为次要位置。但是,信息架构师就是被请来把网站内容变得易于浏览,你有与客户沟通的义务。
解释导航选项
根据用户偏好来做构造导航选项是简化网站信息架构的重要一步。但如果用户一开始就不能理解这些选项,那最精巧的架构都没用。所以,先要考虑解释导航选项的最佳方法。
给用户足够的理解选项的信息量。过多的信息会有混淆界面,减慢导航,甚至让用户放弃使用的风险。
也不要给太少的信息。如果用户要猜测,链接指向哪里,哪里结束,他们很快就会对界面失去信心,离开网站。
设计师可以选择一种方式来解释导航选项:
- 标签
- 标签+图
- 标签+图+描述
选择正确的方式,先评估用户对标签的熟悉程度
标签
如果你用的标签已被人熟知,那么只使用标签就够了。解释“牛仔裤”、“短裤”、“衬衫”、“夹克”不需要使用大图和长描述。
labels_only2<small>熟悉的条目,用标签足够了。(图片:Rock Revival)</small>
保持标签很值得称道,但简洁不应该以清晰为代价。缩写和术语可是可以的,如:UX, BMI(body mass index),前提是目标用户熟悉它们。
有时,尽管术语本身没有问题,但是前后文可能会让它产生歧义。很多大型机构的网站包含一个固定水平导航来指向机构的主要业务,和一个随内容变化的竖直导航来指向下属机构。这样会出现重复的标签。巴斯大学(University of Bath),“研究”这一标签出现在全局导航和左边的竖直导航里。
duplicate_labels<small>有很多下属机构的大机构经常出现重复标签。(图片:University of Bath)</small>
虽然这个会迷惑用户,细致地设计就可以避免歧义。上面这幅截图,菜单上面的标题“探索部门”就是很好的提示,下面的“研究”是指部门的,而不是学校的。或者我们可以使用长一点的标签,“关于我们”改成“关于此部门”之类的做法。
另一个给标签语境的方法就是使用数字,来表示这个类别下面有多少个条目。
statistic<small>在某些菜单中,数字可以配合标签一起使用。(图片:BJ's)</small>
这样的数字经常出现在动态过滤器中。
filters_statistics<small>动态过滤器旁边经常会出现代表条目的数字。(图片:eBay)</small>
很多用户喜欢数字,但是要注意考虑什么时候展示它们。例如,浏览首页的时候,用户通常都不知道有多少内容。这时候给出有多少内容就可以说服用户,他们会想,“这里一定有我想要的。”
statistics<small>在首页标注内容数量可以说服用户。(图片:O’Reilly)</small>
当然,如果内容不多的情况下,你一定不想公开这个数字。
同样地,用户浏览分类,然后找到感兴趣的主题,他们会查看相关的类别,即使只有几个条目,又或者有很多条目。但是,这个时候展示数字就减低浏览速度,也会混淆界面。
statistic11<small>在某些情境,统计数据会妨碍用户。(图片:Digistore, Ministry of Education, New Zealand)</small>
动态过滤器也会有同样的情况。用户会因为条目的数量而选择某个类别吗?如果是,那就标出数字就讲得通。如果不是,那只有那些你会去除,或者以灰色标注的类别旁边会有个“0”。
要不,用户选择某一个类别,才显示类别的条目数;或者在动态选择器选择类别,才显示相应的条目数也是有用的信息。
图标是另一种会出现在标签旁边的元素。精巧而又识别度高的图标是很有用的附加物。无需解释选项的区别,图标就是很好的区别。下面的截图中,我移走了菜单上的图标,你会注意到标签本身就可以解释选项的意义。
labels_without_icons1<small>标签足够了,但会花费一点时间去识别。</small>
然而,加上图标可以让用户更好地识别和区别选项。
labels_with_icons<small>图标使得识别的过程变得更容易。(图片:Mobile.de)</small>
但是,只会图标会也会让人迷惑。即使图标已经为大家所熟知,用户还是不太确定究竟它代表什么。
标签+图
对于熟悉的条目,标签和图标都很好用。对于特殊的条目,图片就很有必要。例如,品牌名称。下面的截图里,车都是以纯文字出现在菜单。
labels_and_pictures1<small>品牌名称只有标签是不足以被理解。(图片:Subaru)</small>
我不知道“Tribeca”和“Legacy”分别代表什么。标签不足以让我做出选择,带图片的标签可能是一个更好方案。
pictures-e1376648165528<small>标签+图对于不熟悉的术语是个更好的方案。(图片:Mazda)</small>
在导航上用图片或图标是一件很有趣的事。譬如描述特定的产品,“13-inch Macbook Pro”、 “Samsung Galaxy Note 3”,除了产品图,没有更好的方案。
但是描述一类类别就没这么简单。在某些菜单中,图标可以被用来描述类别。
icons11<small>在某些菜单中,图标可以被用来描述类别。(图片:Flipkart)</small>
在另一些菜单中,会用真实的产品图片来做这件事。
pictures<small>在某些菜单中,会用真实的产品图片来描述类别。(图片:Flipkart)</small>
对于产品分类,图标可能比图片更适用。一个写实图标让整个菜单变得更专业。
用真实的产品图片还可能产生新的问题。用户会下意识问,“为什么这个产品可以代表这个类别?”、“这就是这个类别最好的产品?”、“我可以在这个网站找到其他产品吗?”……如果他们点进去发现第一个产品就是菜单上面的那个,这种忧虑还会扩大。相反,图标只是代表一个产品类别,仅此而已。
图标还是有一定的标准。如果画得不好,会显得很业余。如果不能被辨认出来,会混淆用户。所以当你无法保证图标的专业性和可识别性,还是用图片吧。
标签+图+描述
有时标签+图都不够用。服务商提供一些复杂的方案,譬如银行、保险经纪、ISPs,然后它们的产品名像这样,“50 Plus”、“Web on the Go”。一对夫妇跟保险经纪谈话,一个女孩在打电话,这样的图片无法描述服务商提供的服务。对于这种情况,几行描述+标签+图才是最有效的方法。
labels_pictures_and_descriptions1<small>复杂的产品就需要标签+图+描述,才能被理解。(图片:Naspa)</small>
头条、文章标题这类标签,可能需要,也可能不需要图和描述。
很多作家支持标题只需要关键信息点,而且要尽量简短。
headlines<small>建议:标题只需要关键信息点,而且要尽量简短。(图片:BBC)</small>
标题很简短,也有关键信息,但是这样的书写风格有它的风险,而且并不适合所有的网站。
应不应该,或者怎么样写描述。事实上BBC的标题是有描述的,上面那副图只是被我去掉而已。下面那幅图是有描述,你会发现基本上都是头条新闻的详细叙述,没有大量的新信息。
headlines-opt<small>描述包含标题未传达的信息。(图片:BBC)</small>
如果标题应该像上面那样用关键词来堆砌,那么描述的意义并不大。因为只阅读标题也能达到引导文章的效果。
然而,只有标题,或者用这种风格来写标题不一定是最好的办法。如果只是简短的新闻时间,BBC风格是一个不错的选作。如果是一篇长文章,标签+图+描述会更吸引人。
下面这个标题更注重吸引人,然后再用几行小字写信息点。图片可以设定基调。
headline<small>标签+图+描述更能深度阐释文章。(图片:World)</small>
从一个小片段了解文章并不困难。用标题抓住眼球,再用描述来阐释文章,再配图。这整个小片段给作者更多的空间去告诉读者信息,并传递文章观点。
那些关于标题的建议,让它在网站之外也被理解。因为标题通常出现在搜索结果、社交媒体、或是其他文章里面。有些作者会做得更多,为这个目的设计书写模板。
context<small>很多作者会尝试让标题更容易在其他地方被理解。(图片:Baymard Institute)</small>
但是在增添前后文的时候,注意不要增添多余的信息。
上图的标题就没有提供足够前后文,因为在网页设计里面,多栏式的版面可以出现在首页、菜单、文章页……并不局限于表格。所以,“表格可用性”这个额外增添的解释,就是脱离了原文。其实不一定增添这样一个东西,因为看文章的人大多知道这是在说什么。
搜索引擎的开发者知道,如果不能给出用户想要的搜索结果,用户就不会再用它了。所以他们会不断地提升结果的相关性,加上一段描述、图,改进算法——这些都是添加前后文的做法。如果一个标题出现在另一篇文章的的推荐阅读里面,文章本身就会提供前后文语境。至于社交媒体,一个人推荐的标题,关注他的人也不会不知道他在说什么。
总结
信息架构就是结构化、标签化内容,这也是导航的基础。设计师可有效地简化网站信息架构,通过为目标用户减少或增加导航的选项,同时也要减低这些选项的认知难度。
这篇文章的建议可以总结为两个列表,“结构化内容”和“便签化条目”。
结构化内容
- 收集和分类用于导航的元数据。
- 以重要的、可选的、无关的来给这个元数据分组。重要的表示对所有用户都很重要,可选的表示对部分用户很重要,无关的表示对目标用户不重要。
- 在第一个层级展示一个重要类别。
- 如果第二层级的内容不多,那就不再分类;否则,按顺序,分层次提供其他重要类别。
- 所有的重要类别都用完以后,列出所有符合要求的内容。
- 如果剩余内容很多,可以在一个层次里面使用所有的可选类别。
- 如果可选类别互斥,那就再增添一个层次。如果可选类别可以合并,那就使用动态过滤器。
便签化条目
- 如果大家都懂标签的意思,那就可以直接用。尽量保持简洁明了。 可以在首页和分类页加数字标示内容数量。图标可以提高选项的识别度。
- 如果标签比较专业,那就考虑加图。用图标来解释选项,但是图标必须要画得好看,而且易认。不然还是用图吧。
- 对于复杂的服务或产品,要考虑为标签加图和描述。描述应该有新的信息而不只是复述标签。同时注意为标题添加前后文时,不要创造多余的信息。
当你简化完整个架构,用户就想要舒适的体验。因此你要设计一个容纳选项导航菜单,并且交互要舒适。关于这一点会在Part 2里谈到。
推荐阅读
- “Information Architecture 101: Techniques and Best Practices,” Cameron Chapman, Six Revisions
- “Classification Schemes (And When to Use Them),” Donna Spencer UX Booth
- “Information Architecture for News Websites,” Stijn Debrouwere
A series of six articles. - “Designing for Mobile, Part 1: Information Architecture,” Elaine McVicar UX Booth
- “The Elements of Navigation,” Petter Silfver, Smashing Magazine
A guide to simplifying and testing labels and icons. - Smashing Magazine icon packs
来源:smashingmagazine / December 3rd, 2013
作者:Anastasios Karafillis
翻译:lyzhie
网友评论