《用户体验要素》读书笔记 （五）
结构化内容 | Apr 7, 2018 at 21:25
在以内容为主的网站上，信息架构主要的工作是设计组织分类和导航的结构，让用户可以高效率、有效地浏览网站的内容。
同样的内容，根据不同的方式排列组合，就能给予用户不同的感觉，合理的安排信息内容，可以让用户在快速浏览的时候能够快速了解到你想要表达什么，这块内容到底谁是重点。我应该看哪些内容。用户不会一开始就读你的产品，而是快速的浏览，只有碰到感兴趣的地方才会聚焦视线，细细阅读相关的内容。
从上到下（top-down approach）的信息架构方法将从战略层所考虑的内容，即根据产品目标与用户需求直接进行结构设计。先从最广泛的、有可能满足决策目标的内容与功能开始进行分类，然后再依据逻辑细分出次级分类。这样的“主要分类”与“次级分类”的层级结构就像一个个的空槽，而内容和功能将按顺序一一填入。
信息架构的方式建立的方式通常有两种，从上到下的方式，就是从战略层考虑内容，以一个目标为导向的方式，想起了Google OKR的过程，由目标出发，在乡下延展分支。
从下到上（bottom-up approach）的信息架构方法也包括了主要分类与次级分类，但它是根据对“内容和功能需求的分析”而来的。先从已有的资料（或者当网站发布后将存在的资料）开始，我们把这些资料统统放到最低级别的分类中，然后再将它们分别归属到较高一级的类别，从而逐渐构建出能反映我们的产品目标和用户需求的结构。
这种建立的方式，通常是先把自能够获取到相关的信息都给搜集一遍，然后排列组合，可以分类归纳出相关的信息，从而找到上一层的归属。两种方式都有局限，从上到下的方式可能导致内容的重要细节被忽略，从下到上的方法则可能导致架构过于精确地反映了现有的内容，不能灵活的容纳未来内容的变动或增加。
结构质量最重要的标准，不是“整个过程一共需要多少步骤”，而是“用户是否认为每一个步骤都是合理的”，以及“当前的步骤是否自然地延续了上一个步骤中的任务”。毫无疑问地，用户会喜欢一个被清晰定义的七步过程，而不是一个令人困惑的、被勉强压缩的三步过程。
用户是否认为每一个步骤都是合理的，用户在队产品操作的时候通常会有一个预期，你的产品能否达到预期，或者超出预期。如果这个预期偏离的太多，产品就变得间隙非常的大，用户会容易理解不了。如果能减少步骤当然是好的，但也要让你的步骤符合用户的预期。
一个完整的用户体验，包括网站结构，都是建立在对网站目标和用户需求的理解之上的。如果你要重新定义网站希望达到的目标，或是之前设想的、网站必须满足的需求发生了变化，那么你就应该准备相应地重新调整网站结构了。但是，像这样的结构变动很少会有事先的预告，当你发现需要重新调整结构时，用户常常已经被折磨了一段时间了。
对网站目标和用户需求的理解，就是战略层来确定的。多花点时间放在里面，对产品的工作会有很好的帮助，这块的内容不是假大空的空话，产品经理一定要充分的理解产品的目标。如果你的下层基础发生了改变，原来的信息架构就需要重新的思考。
结构方法
信息架构的基本单位是节点（node）。节点可以对应任意的信息片段或组合—它可以小到是一个数字（比如产品的价格），或都大到是整个图书馆。我们要处理的是节点，而不是页面、文档或组件，这个思路有助于我们使用一种共同的语言和一组共同的结构的概念来对付各种不同的问题。
在进行信息架构的过程中，最好将其抽象成一个节点，脑图工具就是一个不错的方式。通过点和线关联各个信息的架构和描述之间的关系。抛去了其他因素的干扰，只从信息架构的层面上进行思考。
组织原则
节点在信息架构中是依据组织原则（organizing principle）来安置的。从字面上来讲，组织原则基本上就是我们决定哪些节点要编成一组，而哪些节点要保持独立的标准。不同的组织原则将被应用在不同的区域和网站不同的层面。
节点的汇聚一定是要有逻辑，这样容易提高信息传递的效率。相同或者相似的信息组合一起，或者同样信息多个维度进行组合，这里要决定哪些信息进行组合，那些可以省略，那些需要详细说明。
一般来说，你在产品最高层级使用的组织原则应该紧密地与“网站目标”和“用户需求”相关。而在结构中较低的层级，内容与功能需求将对你所采取的组织原则产生重大影响。
一切都表现的根本目的都是以战略目标为核心的，这些组织的原则也应该是以核心需求为导向。这样组织的目的能否达到需求的要求。是主要的评判标准。里入一个新闻的内容，通常是以时间顺序作为她最显著的组织原则。用户希望看到的新闻时实时的信息。
除非你的信息非常简单，只包括几个不同的截面，否则这种方法很快地就会把信息架构变得既笨重又混乱。由于用户有太多的方法可以将信息排序、过滤，这就造成没有人能找到自己想要的东西。这样的负担（让用户自己使用所有的属性来排序，并且挑选什么是重要的）不应该丢给用户，应该由我们来解决。战略告诉我们“用户的需求是什么”，范围则告诉我们“什么样的信息将满足那些用户需求”。在创建结构时，我们就要具体地识别出用户心目中至关重要的那些信息。成功的用户体验，就是能事先预知用户的期望并将其纳入设计之中。
这里说的“这种方法”是指，用户可以自己选择维度。有的时候用户不需要完全的自由，最好的用户体验都是在一个范围里，苹果的产品，你只有使用了他们家所有的产品所能得到的体验才是最无缝的。但是如果超出去了。就不一定了。用户需要引导，有的时候自由度过大并不好，会给用户过多的负担。并且易用性上来说也是打折的。
语言和元数据
与用户谈话并了解他们的沟通方式，是开发出一个让用户感到自然的命名原则系统的最有效方式。创造并遵守一个反映了用户语言的受控词典是防止企业内部的专用术语侵入网站的最佳方法，那些专用术语只会让你的用户感到糊涂。
产品里面的语言在内部要统一说法，在外部也要统一口径，同一个功能不能因为语言习惯不同，在团队里就有多种叫法，这样会在后期的交流中增加了额外的沟通成本。对内的词汇在相关文档明确即可。对外的口径则是要考虑到用户的习惯，尽量避免使用专业的术语，你高冷了，用户会对你的产品感到困惑，用户需要学习。
第6章 框架层 界面设计、导航设计和信息设计
在充满概念的结构层中开始形成了大量的需求，这些需求都是来自我们的战略目标的需求。在框架层，我们要更进一步地提炼这些结构，确定很详细的界面外观、导航和信息设计，这能让晦涩的结构变得更实在。
与之在产品设计对应的是原型图，线框图的部分。在产品设计的时候不要先画线框图，因为如果是这样子，流程错误了，你就需要重新的绘制，这个页面信息错误了，你就要改线框图，对于产品经理来说这算是一个不小的工作量。最好的是先吧业务逻辑都理顺了，然后页面逻辑，最后才是线框图。
框架层定义
框架层则用于确定用什么样的功能和形式来实现。除了解决具体的这些议题，框架层还要处理更精确的细节问题。在结构层，我们看到一个较大的架构和交互的设计；在框架层，我们的关注点几乎全部在独立的组件以及它们之间的相互关系上。
框架层就开始接界面设计，这个产品的好坏不要只看到这一层，某个交互细节很好。一般用户看到的界面就是这一层面，产品经理要学会通过观察表现层和框架层来还愿产品的结构层，以及范围层和战略层。
对于功能型产品，我们通过界面设计（interface design）来确定框架—一个大家所熟知的、“按钮、输入框和其他界面控件”的领域。但是对于信息型产品，要解决的是一个独一无二的问题：导航设计（navigation design），这是专门用于呈现信息的一种界面形式。最后，信息设计（information design）是功能和信息两方面都必须要做的，它用于呈现有效的信息沟通。
其实都是为了传递信息，功能性更偏重于操作体验，以及操作的反馈和操作引导错误信息等。信息型产品要注重导航设计，这个设计的意思大概是页面呈现的一些信息入口，可以让你的信息流流向哪里，信息的层次如何进行转换。最后的信息设计，是两者都要考虑的，如何将信息有效的传递给用户。
如果这涉及提供给用户做某些事的能力，则属于“界面设计”。界面的意思是说，通过它，用户能真正接触到那些“在结构层的交互设计中”确定的“具体功能”。
界面设计，相当于让你用，而不是让你看。这里流程体验会更加重要。
如果是提供给用户去某个地方的能力，这是“导航设计”。信息架构把一个结构应用到我们设定好的“内容需求列表”之中；而导航设计则是一个用户能看到那个结构的镜头，这就表示，通过它，用户可以“在结构中自由穿行”。
信息型产品，更加注重导航设计。各个信息之间的联系，用户在各个页面之间跳跃的时候不会迷路，并且能够清晰的知道该怎么去。想要了解什么样信息应该通过哪些入口进入。
习惯和比喻
习惯和反射作用使我们与这个世界交互时的各种基础
好的用户体验就是尽可能的使用大量，细小的反射作用代替哪些庞大，注意力高度集中的任务。像老式的电话按钮布局是3 * 4 矩阵，你也可以观察到有很多其他的数字矩阵也都是使用相似的矩阵。是因为人们习惯了这种方式，即使这个标准可能不一定是真正的最佳解决方案。
这并不是说，每一个界面问题的解决办法都必须要毫无条件地死守这些习惯。当某种不同的方式有很明显的益处时，你反而应该试着谨慎地违背一些习惯。建立一个成功的用户体验，要求你在做每一个决定的时候都有充分的、明确的理由。
这里更重要的是，你的在产品的决策一定要非常的谨慎，这里的方式就是每个决策都要有充分的、明确的理由做支撑。
让你的界面与用户早已养成的那些习惯保持一致很重要，但是更重要的是，界面要与它自身保持一致。网站特性的概念模型有助于你保持内部一致性。如果有两个特性都使用了同样的概念模型，那么它们很可能就会有比较类似的界面要求。在这两个地方使用同样的操作习惯，能使熟悉了其中一个特性的用户很快适应另外一个。
这也就说明了为什么好的应用设计都是符合该系统的操作逻辑。在前几年很多软件在iOS和Android的界面设计的时候通常都是以iOS做为标准的，其实很重要的原因就是iOS的标准更严格，让用户习惯了其操作方式。很多系统级别的操作在应用中同样的适用。Android 因为开源的原因，限制比较宽松，所以导致了各种交互都在里面可以得到实现，不好的地方就是，整个应用生态的水平层次不齐非常混乱。用户在多个应用之间使用的时候体验不一致，导致落差感。