深度长文｜如何输出一份让团队满意的交互设计交付物

对C端产品而言，这一步通常通过”创造动机、排除担忧、解决障碍“的三大关键因素分解法提炼需求。而对B端产品，取代动机和担忧的是履行工作职责的”刚需“，因此我在实际项目中多采用”信息需求“和”功能需求“的需求提炼方法。具体方法同样参见《B端产品的角色与场景分析：以会议申请功能的设计为例》。

同样的，表格也是我习惯采用的，在交互文档中展现需求提炼过程的一种比较清晰的形式。

3信息架构：关注竞品和真实用户

紧密围绕目标和需求进行方案设计的第一步，就是将目标和需求转化为全局性的信息架构和流程。

3.1 信息架构是什么

信息架构是对页面、信息和功能有组织的排列排序。合理的信息架构在符合逻辑的同时，也会尽可能贴近用户已有的使用习惯和思维方式，从而帮助用户快速判断和找到他们想要的功能。

对B端产品而言可以大大降低产品的学习成本，对C端产品而言则可以带给用户更好的体验、提高用户的留存率。

在着手进行信息架构设计之初，我们总要面对目标分析阶段得到的大量的页面、信息和功能名称。对这一年里经手的几个B端项目来说，大体都是十余个模块，每个模块中至少有3~5个不等的小功能，每个功能对企业中不同职能、不同身份地位的角色而言可能又会细分成若干个场景，这样分解得到的需求数量可能让我们看到就头大。

如果在目标分析阶段是按照场景通过“信息需求/功能需求”法进行分解的，那么页面和信息在页面中的归属我们应该是大概心里有数的，这种情况下信息架构设计的下手会稍微容易那么一点。

而如果是采用”创造动机、排除担忧、解决障碍“三大关键因素分解得到的需求，则会显得更加庞杂和无序。实际上，这也是我个人对小巧的C端应用建议使用第二种方法，而对本身就复杂度非常高的B端应用建议采用第一种更简化的方法进行分解的原因。

无论如何，海量的页面、信息、功能元素是我们总要面对的，这时常用的两种方法就是竞品分析和卡片分类法。

3.2 竞品分析

对大多数非首创性的C端应用而言，或成功的或失败的，或相似度高的或相似度低的，总是能搜到若干个和自己的项目类型类似的竞品。这时候，选取3~5个竞品，截一套完整的截屏、解析它们的信息架构，无论从共性还是差异上都能找到很多值得学习的地方。

这里的学习不只是借鉴，选择竞品时也不一定要只选择口碑最好的那几个，有时偶尔找一个失败的竞品，学习到的教训可能更能帮助我们减少犯错。

对信息架构而言，很多糟糕的竞品都在”尊重用户习惯“这点上犯了错，为了体现差别而强行做出差别来，只会让用户用得别扭，结果就是大量用户的流失。在做产品的版本迭代时，自家产品的历史版本也是竞品分析时不可缺少的样本。

举个例子：

下图是对京东的京豆和淘宝的淘金币两个竞品模块进行信息架构分析：

3.3 卡片分类

对B端产品而言，除了一些通用性高的企业办公、ERP、金融服务类产品可能相对容易找竞品，而对大多数企业应用来说，各行各业都具有较强的业务壁垒，业务类型千差万别，即使是相同的业务，不同企业的运作和管理模式不同，也可能导致产品需求差别非常大。

例如建筑设计院的项目工时和图纸归档系统、运营商的流量管理系统、通信行业的光缆巡检系统等等，从名字上大家应该就能大概明白为什么很难找到竞品了。

这时，同时适用于C端和B端产品信息架构分析的卡片分类法就是我们最好的伙伴。如果说竞品分析只是借鉴，卡片分析法则是基于真实被试对象心智模型的直接分析手段。

卡片分类法是指将页面、功能或信息元素的名称写在卡片上，让用户（没有条件的话找非本项目组的同事也可以）按自己的理解将卡片分成几组，并给每组起一个名字。

如果初次归类太小或者太小，可以让用户再进一步扩大或者缩小分组，最后对分类结果进行整理，得到初步的信息架构，同时也能帮我们发现一些页面或元素命名不合适的问题。卡片分类法应该是信息架构设计中最基础的方法之一了，在此不再展开赘述。

只想提的一点是：

在B端应用中要注意，卡片分类法要么分模块进行，要么应该把一级模块的名称事先指定给用户，否则面对多个模块的功能混在一起时，用户头疼，测试结果也通常质量很差、毫无参考价值。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!