设计产品：框架和提炼

章节内容概述

本章讲诉了在有了功能需求和数据元素后如何将这些信息正确的归类整理并最终产品化的呈现在用户眼前，以及对于呈现给用户的“结果”又如何去测试与验证其是够符合用户的期待，是有效的、效率的、满意的、实用的。

章节内容结构

作者的观点与思考

关于框架设计

在我理解的信息架构很像超市里的商品成列，我们按照商品属性归类不同的类别，再按照商家的需求与顾客的购买频率划分超市的布局。最后按照既定的动线，吸引顾客购买不在计划中的商品。作者在文中仍然是简单的讲诉了步骤，而事实上真正的设计时，要复杂的多。好的信息架构是融合了商业目标与用户需求的导购员。在虚拟世界中，充当导购员的是“分类”。通过清晰的信息分类，将用户一步一步的带领到他们想要去的地方，同时提供适量的信息满足用户的好奇心，而非信息过量感到迷惑。那么我们应该如何做好分类？

常见的信息分类方法有2种

1，自顶而下，这样的信息架构旨在解决用户的“这类”问题，设计师通常努力的将用户的常见问题列出来，然后设计页面来满足这些需求，但是随着搜索的强大和普遍时，这类模式开始被另一种模式替换，自底向上

2，自底而上，是一种内容本身就可内嵌的信息架构。这种架构的关键在于，所有的信息来自于我们的业务范围驱动而产生的内容（功能，需求等）。而作者书中讲到的步骤，也是就是自底而上的方式。先把已有的所有内容，放在最低层级分类中，然后再将他们分别归属到较高一级的类别从而逐渐构建出能反应我们的产品目标和用户需求的结构

在《WBE信息架构》一书中，作者将信息架构的组件拆分为了以下4种，这4类是用户直接可见的组件。

1，组织系统，如何组织信息构建框架让用户了解产品所有信息之间的关系。常用的结构又分为

a,层级结构：是一层一层筛选的结构，将最大而广的分类至于顶部，更小的放在第二层，逐渐细化。但是在层级的广度与深度上，如何取舍成为重点。在设计时，我们应该更加保守的考虑深度，通常3层是一个可以接受的层级，超过3层用户就会觉得沮丧或者迷失；广度更多的是取决于页面的一般人的扫描能力和人类的认知局限。

b,顺序结构：通过组织信息为用户创建路径，通过每一步的操作而扩展呈现的信息。通常我们不能很好的处理预期之外以及不想要的信息。

2，标签系统，如何表示信息让一个名词来传递大量信息，帮助用户通过概念来查找内容。例如当我们再使用软件遇到了困难时，可能想到的是不同的信息,客服电话，帮助文档，在线客服等，而这些信息都可以在界面中的同一个标签找到“帮助中心”

3，导航系统，如何浏览信息而不会“迷路”。组织系统是用来修建房间的，那导航系统就是用来增减门窗的。导航可以用列表或者菜单呈现内容的类别。但是类别切忌不要太多，在面对导航分类过对时，筛选出绝对重要的分类，放弃不重要的分类。过多的选择只会让用户付出更多时间来思考如何选择。

4，搜索系统，如何搜索信息而对用户呈现“正确的”答案。搜索系统并不是所有软件都需要的，只有在软件包含了大量的数据时才会有效。

关于验证与测试

用户测试在产品的周期中会有不同的阶段

产品开发前，测试功能的交互流程进行验证看是否能形成闭环、对交互或视觉上不同设计方案的验证是否操作流程、命名与信息分类是否准确与符合预期；产品上线前，主要是检验产品的性能、功能方面是否达到标准；产品上线后，为下一次的迭代做准备，更加深入的了解用户群体对该产品的使用体验及意见反馈。

而为了避免后期各种状况不佳导致推倒产品重来的危险与修改成本巨大，产品开发前的用户测试尤其重要

产品开发前的用户可用性测试可以分为以下5个步骤

素材准备

此次测试所需要的设备，素材，文档等。尽量是逼真的素材

任务设置

从验证的问题出发，围绕测试目标创建用户情景与任务。一个完整的任务应该包含情景、正确的指令、停止条件，例如天是你的还款日期（情景），你打算把12月份借的500元在今天全部归还了（指令），请你成功将这部借款归还（停止条件）。

用户招募

通常招募人生在4-6人即可，如果要测试不同的用户人群可以每个人群5人左右，比如小白用户、普通用户、专家用户

正式测试

正式测试时观察用户的表情与肢体动作，保持和用户交流，但是切忌引导性的交流；当用户出现犹豫，疑惑或者失败时才进行简单的询问。若用户能够快速的坚定的说出原因，则该理由可行度较大，若用户迟疑或者难以描述只需记录问题点，不要再继续追问；对于用户提出的建议应该鼓励和肯定，用户出现问题时切忌不要让用户觉得是自己的问题，此时更应该鼓励，让用户放轻松。

测试报告

立即整理报告，可以按任务完成情况、任务完成时间、任务完成路径、用户自我报告四方面整理，最终将用户报告综合分析，排除问题优先级，综合梳理，得出解决方案