卡片设计从凭感觉到有办法:原型阶段的信息架构与视觉规范
作为一个常年和原型图打交道的产品经理我越来越觉得卡片设计是整个页面设计里最容易被低估的环节。大家评审时讨论最多的往往是功能逻辑和业务流程可真到方案落到高保真一张卡片怎么摆、放哪些字段、圆角取多少、阴影压多重经常变成谁都能说两句、谁都没把握的拉锯战。卡片设计说小也小一块“巴掌大”的区域说大也大几乎所有主流产品页面都能拆成一组卡片的集合。如果你正准备把原型做得更专业或者正为一张卡片的排版挠头这篇文章我会把卡片设计从“凭感觉”变成“有办法”先聊它到底承载了什么再讲信息骨架怎么做然后是视觉参数和不同场景的变体最后是原型实现和那些真实踩过的坑。1. 为什么说卡片设计是原型阶段最该花时间的组件1.1 一次评审会上被问倒的经历我记得有一次给新版本做评审方案里放了一张任务卡片我当时觉得不就是“标题、状态、日期、负责人、一个按钮”嘛五分钟能画完的东西。结果进入评审没两分钟开发同事就抛了一串问题上来这张卡片的点击区域是整个卡片还是只有按钮标题最长支持几个字超出怎么处理状态从“未开始”变成“处理中”时整张卡片需要换背景色吗图片加载失败显示什么缩略图比例是固定还是自适应这些问题单个拿出来都不难但我当时并没有系统组织过答案答得有点狼狈。会后我把问题理成一份清单才发现“一张卡片”背后有信息层级、有交互边界、有状态变化、有异常容错任何一个点做得含糊到前端实现就变成一次“设计补充说明”甚至返工。从那次之后我把卡片当成页面设计里的基本单元来对待所有页面的评审前置条件都有一条页面里的每一种卡片先自检信息、状态和热区是否完整。1.2 卡片制界面的信息承载逻辑卡片之所以无处不在背后有个很朴素的原因人在读屏幕时并不是逐字扫描而是先看“块”。卡片相当于给一组关联信息画了一个视觉边界用户只需要对这个边界内的整体做一次判断——这是什么、能不能点、点了之后去哪。这就是认知心理学里说的分组效应当信息被组织成有限数量的组块时记忆和处理负担会明显下降。反过来理解为什么有些页面用卡片做了分组看起来反而更累因为卡片设计不只是画一个圆角矩形它内部的信息如果互相打架外部边界又不清楚用户看到的就不再是整齐的信息块而是一堆漂浮的碎片。原型的价值恰恰在这里在真实数据填充之前用结构化手段验证“这些字段能不能组成一个让用户秒懂的块”。所以产品经理在原型阶段关注卡片本质上是在关注信息组织方式。1.3 谁需要关注卡片设计关注到什么程度团队里每个角色对卡片的介入深度不一样但都不建议完全甩手产品经理管信息和交互边界要能确定字段、排序、行动点、点击热区。交互设计师补全状态、异常态、响应式规则让卡片在动态环境下稳定。视觉设计师定风格参数维护组件规范让卡片和整体语言一致。前端开发把上述所有约束转成真实布局和逻辑并在还原走查时逐项核对。产品经理不必成为视觉专家但必须掌握一个判断力这张卡片要装什么不能装什么。很多时候卡片越画越乱不是因为视觉不好看而是产品经理自己没想清楚信息优先级。这个能力可以在原型阶段直接训练没有额外成本。2. 动手画卡片之前先做信息架构的“填空题”2.1 一张卡片替用户回答哪三个问题我画卡片前习惯先列三个问题让卡片逐一回答第一个问题这是什么要能让用户一眼识别当前对象的身份通常由一个明确的标题或主图承担。第二个问题和我有什么关系这是决策依据展示状态、时间、进度、收益、风险等上下文信息。第三个问题我能做什么提供一个清晰的行动出口按钮、整卡点击入口或更多操作菜单。拿任务卡片举例“任务名称”负责回答第一个问题“截止时间”“优先级”“当前状态”回答第二个问题“开始处理”“查看详情”这类按钮回答第三个问题。如果一张卡把这三种角色混在一起比如把“截止时间”做得和任务名一样大用户决策路径就会被打断视线不知道该先停在哪里。2.2 信息优先级排序主信息、次信息、可忽略信息接下来把候选字段全部罗列出来不要想着删先摆出来。然后标三个属性用户关心的频率、对决策的影响程度、业务方坚持放的理由。用一张表格就能梳理开比如某个任务卡片字段用户关心频率决策权重建议任务名称每次高必留控制一到两行截止时间每次高保留弱化修饰优先级偶尔中高用标签或色点表达负责人头像偶尔中辅助识别尽量精简创建人极少低默认收起按需展开做完这张表你会发现业务方想放的不少字段都落在“极少关心”和“低决策权重”里。这时候我会守着一条原则任何字段放上卡片不能影响识别不能帮用户做判断那它就是噪音应该收进二级详情页。减法比加法难但原型阶段做减法的成本最低。2.3 从业务目标推导卡片的“行为按钮”卡片上放几个按钮、按钮放多响不是拍脑袋定的应该从业务目标倒推。如果业务目标是“让更多用户进入详情页”那整张卡片适合做成一个大热区按钮只是辅助。如果业务目标是“让用户把内容加入稍后读”那加入按钮必须足够显眼同时要注意整卡点击不能误触按钮。反面场景我也见过不少一张卡片上堆了“删除”“收藏”“分享”“不感兴趣”四个平级按钮用户根本分不清主次操作效率反而更低。稳妥的做法是只保留一个主行动按钮把次要操作收纳进“更多”菜单。卡片越小操作按钮越要克制这是移动端交互的常识但在原型阶段特别容易被忽略。2.4 先画“文本骨架”再画视觉稿很多产品经理习惯直接从高保真入手一边调颜色一边想字段排序结果被视觉细节带跑评审时争论的尽是“这个绿是不是太亮了”。我推荐一个办法先用纯灰框和真实占位文本画一个“文本骨架”只表达卡片内部的信息顺序和层级关系完全不涉及颜色、阴影、圆角。文本骨架的作用是逼着所有人先把阅读顺序聊清楚。比如任务卡片的骨架从左上角开始依次是任务名、截止时间、状态标签、操作按钮这是符合人眼从左到右的扫读习惯的。画完骨架可以出两三版排序方案找几个同事做十秒钟测试问他们第一眼看到了什么、能不能想清楚下一步。一旦信息顺序定了后面的视觉设计只是在为这个顺序服务而不是重新发明顺序。3. 卡片视觉参数的决策过程尺寸、圆角、阴影与间距3.1 卡片的宽度体系栅格、边距与安全区卡片不是孤立存在的它活在页面栅格系统里。移动端最常见的是12列栅格屏幕左右边距通常取16px卡片与卡片之间的间距取12px或16px这样会形成稳定的纵向节奏。桌面端则用栅格列来控制卡片宽度内容区越宽卡片重复次数越多单张卡片的最小宽度就必须被约束否则会出现一排卡片里有的宽有的窄、看起来杂乱的情况。以下是一组我常用的基础参考值平台屏幕左右边距卡片间距卡片内边距移动端16px12px16px平板24px16px20px桌面端24px以上16px24px这套值的好处是全部落在8的倍数上和主流设计工具的8点网格体系对齐开发还原时也好换算。如果产品对信息密度有特殊要求可以把间距整体缩一档或扩一档但全站要保持同一种节奏。3.2 圆角的情绪表达圆角是卡片中最容易被当成“随便调一下”的参数实际上它对产品气质影响非常大。圆角越小界面越偏工具感、专业感圆角越大界面越偏亲和、年轻。粗略经验是0到4px的圆角适合金融、数据后台需要稳重和效率8到12px是内容型产品的安全区通吃多数资讯、工具场景16px以上常见于社区、娱乐产品显得轻松活泼。注意一条硬原则圆角值必须在全站统一成体系不能同一页面里既有4px的小圆角又有20px的大圆角。卡片风格一旦混用界面就会像多个产品拼在一起。选哪种圆角先看产品本身的性格定义再看竞品的普遍做法最后落到组件库里统一维护。3.3 阴影与描边层级分离的两种路径卡片与背景的分离主要靠两种手段阴影和描边。阴影适合卡片悬浮于背景之上的场景能营造空间层次描边更适合卡片与背景色接近、又不想增加阴影负担的场景。原则上不要同时给卡片加又深又大的阴影再叠一层粗描边否则卡片边界会显得厚重笨拙。移动端卡片阴影我可以给一组起点参数横向位移0px纵向位移4px模糊半径12到16px阴影颜色用黑色透明度20%到30%。这类阴影视觉上柔和不会产生强烈悬浮感。扁平化风格的产品则建议用1px浅描边颜色可以用黑色透明度8%干净利落。原型阶段就应把阴影参数写清楚而不是让开发自己去猜应该用多重的阴影。3.4 卡片间距与亲密性法则间距是一种语法它告诉用户哪些信息属于同一个组。核心法则是卡片内部间距要大于卡片之间的间距否则分组关系会被打破。假设卡片内边距是16px卡片与卡片间距只有4px那用户看到的就是一大块连续文字而不是一张张分开的卡片。实际操作里我习惯按三级间距来处理同一卡片内同组字段之间用8px卡片内不同信息块之间用16px卡片与相邻卡片之间用12到16px。只要距离层级保持一致用户扫一眼就能分清边界。这条法则放在原型阶段验证成本极低拖动几根辅助线就能排除大量后期视觉返工。3.5 一套可以抄走的卡片规范参数表下面这套参数不是标准答案但它是内容型产品一个稳妥的起点可以照抄到原型里再根据产品气质调整参数推荐起点值卡片宽度容器宽度自适应屏幕横向边距16px卡片间距12px卡片内边距16px圆角12px阴影Y:4px, Blur:16px, 黑色20%标题字号16px加粗正文描述14px常规辅助信息12px操作按钮高度32到36px热区不小于40px把这些参数写进原型的设计说明里团队评审会少很多无意义的争论。参数不是死的但总得有一个统一基线后续再根据真实数据和用户反馈去调。4. 四种高频业务场景下的卡片形态变体4.1 资讯/内容流卡片内容流卡片最常见的字段是封面图、标题、摘要、来源、发布时间、互动数据。设计重点在于主图比例全列表统一比如统一为16:9或者4:3避免不同内容因为图片比例不一致造成高度跳动。标题是整张卡里唯一必须显著的信息建议限制在两行以内超出用省略号摘要最多保留一到两行。来源、发布时间这类信息适合弱化处理放在标题下方用辅助字号排列。互动数据点赞、评论数放不放、放多少取决于产品是把内容消费放在第一位还是把社区互动放在第一位。如果以阅读为优先互动数据建议收进详情页如果以社区活跃为优先就保留在卡片底部。4.2 电商商品卡片电商商品卡的字段优先级非常稳定价格最显眼其次是商品名称商品图负责建立直观认知评价和销量是辅助佐证加购或收藏按钮作为行动点。价格必须用大号字加粗单位符号缩小让用户第一眼就感知代价商品名称限制两行常用省略号截断促销标签控制在两个以内否则卡片会变得像贴满广告的电线杆。商品卡还要特别注意动态状态价格变动、售罄、缺货、下架每个状态都要有对应的视觉表达。很多原型只画了一个“有货且价格正常”的状态等运营配置出奇奇怪怪的促销组合时已经晚了卡片被撑到变形是常见事故。4.3 用户/联系人卡片用户卡通常包含头像、昵称、身份标识、个人简介和操作按钮。头像尺寸全站统一个人资料页可以大一些列表里以40到64px居多形状保持一致要么全圆角要么全方形。昵称是第二重要的信息字体加粗旁边可以挂一个认证标识或等级图标但标识不要超过一个多了就是贴纸大战。简介只留一行用省略号截断。关注、加好友这类操作按钮要么独立放在卡片右侧要么出现在头像上方形成联动无论哪种点击热区都要做足。原型里常见错误是把整张用户卡设置为可以点击进入个人主页同时又希望用户点按钮完成关注结果两层热区重叠用户经常误触这类冲突需要在设计稿里明确画出来。4.4 数据统计卡片数据卡片的明星永远是数字。主数字要大、要粗建议用28到40px的中粗字体标题、单位、趋势变化箭头、环比说明这些信息全部是配角字号控制在12到14px。一张统计卡片只表达一个数据主题不要在上面堆柱状图、折线图、进度环再加三个指标否则核心指标会被淹没。数据卡片还必须设计空状态、加载状态和异常状态。原型阶段最容易被忽略的就是空状态很多产品经理画了一个漂漂亮亮的满数据卡结果接口没数据时页面成了白板。数据卡要提前定义“暂无数据”时的展示文案和占位图形这是稳定体验的底线。5. 原型工具里的卡片实现技巧与交付标注规范5.1 用组件和变体维护卡片库原型画到两三个页面以上就不建议一张张复制卡片了效率低且容易不一致。在Figma这类工具里我会把卡片建成一个主组件容器使用Auto Layout内部放好标题、描述、操作按钮等占位元素再通过变体定义不同尺寸和状态。比如同一个任务卡片可以有“默认”“悬停”“选中”“禁用”四种变体也可以有“带头像”“不带头像”两种结构变体。组件化初期会多花半小时但它带来的收益是指数级的改圆角、换阴影、调字号只需要在主组件上改一次所有实例同步更新。原型迭代越往后这个优势越明显。建议产品经理就算没有设计师配合也要学会用这个方式来维护自己画的原型。5.2 状态设计默认、悬停、点击、选中、禁用原型阶段状态不完整几乎是评审必踩的雷。一张卡片至少要覆盖以下几类状态默认态、悬停态桌面端尤其需要、点击或按压态、选中态、禁用或不可用态、加载中状态、空数据状态和图片加载失败状态。这里面前五种是交互状态后三种是数据状态。在原型工具里状态切换可以用交互变体或动态面板实现。演示时一边切换状态一边讲解逻辑能让评审成员直观看到设计边界。如果原型里实在来不及做全部状态至少把状态清单附在交付说明里告诉开发“这些状态还没在图里体现但交互规则已经定义好了”避免开发上线后自行发挥。5.3 交付开发时的标注规范与注释写法卡片交付开发最容易产生歧义的就是细节参数。我建议交付物里至少包含这些标注卡片尺寸与内边距、圆角值、阴影参数、字体字号与行高、文字颜色、图片比例、标题最大行数和省略规则、点击热区范围。注释也要写成可以让开发直接落地的句子。不要只写“标题不要太长”而要写清楚“标题最多两行超出以省略号截断”“当图片加载失败时显示灰色占位图和默认图标”。每一条注释都是在减少一个不确定项。团队里还可以约定一张卡片验收checklist评审结束时逐项打勾确认热区、状态、异常态都已定义。5.4 响应式卡片不同屏幕尺寸下的适配策略响应式原则说来也简单卡片内部的信息结构尽量不变变化的是外部容器宽度和每行卡片的数量。手机上通常单列展示平板上两列桌面端三列或更多。原型阶段至少要交付手机和桌面两套布局并说明列表在列数变化时卡片宽度是等分容器还是固定最大宽度图片是否按比例裁切。很多产品经理说响应式是前端的事这没错但产品侧必须定义清楚边界。比如“窄屏时图片比例不变高度自动裁切”“卡片最小宽度360px小于这个宽度改单列”。这些规则不写出来开发只能用一套默认逻辑跑结果总有几个尺寸的屏幕看起来不对劲。6. 一张卡片引发的“事故”点击热区问题的完整排查链路6.1 现象用户反馈“卡片点不中”有一次做一个任务管理工具列表页是典型的任务卡片每张卡展示任务名、优先级、截止时间和一个“处理任务”按钮。上线一段时间后后台数据反映从卡片进入详情页的转化率明显低于预期用户反馈里也频繁出现“点了没反应”“我想点那一整块结果只有按钮能点”“看起来整张都能点为什么文字部分点了没反应”。这类反馈在数据分析里会表现为点击率不低但转化率很低说明用户点了很多次才成功或者干脆放弃。当时的直觉判断是视觉和交互出了问题但具体在哪里需要一步步查。6.2 还原先看用户到底点了哪里排查第一步不是改代码而是还原用户操作路径。我们调取了一段时间内的点击热力图和操作录屏回放发现用户大量点击集中在卡片的空白区域、标题文字周边和卡片边缘而这些位置的点击基本没有产生后续页面跳转。也就是说用户是真的把这些区域当成可点击区域了我们设计上给了“整卡可点”的暗示但实现时没有把热区铺满。这一步的价值在于排除误报不是用户不知道卡片能点而是视觉暗示和实际可点范围不一致造成了挫败感。6.3 对照设计稿与实现逻辑的差异接着把设计稿和前端代码对照着过了一遍。设计稿里确实把整张卡片背景设成了跳转热区但这份设计稿只画了视觉效果没有单独的透明热区图层也没有在标注里说明热区边界。前端从设计稿里能看到的可点击元素只有“处理任务”按钮和标题链接于是很自然地只给这两个位置绑定了事件。问题还叠加了移动端点击精度问题文字和卡片空白区域没有足够大的点击目标手指点起来很不舒服。移动端普遍接受的推荐热区尺寸是44x44pt左右卡片上大段文字显然不满足这个要求。6.4 根因交互约定缺失根因不在开发而在于产品设计侧没有把热区作为交付内容。我们口头说了“整卡可点”但图纸上并没有画出来开发只能按可见元素推断。这不是谁不认真而是协作流程里缺少一个明确的交付物叫做“热区示意图”。热区要约定四个要素可点击的边界范围、边界内的不同操作分区、最小点击尺寸、悬停或按压的视觉反馈。这些要素缺一不可且必须在设计稿或交互说明里能直接看到。6.5 修复改规范并补清单修复分三步进行。第一步把卡片热区规则写成文字规范整卡点击进入详情按钮是独立热区热区最小尺寸不小于40px。第二步在卡片组件里增加一个透明热区层覆盖整张卡片按钮层放在热区层之上这样点卡片任意位置都能进详情点按钮触发对应操作。第三步把热区审查加进原型走查清单和状态审查并列每次评审前逐项过一遍。这里有一个容易被忽略的细节透明热区层要放在最底层还是最上层取决于按钮是否独立。如果按钮本身有独立事件按钮必须在热区上层否则点按钮会先触发整卡跳转按钮操作反而做不了。6.6 验证数据恢复到预期修复后连续观察两周数据卡片进入详情的转化率明显回升误触和“点了没反应”的反馈基本消失。这个案例让我意识到原型阶段一张透明的热区图层就能解决的问题如果漏掉会变成上线后一个完整版本的返工前后差了两三周。现在我做任何卡片类组件默认都会把热区范围直接画出来并且要求团队在评审时问一句这张卡哪些位置能点哪些位置点了有反馈哪些位置点了没反应但看起来像能点7. 其他最容易踩的坑五个反面案例与修复方案7.1 坑一信息超载什么都想放典型场景是业务方要求把运营标签、评分、点赞数、作者等级、时间、来源一次全放进卡片。结果卡片上的主信息被挤到只剩一行用户扫一眼只感觉到“乱”。修复原则回到第二章的那三个问题这张卡是什么、对用户有什么用、用户接下来能做什么任何字段都先对号入座对不上就收进详情页。做信息减法很难跟业务方解释但可以用一句话回应卡片只负责让用户决定“要不要点”决定之后的细节留给详情页。7.2 坑二卡片之间缺乏视觉区分度卡片背景色和页面底色太接近、卡片间距又小再没有阴影最后呈现出来像一大块连续文字。用户并不是在做任务时仔细辨认每一组的边界而是扫一眼靠视觉间隔判断。修复方案有两类一是拉开外部间距到12px以上二是加一层非常浅的阴影。二者选其一就好间距和阴影同时加并不会让边界更清晰反而增加视觉噪音。7.3 坑三忽视无障碍对比度辅助信息用浅灰色放白底乍看很清爽但阳光下根本看不清。比如标题是近黑色辅助信息用了接近背景的浅灰对比度可能只有2:1远低于可读标准。修复时不要只调深一点点而是按对比度思路校验正文文字至少4.5:1大字号可以放宽到3:1。原型阶段可以借助取色工具快速验证别等上线后收到一堆“看不清”的反馈。7.4 坑四圆角阴影风格与整体语言冲突有些产品整体是扁平、克制的界面卡片却用了超大圆角和重阴影导致气质割裂。往往是因为卡片单独被美化过头忽略了全局设计语言。修复方式是让卡片参数先从全局设计规范里长出来而不是为单张卡片重新发明风格。如果产品还没有规范那就先定一套最小可行的参数基线再不断迭代而不是每张卡各自为政。7.5 坑五只设计一个状态动态内容破版原型里只画了理想状态上线后出现标题过长、图片缺图、数据为空等问题卡片直接破版。修复方法是每个卡片先准备“最长文本样例”“最少图片样例”“空数据样例”再分别设计容错方案。标题超长时用省略号截断图片加载失败时显示占位图空数据时给出引导文案。动态内容越复杂越要提前定义边界否则返工是必然的。最后说一点个人体会。卡片设计做到后面表面是在调圆角和阴影实际上是在训练一种“信息分层”的判断力。你看到一张卡片时能下意识判断什么东西该大、该重、该凸出来什么东西该小、该浅、该藏起来这种能力比掌握某个工具的快捷键值钱得多。所以别嫌卡片小每一次原型评审都值得把卡片单独拎出来过一遍。