UI 设计中，如何在卡片与列表之间选择

如果用户需要通过特征辨认项目，并探索各个项目的差异，可以选择卡片。如果他们需要快速查看一组固定属性、找到某个已知项目，或逐项处理工作，可以选择列表。如果任务要求在多条记录之间比较大量数值，表格或许才是更贴合需求的选择。

在 UI 设计中比较卡片与列表，可以从这个判断开始。但这并不意味着图片多的产品就一定要用卡片，业务应用就一定要用列表行。同一批内容可能服务于多种任务，哪种布局更合适，要看当前页面主要应该帮助用户完成哪一种任务。

例如，在一个网站项目库中，寻找视觉方向的设计师可能看一眼缩略图，就能认出合适的项目；查找逾期评审的项目经理，需要的却是负责人、评审状态和截止日期。两个人查看的是同一批数据，想回答的问题却不同。修改卡片的圆角大小，并不能解决这种任务差异。

先弄清楚用户在找什么

先确定用户要做什么，再选择组件。“浏览项目”这个说法留下了太多未明确的细节。把任务写成“找到一个视觉风格适合酒店业客户的项目”或“找到今天到期的评审”，你就能据此安排不同的信息优先级，也有了评价布局的具体依据。

对于第一种任务，一张能够辨认项目特征的预览图很有帮助。仅把标题放大，未必能让人看出项目采用了摄影、克制的字体设计，还是色彩鲜艳的插画。第二种任务则需要准确的日期和状态，并且这些信息应当出现在用户预期的位置。一个只起装饰作用的缩略图，可能占用了空间，却没有帮助用户作出判断。

写下用户最可能首先依赖什么线索：可能是一张图片、一个名称、一个类别、一位负责人，或一个日期。接着再确定，用户需要什么第二线索来确认自己找对了。这些信息应当在不打开项目的情况下就能看到。如果用户必须逐个打开所有候选项目，才能认出它们是什么，那么集合视图承担的工作就还不够。

Nielsen Norman Group 在讨论卡片时，区分了卡片将不同类型内容组织到一起的能力，以及列表提供稳定浏览路径的能力。文章也指出，卡片占据的空间更多，还可能让项目的排序关系不够明显。应把这些观察作为需要检验的取舍，而不是据此认定某一种形式在所有情境下都更好。Nielsen Norman Group 的 UI 卡片分析。

Pinterest 与眼动案例揭示了不同的使用代价

NN/G 的卡片文章记录了一版 Pinterest 界面：图片、标题和辅助信息被组织在高度各异的容器中。对于主要依靠图片辨认、且每个项目内容量不同的集合，这样的处理是合适的。下方截图展示的是当时的历史界面。

同一篇文章还记录了一次眼动测试，参与者需要在卡片布局中寻找自己感兴趣的报道。注视轨迹显示，他的视线在候选报道之间反复移动。NN/G 将这一行为与两项布局特征联系起来：缺少明显的先后排序，以及可比较的信息没有出现在一致的位置。

这两个案例揭示了两种不同的任务。如果用户在挑选一张感觉合适的图片，探索本身就是任务的一部分。如果工作人员在查找最近逾期的记录，那么反复在每张卡片中寻找日期，就是额外的负担。把两种活动都称为“浏览”，会掩盖真正应该决定布局的任务差别。

在比较视觉风格之前，先检验信息是否有用。把方案中网格里的缩略图遮住：如果主要任务因此无法完成，那么图片很可能确实提供了必要的判断依据；如果遮住图片以后，日期和状态更容易被注意到，任务反而更好完成，那么图片可能正在分散用户处理工作的注意力。

确定用户在打开项目之前必须看到什么

比较两个方案时，使用相同的记录、相同的筛选条件，以及相同的可用操作。请一位用户查找逾期项目，请另一位用户辨认视觉方向，并交替安排先展示哪种布局。记录他们有没有选错、是否不必要地进入了详情页，以及返回集合后是否找不到原来的位置。用户偏爱更漂亮的页面，可以作为外观反馈，但不能据此回答哪种布局更能支持任务。

先查看内容，再决定用什么容器展示

先取一小批真实记录，其中也要包括不容易安排的内容。对于这个项目库，可以选入短标题、长标题、缺少缩略图、已归档和没有负责人的项目。相比一整屏一模一样的占位矩形，这些实际内容更能帮助你判断适合采用什么布局。

如果集合中各项内容差异很大，卡片可能更有优势，因为每个项目都能形成相对完整的摘要。如果每个项目都重复相同字段，就更有理由考虑列表。这两种观察都不足以单独决定最终方案，但能让你知道设计必须容纳哪些内容情况。

尤其要留意缺少媒体素材的记录。如果大多数记录都没有有意义的图片，卡片网格常常就会变成重复占位图的陈列。布局让人以为可以靠视觉辨认，实际内容却要求用户查找文字。与其刻意制造装饰性的差异，不如考虑以文字为主的列表，或仅在有需要时显示较小的缩略图。

反过来，如果列表把视觉作品集简化成一串文件名，也可能删去了用户必需的信息。“Project 14”和“Project 15”即使是准确的名称，也不一定能帮助人辨认项目。在这种情况下，加入有用的预览图，可能比让屏幕容纳更多行更重要。

一个例子：同一项目库，两种起始视图

设想项目库里有六个虚构项目：Cedar Lodge、Harbor Rooms、Studio North、Maple Clinic、Archive House 和 Lumen Shop。每条记录都有缩略图、负责人、评审状态和评审截止日期。展示方式改变时，这些字段本身并不会改变。

如果主要任务是探索视觉方向，就突出展示缩略图，把项目名称紧接着放在下方，再补充一个简短类别和不过分抢眼的状态标签。如果显示负责人能帮助用户决定联系谁，也可以保留，只是降低视觉强调程度。不要因为数据里有这些信息，就把项目的所有元数据都塞进卡片。

如果主要任务是管理评审，可以从紧凑的列表行开始设计。把项目名称放在开头，必要时配一个小缩略图，再把状态和评审截止日期放在一致的位置。也可以直接展示“打开评审”之类的具体操作。在这种情境中，用来修饰视觉风格的描述文字就没有那么有用。

这两种视图不必显示完全相同的字段，但对同一个底层对象的描述必须一致。如果一种视图把状态叫作“待评审”，另一种却叫作“待处理”，用户可能会怀疑，切换视图是否改变了项目状态。

初始视图应当符合页面的主要用途。发现内容的页面可以默认显示卡片，评审队列可以默认显示列表行。即使提供了视图切换，也仍然需要选择合理的默认形式，因为许多人会直接沿用最先看到的那一种。

让每种视图支持自己的任务

卡片：建立清楚的内部顺序

卡片也需要清楚的阅读顺序。先确定哪个元素用来辨认项目，哪个用来解释内容，哪个用来发起操作。如果缩略图、标题、徽章、作者、标签列表和按钮都同样抢眼，卡片就会变成一个微型仪表盘，无法再充当有用的摘要。

在项目库的视觉探索视图中，缩略图和标题应当让用户认出项目，类别帮助用户理解内容，状态和负责人则是辅助信息。通过尺寸、字重、元素之间的距离，以及适度收敛的视觉处理，就能表达这样的顺序，不必为每个字段分别安排一种颜色。

需要彼此比较的信息，也应当放在可以彼此对应的位置。即使卡片主要用于浏览，用户仍可能在几个候选项目之间核对同一项细节。因此，应把状态放在相同区域，并采用一致的标签格式。与其让重要元数据的位置不可预期地变化，稍微缩短描述通常是更好的取舍。

图片应当值得它占用的空间。一张小到看不清布局的截图，未必比没有图片更有用。可以围绕最能帮助辨认的特征裁切，在合适的情况下保持一致的宽高比。避免把各种随意裁切的图片混放在一起，让整个网格比项目本身还显得杂乱。

设计也应当明确支持“没有图片”这种状态。使用不抢眼的替代处理，通过标题和类别让用户仍能认出项目。不要把替代图做得过于醒目，反而让没有图片的记录成为整个集合中最显眼的项目。

卡片需要让人看出边界，但未必每一张都要加上粗重描边和深阴影。边界的目的是让人知道哪些信息属于同一个项目。在增加装饰之前，先尝试用间距和轻量的底色处理建立这种联系。评审时要看整个集合，因为一种处理在单张卡片上很好看，重复二十次以后却可能显得累赘。

列表：保留可靠的扫描路径

如果每一行的结构都不同，列表的优势很容易就会消失。把用于辨认项目的内容放在固定位置，并明确辅助字段的排列顺序。用户向下浏览集合时，不应该每看一行，就重新摸索一次它的结构。

在评审队列中，先放项目名称，再把评审状态和截止日期安排在容易反复找到的位置。如果列表按截止日期排序，就让用户看得到这个日期。按隐藏字段排序，只会让读者不断寻找一个根本看不见的规律。

信息密度关乎阅读与操作，不是看谁能在一屏里塞进最多记录。每行都要留出足够空间，让不同名称仍然能被区分，控件也能方便使用。如果提高密度后，负责人和状态挤成了一条灰色文字带，那么即使多显示了几条记录，也未必真的有帮助。

有目的地安排第二行信息。它可以放简短描述，也可以放工作区名称等能区分项目的信息，但不要换一种说法重复标题。例如，在“Cedar Lodge 网站”下再写“为 Cedar Lodge 制作的网站项目”，只是增加了文字长度，对辨认项目几乎没有帮助。

列表也可以包含图片。一张小而有意义的缩略图，可以在保留稳定行结构的同时帮助用户辨认记录。真正要判断的是，图片是否需要成为整个项目的视觉主体，而不是列表究竟能不能放图片。

如果一行中不断加入多个对齐的字段，而用户也确实需要主动比较这些字段，就要考虑自己是否已经在设计一张表格。这并不是设计失败。表格能通过明确的表头说明各项关系，也能更直接地支持比较。即使把它叫作列表，各列之间的关系也不会因此消失。

扩大点击区域之前，先说明点击会发生什么

一张卡片可能既能打开项目，又能展开菜单、加入收藏，还带有类别链接。每增加一个操作，卡片上的交互就更复杂一点。设计师需要说明，用户点击图片、标题、空白区域或辅助控件时，分别会发生什么。

先确定一个清楚的主要去向。如果点击标题会打开项目，而点击缩略图会进入图片查看器，这种差别就必须有合理原因，也要有用户能理解的操作提示。否则，两个视觉上关联的元素，行为却像互不相关的链接。列表行也可能出现同样的问题，例如名称和行背景分别跳转到不同页面。

W3C 设计系统既记录了包含独立链接的卡片，也记录了整张表面作为链接的卡片，并提醒卡片标题的层级必须适合所在页面。这说明，卡片的视觉形式并不对应唯一、必须遵循的交互模型。W3C 的卡片组件模式。

对于这里的项目库，可以先采用带链接的标题，加上一个独立菜单，这种方式容易理解。如果实现时扩大了主要操作的点击区域，就要确认菜单仍能独立使用，用户在需要时也仍能选中文字。不要嵌套链接，也不要把每一小段文字都变成单独的键盘焦点停靠点。

选中项目和打开项目是两种操作。 当用户需要选择多个项目后统一操作时，应当能看到明确的选中状态，也知道如何退出选择。如果没有明确切换操作模式，就不要让用户在一种视图中第一次点击是选中，在另一种视图中却是打开。切换视图应当改变展示方式，而不应悄悄改变基本操作的含义。

在说明鼠标或触控行为时，也把键盘操作的预期写下来：焦点应当移到哪里，哪个元素负责打开项目，怎样才能到达辅助菜单？截图回答不了这些问题，所以交互评审也应当覆盖它们，不能因为视觉层级清楚，就假定控件结构也一定清楚。

两种视图都确有价值，才提供切换

只有当同一批用户确实会在“辨认项目”和“快速查看固定信息”之间切换时，卡片与列表的切换控件才有价值。如果其中一种视图只是另一种效果更差的版本，增加它带来的帮助就很有限。同时支持两种视图，也意味着需要照顾的内容状态和交互细节增加了一倍。

如果提供切换，请保留筛选条件、排序方式和当前结果集合。 用户已经把项目库筛选为等待评审的项目后，不应该一切换到列表，就重新看到所有项目。切换改变的是结果如何呈现，而不是哪些结果符合当前条件。

在有意义的情况下，保留用户已选中的项目；如果存在限制，应当明确说明。例如，只有列表视图支持批量操作时，应当解释这一点，而不是不作提示就清除用户的选择。更好的做法是进一步考虑，是否能让同一操作在两种展示方式中保持一致。

切换控件应当带有标签，并清楚显示当前启用的视图。网格和列表行图标可能有帮助，但仅凭图形不能解释所有布局。“卡片”或“列表”这样的简短文字能让选择更清楚，尤其是在窄屏上，两种布局外观相近的时候。

还要考虑再次访问的用户。在实际产品中记住视图偏好可能有用，但不应因此覆盖任务已经改变的情境。评审队列和公开的灵感图库，未必需要共享同一个全局偏好。明确偏好的保存范围，避免让“记住设置”变成出乎用户意料的行为。

在窄屏上也要保留完成任务所需的信息

网格在手机上常常会变成单列，但这并不会自动使它成为好用的列表。卡片里的图片可能仍占据大部分屏幕，而完成任务所需的字段却被推到很远的下方。布局改变以后，应当重新检查信息层级。

在视觉探索视图中，较大的预览图可能仍然合适；在评审队列中，一段紧凑、日期清楚可读的摘要可能更有用。不要仅仅因为某个关键字段在桌面布局里位于最右侧的一列，就在窄屏上把它隐藏。

让辅助字段按明确的顺序换行，或移到第二行。不要只为节省空间，就把状态缩成一个没有说明的彩色圆点。如果必须把某个字段折叠起来，要判断用户是否仍能在不逐项打开记录的情况下完成主要任务。

长名称特别容易暴露问题。用两个接近真实情况的项目名称测试：开头几个词相同，直到末尾才有区别。如果截断后两者显示成相同文字，窄屏布局就已经无法让用户区分记录。在缩小字号之前，先尝试调整换行、可用宽度，或用于辨认项目的可见字段。

操作区域也要单独检查。在宽列表行中容易点击的菜单按钮，到了窄屏上可能紧挨着标题或复选框，显得拥挤。卡片中如果有三个小控件，宽度变小时尤其容易难用。只要能让任务更简单，可以把非必要操作移出直接展示的区域，同时保留清楚的访问入口。

用实际查找任务比较列表和网格

不要只问评审者更喜欢哪种布局，而应给他们一个有可观察答案的任务。在这个项目库中，视觉探索任务可以是找到一个风格克制、适合酒店业的项目；查找已知项目的任务可以是找到 Archive House；管理类任务可以是找出分配给某位负责人、日期最早的一项评审。

两种布局要使用等价的内容。 如果其中一种有更好的缩略图、更短的文案，或更有用的筛选，那么比较的就不只有布局。这些改进本身也许值得做，但不能把它们误当作卡片或列表天生更好的证据。

观察用户在哪些地方犹豫。为了查看没有展示的状态而反复打开项目，说明可能存在内容问题；从详情页返回后找不到原来的位置，说明可能存在导航问题；直接跳过网格第二行，则可能与视觉顺序有关。不同观察指向的修改并不相同。

也要安排一个能挑战你所偏爱方案的任务。如果你偏爱卡片，就测试反复查找相同字段；如果你偏爱列表，就测试能否通过视觉在相似名称中认出项目。测试是为了暴露这一选择带来的代价，从而判断能否接受，而不是收集对第一张设计稿的赞同。

你可以在 OpenDesign 中构建并评审不同的 HTML 布局，用视口预设查看它们在不同尺寸下的视觉表现，也可以给具体卡片或列表行添加评论。把记录和要求保留在设计上下文中，让后续修订有稳定依据。搜索、已保存的视图偏好，以及切换后是否继续保留选择，则需要在实际实现的流程中测试。