如何在制作信息图表时选择图标风格,而不需要对每一张幻灯片反复推敲?
在客户演示文稿的第八张左右幻灯片中,我曾经看到一个本应可靠的信息图表突然失去了可信度。数据本身没有问题,颜色也符合品牌指南。但其中三个图标有细线轮廓,两个是实心填充,还有一个——显然是在凌晨两点从免费图标包中拖拽进来的——有其他图标没有的阴影。房间里的人无法说出具体哪里不对,但他们只是不再信任旁边的图表了。
这就是图标风格的奇怪之处:它很少是幻灯片被赞扬的原因,但却经常是幻灯片被怀疑的原因。而大多数关于这个主题的建议仅停留在“选择一种风格并保持一致”上,这虽然正确,但也毫无用处,因为它没有告诉你在什么情况下选择哪种风格、用于哪种数据、在什么大小下。
**线条粗细才是关键,不是填充**
人们假设图标风格的可见差异在于平面与3D、实心与轮廓。但实际上,并非总是这些让不匹配的图标集暴露无遗。关键在于线条粗细。一个2px线条图标放在来自不同集合的1.5px线条图标旁边,观众还未能明确原因时,眼睛已经察觉出粗细不一的不协调——眼睛对粗细不一的反应速度比对风格不一的反应更快。
这就是混合图标包风险的真正原因:不是平面和3D“概念上冲突”,而是没有两个独立的图标库共享相同的线条粗细标准、圆角半径或网格大小。从五个不同的免费来源中选取五个“线条图标”,你会发现它们的线条宽度微妙不同,尽管每一个技术上都是线条图标。**解决方案不是“使用一种风格”,而是“使用一个来源”。**一个图标库、一次导出批次、一个网格——风格标签的重要性远不如共同的生产来源。
**将图标风格与数据类型匹配,而非仅看美观**
这里大多数指导意见变得模糊:它们将图标风格视为品牌决策,与旁边的图表或布局无关。但实际上,图标风格应与你构建的信息图表类型相匹配。
- **统计信息图表**(一个大数字旁边配有支持图标)适合使用更粗犷的实心图标——它们需要在半秒内被阅读,实心形状比细线轮廓在快速扫视时更经得起考验。
- **流程或步骤信息图表**通常用一致的线条图标更清晰,因为眼睛需要追踪一系列步骤,而每一步不应在视觉重量上相互竞争。
- **比较布局**(此与彼、之前与之后)是唯一能让双色或两色图标集物有所值的地方,因为第二种颜色可以直接编码比较内容,而非仅仅装饰。
在决定信息图表类型后再选择图标风格,而不是反过来。否则,你可能会强行将一个美观的图标集应用到它从未适合的布局上。
**无人提及的大小问题**
在全屏预览中看起来锐利的图标风格选择,一旦实际使用时往往会出问题——缩小到图例、仪表盘瓷砖或共享演示文稿的幻灯片缩略图中。特别是细线轮廓图标,在小于约20px时容易消失或模糊,而实心或双色图标则能保持形状。
这比听起来更重要,因为识别发生得比人们想象的更快。2014年麻省理工学院研究人员Mary Potter领导的一项研究报道显示,人类大脑可以在13毫秒内处理完整的图像(远快于之前研究者认为的100毫秒估计)。换句话说,观众几乎瞬间就识别出图标形状——这意味着在小尺寸下形状模糊的图标不会获得第二次理解机会;它要么被误读,要么被忽略。如果你的信息图表的任何部分最终会变小——印刷的简报、移动端查看、PDF导出——在完成演示文稿之前,在该尺寸下测试图标风格,而不是事后才发现问题。
**打破一致性规则的正确时机**
“保持一致”是几乎所有情况下正确的选择,这正是为什么要明确例外的原因。如果信息图表中的一个类别确实需要突出显示——一个风险标志、一个“新”的标签、一个在平静仪表盘中单独出现的警报图标——给该图标与其他不同的风格并不是错误,而是整个目的。当所有图标共享相同的粗细和填充时,你也失去了“这个不同”的信号能力,而这正是幻灯片需要传达的信息。
不过,我不会建议在一个信息图表中做超过一次这样的打破。一个明确的异常读作强调。两三个则开始读作不一致,观众无法区分哪些不一致是故意的,哪些是遗留的早期草稿中的图标。
**构建一个能真正完成的风格**
人们忽略的一点是:决定图标风格的限制往往不是美学,而是覆盖范围。一个精美的手绘图标集包含40个图标,但无法支持一个25类别的信息图表;在第三十类别时,你会发现缺少匹配的图标,要么混合来源(回到线条粗细问题),要么手动编辑本来不需要编辑的图标。在爱上一个风格之前,检查该来源库是否确实有足够多的图标,涵盖所有类别,以覆盖完整的数据集——而非仅仅是预览中的三个示例。
对于需要反复构建而非一次性完成的人来说,使用预先匹配的模板集(包含PowerPoint形状和图标资源)可以完全避免覆盖不足的问题,因为整个集合是一起生产的,而非从散乱的下载中组合而成。同样适用于图标风格的逻辑——根据数据的需求选择视觉效果,而非孤立时看起来最美的——也直接适用于选择图表类型以及选择适合行业视觉期望的模板,而非当前流行的模板。
下次信息图表感觉略显不可信,但又说不出为什么时,先检查图标,再检查数据。十次有九次,问题从来不是数据。
评论 (0)