如何设计一个合适的列表

如何设计一个合适的列表

编辑导语：在我们的日常生活和工作中，就会看到非常多的列表，最常见的也就是消息列表、联系人列表之类的，每个列表的功能和表达的信息都有所不同；本文作者分享了关于专门设计一个合适的列表，我们一起来了解一下。

我们平均每天会浏览多少个列表？

为了得到一个相对真实的数据，我对身边7个来自互联网、金融、建筑、医疗等不同行业的朋友进行了调研。根据抽样调查的结果显示，这个数值在180左右。且超过70%的人，每天浏览列表的数量数大于150个。

这是一个挺出乎意料的结果。这说明，虽然我们每天都在各种不同的产品中使用“列表”这种形式的构成，但是我们并没有真正意识到“列表”在产品中的重要作用。

所有的产品都和列表有关系：

根据前面的调查显示，这几个朋友日常浏览的产品，其品类有社交、资讯、工具、娱乐等，几乎涵盖了大部分的领域；而且我相信，随着样本数量的增加，这些品类只会越丰富、越完整。

比方说，我们日常使用的聊天软件，微信和QQ，它们里面就包含了不少列表，如：聊天室列表、联系人列表、朋友圈的朋友动态列表等；还有我们闲暇时刻杀时间用的资讯软件和视频软件，比如今日头条、抖音和快手，它们里面也有不少列表，如：文章列表、视频列表、创作者列表、音乐列表等。

这些列表的形态各异、结构纷呈、用途不一，但无一列外的是，它们都在不同场景下向用户呈现了丰富且有用的信息，同时还在用户和数据之间架起了沟通的桥梁。

列表是信息承载的自然选择：

在互联网世界里，最重要的当然是信息。从技术的角度来看，这些纷繁复杂的信息都储存在一张张看不见的数据表中；而最初的列表，正是由这些数据表演化而来；这就意味着，列表在数据存储方面，有着其他结构所不具有的技术优越性。

正是出于这一点，列表被大量的应用到了不同的信息展示和交互场景中，而且都很好的起到的信息承载的作用。

它们的普遍存在隐含了一个我们必须面对的问题，那就是我们如何为每一个不同的场景设计一个合适的列表？

接下来，我将带着大家一起探索列表的本质，并向大家展示一个合适的列表该有的样子；然后我会结合一个实战案例，分享列表的设计过程。

一、认识列表

列表的普遍程度远超我们的想象，已经达到了能够潜移默化地走进每一个产品的地步。有时候，我们在设计过程中应用“列表”来承载数据时，并没有去想太多，也不会去深究为什么要这么做，仿佛这一切都是天经地义。

原因也许是前面提到的，列表这一结构在技术上的优越性，那么这种结构又是由什么元素组成的呢？我认为有三种，分别是：数据、布局和操作。

如果不去看前端界面的表现，直接通过接口去获取列表的数据返回，我们会发现，这些“列表”是由多条结构类似的数据组成的，它们组成了一个有序排列的信息合集。

这个信息合集有三大特点。

最大的特点是数据结构的相似性。例如电商平台的订单列表，每一行数据中哪些是引用、哪些是数组、哪些是扩展字段等，这些大都是一样的。

第二个特点是数据排列的有序性。这里的顺序，代表的是数据展现给用户的先后次序，一般会按照时间、数量、类型等数据的典型特点来排序，便于用户的理解和使用。

最后一个特点是数据的充分必要性。换句话来说就是，接口返回的数据既要充分满足前端展示的需要，又要保证每个数据的存在都是合理的。这是非常容易理解，但有时候特别难做到的一点。

如果数据是积木块，那么它们之间的组织方式将决定积木整体的最终呈现结果。在零零散散的积木面前，我们产品人员就像一个堆积木的玩家，会努力把每一块积木放置到合适的位置上，最终实现既定的目标。

这个过程要注意两点。

第一，我们要保证信息结构的合理性，也就是分清信息的类别和层级。这里举一个场景，比如我们正在设计商品购买页，现在需要展示的一个商品是“书”。

在这之前，我们收集到与这个商品有关的信息有：书名、作者、作者的详情、书籍分类、价格；那么，按照信息的类别和层级，我们可以把这些信息组织成一张信息结构图，如下。

第二，我们要遵循人类视觉的规律；比如，人的视觉范围是有一定限度的，超过这个范围的区域是人的视觉盲区，我们不应该把重要的内容放到这里；又比如，人对文字感知的敏感程度远比对图形的低，所以一些需要突出重点的内容，可以应用图形的方案；再比如，不同的色彩能给人带来不同的情绪，红色是热情、蓝色是冷静、黑色是庄重等，这些都可以合理利用。

列表之所以能够如此受欢迎，当然不只是用于展示信息而已，它更重要的表现在于近乎完美的交互体态；无论是搜索、筛选还是排序，无论是单个操作、多个操作还是全选操作，列表的应对都游刃有余。

如果说对数据库的增删改查是一个程序员的浪漫，那么对列表的操作则是一个产品的艺术。这种艺术特质，可以反映在两个方面上。

一方面，操作要符合场景。这里的场景，更多的是交互场景；比方说你在搜索一个超市的时候，出来了一个商超的列表，这时候你看到表头里有“距离”这项；这时候大部分用户的想法，可能就是希望列表能够按照“距离”这个项来进行排序，那么我们理所应当把筛选的操作放到“距离”上面，而不是去其他地方放一个筛选项（比如列表的头部操作区域）。

另一方面，操作是必要的。在理论的角度来看，任何列表都可以增删改查。可一旦列表处于某些场景中时，我们就需要隐藏一些不合时宜的行为；比如买家看到商家的商品列表时，不能改删除商品。相反，如果列表处于另一些场景中时，我们可能要去丰富基础的操作；比如同样是买家查看商品列表，我们需要提供多维度的筛选和排序方式，以供用户快速找到合适的商品。

二、如何设计

列表的这三个元素是大部分场景下，一个合适的列表本该有的样子，但这并不意味着它们缺一不可。我们了解它的构成，不是为了可以照本宣科地去设计的，而是为了在既定的场景中搭配出合适的样子，需要具体情况具体分析。

这里有这么一个场景：在一个PC端的云文档产品中，用户储存有许多文档，其中不少开启了分享，以便与他人协作；分享的方式虽然很便利，但是也存在安全隐患，因此用户特别希望能有一个地方能够对这些分享出去的文档进行统一管理。

如果是你，你会怎么去设计这个“已分享文件”的管理列表呢？这里我给出我自己的答案。

1. 分析需要什么数据

首先，这是一个文件列表，那么对用户来说最基本的一个数据就是文件的基础信息，用于文件的识别，如文件名、文件图标。

其次，从需求背景来看，用户的核心诉求在于“找到想要的东西”并加以管理，而这个“东西”就是已分享出去的文件。那么这种文件有什么特征呢？

最明显的一点就是“已经开启分享”，也就是说产生了分享的行为数据，如分享链接、分享的对象（范围）、分享出去的权限、分享链接的有效期。

除此之外，用户肯定还会关心文件分享出去之后所产生的结果，比如文件通过分享链接的下载量和访问量。

2. 梳理信息优先级

整理好所需的数据之后，我们就可以开始定义数据的优先级，并根据信息对用户的重要程度来划分。

在当前案例中，用户的首要目的是“查找”，其次才是了解文件的分享信息和分享行为带来的结果详情；那么我们就能得出一个优先级：辅助查找和定位的信息 > 解释和详情类信息。

然后，我们要按照优先级归类信息。

过程就不赘述了，我直接上图：

经过了前面两步的分析，我们已经知道用户关心的内容是什么，也知道了哪些信息应该重点突出；那么在第三步中，我们要做的是如何把这些信息有机结合起来。

一般来说，我们会参考一些比较成型的范式，通过套用与调整，最终形成合适的列表。

这里我介绍三种比较通用的列表范式：

1）行列式

最大的特点是每个行列的交点形成独立的信息单元，也叫表格。

这种列表的优点在于结构清晰且具有稳定性、信息的定义清晰明了、没有业务倾向且可塑性强；缺点在于单行能容纳的信息不能太多，不然要么引起视觉疲劳，要么打破原有的结构稳定性；其次就是重点不突出，用户的视觉焦点比较零散。

2）无列式

没有严格意义上的列，每个单元自为整体，也叫信息流、feed流列表。

它的优点是自上而下的信息布局符合大多数用户的阅读习惯；其次每个信息单元的独立性强，因而信息单元内的信息布局比较自由，可根据业务形态进行拓展；不过它的缺点也很明显，就是信息的密度比较低，一屏内所能展示的信息单元不多。

3）无行式

没有严格意义上的行，每个单元自为整体，一般也叫瀑布流。这种列表在保留了信息流列表绝大多数优点的前提下，解决了信息单元密度低的问题。代价就是要求大屏幕，且缺乏结构的稳定性。

回到案例当中，如果我们把已有的信息往这三种范式中套用，那么就会发现行列式和无行式结构的列表都不是最佳的。为什么呢？

首先，在这些数据当中，优先级高的信息数量明显少于优先级低的信息，所以如果我们采用行列式结构，那么就会分散用户视觉焦点到优先级低的信息上，这是有悖于“查找”这一目标的；其次，用户的核心诉求是“找到想要的东西”，而查找和定位需要列表的结构具有稳定性，那么稳定性低的无行式结构也就不适用了。

因此，我们选择了在结构上更稳定、内容布局比较自由的无列式结构。

整体的框架定好了，那么每个信息单元的内容应该如何布局呢？这里我们主要是根据用户的视觉习惯来进行信息布置的。

在PC端，用户的视觉焦点一般分布在左上、中部和右下，尤其左上。那么优先级最高的信息，像图标和文件名，就应该被放在这个位置上；而次要优先级的信息，可以放在左下和右下，如分享信息和分享行为数据。

除了视觉焦点之外，我们还可以利用人对色彩和图形的敏感性来调整信息的表现形式；例如，我们会根据文档的不同类型去设计不同的图标，便于用户第一时间就能区分文件的类型；又比如，我们会采用不同的颜色来区分文字信息的重要程度，以便抓住用户的眼球。

4. 功能操作

如果说前面的三步我们都在研究用户想要“看”什么，那么在最后这一步中，我们要分析的是用户想要对列表“做”什么。

在本文的案例中，用户想要做的事情前面其实已经提到过，是“找到想要的东西”并加以管理，简单来说，就是查询和管理。

说到查询，不得不提“search全家桶”：搜索、筛选和排序。它们分别满足了三种不同的场景，搜索满足的是用户只模糊记得文件名的场景、筛选满足的是用户通过文件的特性减少列表结果的场景、排序满足的是用户根据自己关心的信息去改变列表信息展示优先级的场景，这三者的作用无一例外都是为了提高用户的查询效率。

至于说管理，每个不同的列表场景对应的管理需求大相径庭，无法一概而论。不过有一点是共通的，那就是管理行为本身是与列表的信息高度匹配的；例如，在已分享文件列表的场景中，用户能管理的内容其实是有限的，如分享的对象（范围）、分享出去的权限、分享链接的有效期等；从这个角度出发，那么用户需要的管理操作无非就是修改分享行为、结束分享行为等。

小事情中也有大学问，仔细回顾列表设计的整个过程，你会发现，这里面的方法论和设计观其实适用于很多地方。

在产品设计的领域里，没有大小贵贱之分，你倾注到产品里的每一份感情，用户都是能够感知到的；只是这个世界太复杂，节奏也越来越快，大家的视线都聚焦在那些高大上的东西身上，很多细微的存在渐渐被人们遗忘。

我不希望人人如此，愿你我成为细节里的巨人。

本文由 @凌丰 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。