很多人问我，UI设计评估到底应该怎么做，我通常会反问一句：你评估的是设计稿，还是产品？如果你的答案是“设计稿”，那说明评估还没做到位。做UI评估这件事，看起来是审美问题，本质上是工程问题。这也是我想聊“图工程Graph Engineering”这个玩法的原因——它不是一个绘图工具，也不是做知识图谱，而是一套把UI评估拆成节点、规则、输出物的方法，让评估从“我觉得”变成“我们有数据、有标准、有结论”。

这套方法最适合三类人：一是被评审会折磨的UI/UX设计师，每次被问到“为什么这个按钮这么小”“为什么这个颜色不够活泼”的时候，可以用一套标准把讨论拉回正轨；二是带设计团队的负责人，新人设计师的评估能力参差不齐，有一套可复制的流程就能快速拉齐水平；三是经常和设计打交道的产品经理和前端开发，他们同样需要一套语言来和设计师对话。下面我把整套玩法拆开来讲，包括为什么这么做、具体怎么操作、踩过哪些坑。

1. 为什么UI设计评估是工程问题，不是审美问题

1.1 从“我觉得好看”到“评估图谱”：Graph Engineering的定义

先说一个我见得太多的场景。评审会上，设计师A说“这个配色很高级”，产品经理说“我觉得不够活泼”，前端说“这个实现成本有点高”，三个人各说各话，最后谁嗓门大听谁的。这种评审会开一百次也不会有沉淀，因为所有人都没有共同的语言体系和判断框架。

Graph Engineering的思路，就是把一次UI评估当作遍历一张图来对待。这张图上有四类节点：视觉节点、交互节点、实现节点、体验节点。每个节点都有明确的检查项，比如视觉节点里要查对齐、留白、层级、对比度；交互节点里要查状态、反馈、异常路径。节点与节点之间还有关联关系，视觉层级设计得不好会影响交互路径，交互路径设计得不好会增加实现成本，实现性能差又会反过来拉低体验感受。

为什么用“图”而不是简单的“清单”？因为UI问题很少是孤立存在的。一个卡顿问题不只是性能问题，它会让用户感觉这个产品“很笨”，进而影响对整体质量的判断；一个空态缺失不只是交互缺陷，它会让用户以为功能坏了。把评估对象当成一张互相牵连的图，才能找到问题的根，而不是在一个表面症状上反复纠结。

这个思路和一个常见的工程概念很好类比：就像搭积木之前先画结构图，你得知道哪块积木承重、哪块积木只负责装饰。UI评估也是一样，先画出节点和连线，再逐节点打分，最后看整张图哪里是最薄弱的环节。

1.2 图工程视角下的评估收益：可复制、可量化、可培训

把评估工程化，最大的收益是三个“可”：可复制、可量化、可培训。

先说可复制。我以前带过一个新人设计师，审美底子不错，但一到给界面挑毛病的时候就只能说出“感觉不太对”。后来我把评估节点表给他，让他按图索骥去检查——先查视觉层，再查交互层，再查实现层，最后综合判断体验层。他发现原来“感觉不对”背后是有具体原因的：主按钮和次按钮的视觉权重拉不开、列表留白间距没有遵循栅格系统、空状态页面什么都没写。两周之后，他给出的评估报告已经和做了三年的设计师差不多水平。这就是可复制的力量，不依赖天赋，依赖流程。

再说可量化。有了统一的评分表，版本迭代时就可以对比“上一版首页得分4.2分，这一版首页得分4.6分”，到底改好了没有，数字说话。团队也可以设定及格线，比如“核心页面视觉层不得低于4分”，低于就返工，省掉很多无谓的争论。

可培训则是一个顺带的好处。评估能力拆成检查项之后，培训不再是“你多看看好设计自然就会了”，而是“今天我们专门练色彩对比度的检查方法”“明天练空状态评审清单”。每一项都能单独练、单独考核，进步是可感知的。

2. 四个评估维度：把UI看成一个图结构

2.1 视觉节点：对齐、留白、层级、对比

视觉节点是UI评估最基础的层面，但它不等于“好不好看”。我会把它拆成四类硬指标：对齐、留白、层级、对比度，每一项都有客观标准。

对齐这块，我习惯用8pt栅格来量。Figma里拉两条参考线，看看元素之间的间距是不是4的倍数或者8的倍数，很多新手设计稿一拉辅助线就露馅——有的地方差了2px，有的地方差了7px，视觉上就会有“差一点点”的微妙粗糙感。留白看的是信息密度，一屏里面信息挤到超过用户的视觉承载量，就是一个减分项。层级看字号和字重有没有形成清晰的阶梯，比如标题用20-24号、正文用14-16号、辅助信息用12-13号，并且至少要有三级梯度。对比度我直接用工具测，正文文本和背景的对比度至少要达到WCAG AA标准，也就是4.5:1，大号文字可以放宽到3:1。

这里有个很容易踩的坑：为了追求所谓“高级感”把对比度做得很低，灰色文字配浅色背景，设计稿里看很精致，但一到真机上，用户在阳光下根本看不清。我见过很多“高级感”翻车的案例，颜色审美再在线，如果看不清实质内容，整个视觉节点就是不及格。

2.2 交互节点：状态、反馈、异常路径

交互节点是最容易被评估漏掉的部分，因为静态设计稿只能表达一种状态。我把它拆成三块：状态完整性、反馈及时性、异常路径覆盖度。

状态完整性指的是每个可交互元素都应有常态、悬停态、点击态、加载态、禁用态。列表页面要有正常有数据的样式、无数据的空态、加载中的骨架屏、网络错误时的失败态。一个简单的搜索框，至少要有输入状态、搜索中状态、无结果状态、有结果状态、网络异常状态，五个状态缺一个，遇到对应场景就会露馅。

反馈及时性指操作之后系统要在多快时间内给用户回应。按钮点击之后如果接口要两秒才返回，必须有一个loading反馈，否则用户会认为点击没生效，然后重复点击，造成重复请求。

异常路径这块，我看很多团队在规划阶段做得不错，一到设计还原就丢三落四。比如断网提示、超时重试、输入校验失败提示、用户取消操作的返回路径，这些都是“在图上容易忽略的节点”。做评估的时候，拿一张纸把用户的操作路径画出来，每一条路径的异常分支都列出来，再回到设计稿里找对应的界面，找不到就是缺失。

2.3 实现节点：性能、卡顿、跨端表现

这个维度是我个人的特别关注项，也是“图工程”里“工程”二字的核心。近几年我在各路技术社区里经常看到“ui界面卡顿”“steam的一个关键组件没有响应”“C# task中更新ui”“安卓手机调试打开ui绘制”这类问题，它们本质上都是实现层出了问题。UI评估如果只看视觉和交互，不落到真机表现，就是纸上谈兵。

实现节点要查四件事：首屏渲染速度、交互流畅度、跨端一致性、资源开销。首屏渲染用性能面板看，JS处理时间和网络瀑布图是最直观的证据；交互流畅度看滚动和切换页面时有没有掉帧，用手机录屏观察就能有个初判；跨端一致性要注意不同屏幕尺寸和系统版本下，同一套设计稿渲染出来是不是同一回事；资源开销指图片有没有做压缩、组件有没有过度重绘、有没有在子线程里操作UI导致卡顿。

设计师可能觉得自己不会写代码就看不了实现节点，其实不是。你可以让前端同学给你一份性能报告，或者自己在开发者模式里跑一遍，看几个关键指标（FCP/LCP、CLS、长任务耗时）。你只要知道“设计还原度”这件事需要用数据验证，就已经比90%的设计师专业了。这里我多说一句，如何将figma里面的ui导入到unity中这类跨工具问题，本质上也是在问实现层的工程协作，设计交付物如果不规范，谁接手都难受。

2.4 体验节点：场景、目标、成全度

体验节点是前面三个节点的综合结果，我放在最后评。它回答的问题是：用户能不能在合理时间内，以合理的操作步骤完成核心任务。

评估方法很简单——挑一个典型用户场景，走一遍完整的用户路径。比如本地生活平台的用户想“找一个离我最近、评分最高的火锅店然后预约”，从打开App到完成预约，目标步数应该控制在4步以内，单步耗时不应该超过5秒。如果中间穿插了登录墙、弹窗、过度跳转，或者信息流里没有位置类筛选，那体验节点就要大幅扣分。

这里有一个容易混淆的概念：要素齐全不等于信息清晰。一个页面把品牌信息、商品列表、推荐位、活动入口全部堆上，看起来什么都有，但用户找不到自己要的东西，体验分反而很低。体验节点的核心永远只有一个——用最短的路径成全用户的目标，其他一切都要让位。

3. 实操步骤：搭建你自己的UI评估工作流

3.1 准备阶段：收集材料、拆解页面清单

一套规范的评估流程，准备工作大约占三成时间，但很多人在这一步偷懒，后面就得返工。

要收集的材料一共四类：设计稿源文件（最好是带标注或者带自动布局的版本，方便量间距）、可点击的高保真原型（用来走交互路径）、线上页面的录屏（最好是真机录屏，能看到真实帧率表现）、性能面板截图（Chrome Lighthouse或开发者模式的Performance面板）。

然后是拆解页面清单。具体操作是把每个页面按功能模块拆块，我常用四块法：首屏区（用户第一眼看到什么）、内容区（核心信息流）、操作区（按钮、输入框、导航）、反馈区（弹窗、提示、空态）。以首页为例，首屏区是搜索框和Banner，内容区是金刚区和信息流，操作区是底部Tab和悬浮按钮，反馈区是各种Toast和弹窗。每一块对应一张检查清单，评估的时候逐块过，不会漏。

拆完之后，做一张“节点地图”，横轴是页面模块，纵轴是视觉、交互、实现、体验四类节点，一格一格打钩。这张地图本身就是项目资产，之后每次版本迭代都可以复用。

3.2 打分阶段：评估记录表与量化规则

打分阶段我使用5分制，每个检查项单独打分，最后加权汇总。下面这张表是我一直在用的简化版，可以直接复制到团队文档里用：

评分有几个规则要注意。第一，不要打3.5这种中间分，评估需要有倾向性，5分制里3分意味着“要改进”，4分意味着“可用”，2分意味着“必须改”，中间分会稀释结论。第二，同一个问题只记一次，不要因为它在三张截图里出现了三次就重复扣分，但可以在问题描述里标注影响范围。第三，定级看用户影响，不看你个人的主观感受。一个颜色你不喜欢但用户能看懂，这不是问题；一个按钮小到用户找不到，这才是问题。

3.3 输出阶段：评估报告与问题分级

评估的最终产物不是评分表，而是一份能推动决策的报告。我的报告标准结构是四段：摘要、问题清单、证据对比、整改建议。

摘要部分用三行话讲清楚整体结论——“首页整体质量中等偏上，视觉层得分4.2，交互层失分严重，主要原因是状态缺失；实现层存在首屏加载缓慢风险，建议优先处理两项P0问题”。问题清单按P0/P1/P2分级，P0是阻断用户完成核心任务的，必须立刻改；P1是明显影响体验的，应该在本迭代改；P2是优化项，可以排期打磨。证据对比要贴截图，左边是设计稿，右边是真机实拍，标注差异位置。整改建议要落到具体动作，不是“提高性能”这种空话，而是“图片改为懒加载并压缩到720px宽”“搜索无结果页面补一句文案加一个返回按钮”。

报告写完不是结束，一定要约定复评节点。改完之后再评一次同分，才能确认问题真的解决了。这个闭环是评估工作流里最容易被跳过、也是最重要的环节——没有复评的评估等于没评估。

4. 实战复盘：一个本地生活平台首页的评估全过程

4.1 页面拆解与节点标注

拿一个我最近做的本地生活平台项目来当案例。项目需要评估登录页和首页两个核心页面，我把它们拆成了六个模块：登录入口区、Banner区、金刚区、内容信息流、底部Tab栏、搜索反馈区。六个模块对应四类节点，一共标注了24个检查项。

登录页重点查体验节点和实现节点，因为登录是用户第一次接触产品的门槛，任何阻碍都会造成流失。首页重点查视觉节点和交互节点，因为信息密度高，最容易出现层级混乱和状态缺失。准备工作花了大约半天，主要时间花在导图片、录屏、跑性能面板上。这里有个实操细节，录屏最好用中低端安卓机而不是旗舰机，性能问题在低端机上更容易暴露，旗舰机上反而不明显。

4.2 逐节点评估与问题发现

评估过程中我发现的问题挺典型，挑四个有代表性的说。

第一个是视觉层的按钮层级问题。登录页有两个主要入口，设计稿把“手机号登录”和“一键体验”做成了同样大小同样颜色的按钮，用户在登录页犹豫了三四秒才做决定。用一个简单的注意力热力测试就能发现，两个按钮视觉权重相同，系统分不出主次。建议是把体验入口弱化成文字链或者次按钮。

第二个是交互层的空态缺失。首页搜索框输入“奶茶”之后无结果，直接白屏。用户在这里的反应是“是不是坏掉了”，而不是“没搜到”。事实上只要补一句“附近暂时没有奶茶店，换个词试试”加一个返回按钮，体验就能及格。

第三个是实现层的首屏加载问题。性能面板显示，首页首屏图片全部走原图，三张Banner加起来3.6MB，在4G网络下首屏耗时超过4秒。图片压缩到720px宽、改用懒加载之后，首屏资源降到1.1MB，耗时降到1.8秒。这类问题如果在设计稿阶段要求“出口图按实际尺寸导出、不超过200KB”，后面能少很多事情。

第四个是体验层的登录墙问题。用户浏览门店列表的时候，点了“查看完整菜单”就弹登录框，用户一旦犹豫就会退出。后来我们把“查看菜单”改为游客可看、登录仅用于下单，核心任务的完成率提升了约30%。这个改动不涉及视觉和交互的颠覆，只是重新调整了体验节点的路径。

4.3 问题定级与整改建议

四个问题的定级和处理方式整理一下：

定级的原则是：有没有阻断核心任务执行。白屏和首屏过慢直接阻断用户，“搜索”和“浏览首页”本来就是核心任务，所以是P0；按钮层级和登录权限不影响核心任务完成，只是影响效率和转化，所以是P1。这样排完优先级，开发排期就有了依据，不会出现设计师和开发为了“先改颜色还是先修性能”吵半天的情况。

5. 常见问题与排查技巧实录

5.1 评估时最常见的5个坑

这几年做评估做下来，我发现有几个坑几乎是固定出现的，提前知道能少踩不少。

第一个坑是只评视觉不评实现。设计师评估完给个高分，结果开发做出来卡成PPT，用户根本不在乎你配色多高级。避免方法就是强制自己在评估流程里加入“真机验证”环节，哪怕只是拿手机录一段屏。

第二个坑是拿主观偏好当客观标准。有人觉得按钮就应该是方的，看到圆角的就直接扣分，这不对。评估标准必须建立在“用户能不能完成任务”“间距是否一致”“对比度是否达标”这类可验证的维度上，而不是个人品味。

第三个坑是忘记异常状态。我知道很多人评审只看“理想状态下的页面”，因为设计稿就是那个样子。但用户的使用场景里有一半以上是异常状态：断网、空数据、加载慢、接口报错。解决办法很简单，建一个“状态检查清单”，每次评估的时候逐项对照。

第四个坑是把“要素齐全”当成“信息清晰”。菜市场什么菜都有，但用户需要的是“想买的菜能直接看到”，页面堆功能不等于页面好用。评估的时候多问一句“核心任务是什么，这个页面帮用户完成了吗”，比数有多少个模块有用得多。

第五个坑是评估者不懂实现成本。总有一些设计师会说出“这个阴影效果再浓一点”“这个动画要弹跳两次”之类的话，不关心前端的实现难度和性能开销。好的评估应该主动关心“这个效果值不值得这个成本”，如果一个动效只是为了炫技却拖慢了首屏，那就应该减分。

5.2 高性能UI的排查清单

针对实现节点，我整理了一个高频排查清单，照着过一遍就能定位大部分性能问题：

• 首屏图片体积是否超了200KB，有没有做压缩和懒加载
• 首屏渲染是否被大量同步JS阻塞，长任务耗时是否超过200ms
• 页面滚动是否有明显掉帧，列表是否做了虚拟化
• 有没有在子线程里操作UI控件，会导致界面无响应
• 注意跨框架环境，比如Electron或Unity嵌入WebUI时的组件通信和渲染资源问题
• 组件库使用是否合理，有没有引入了一大套UI框架却只用其中一个按钮，导致打包体积虚高
• 网络请求是否存在串行请求，能不能并行或预加载
• 真机上是否出现过系统级UI无响应或卡顿的提示，这通常意味着主线程负荷过重

我不建议设计师自己动手去改性能代码，但一定得会用性能面板看数据，并且能把数据转化成设计决策。比如性能面板里显示首屏被某个大图卡住，你可以给出“这张图裁掉或者后移”的设计建议，这就不是开发驱动设计，而是设计驱动开发了。

5.3 评估技能怎么持续训练

最后聊一下怎么持续提升评估能力。UI评估和任何技能一样，不练就会退化。我自己的训练方法是每周固定拆一个App，用这套评估流程走一遍，记评估笔记。也不一定非要拆竞品，拆自己家的产品更有价值，因为你有真实的数据反馈可以对照。

拆解的产出物不是“这个App好不好用”这种结论，而是一份有评分、有依据、有截图标注的评估记录。一个季度下来，就有十几份案例了，遇到类似设计问题直接翻案例库，比现想快得多。

另外一个很有效的训练方式是交叉评审。两个人或两组人评估同一张设计稿，然后比对打分，对差距超过两分的项目展开讨论。讨论过程通常非常有意思，你会发现“我觉得这个按钮很醒目”和“我觉得它太抢戏了”背后，双方对页面层级判断的逻辑是完全不同的。这种讨论不管最后谁说服谁，双方的评估标准都会更完善，团队的整体水平也被拉起来了。

我个人经验里还有一个很小的技巧：把评估记录表放在团队随时能看到的地方，每次评审会之前先让大家过一遍检查项。坚持做了几次之后，你会发现会议时间至少缩短一半，因为大家开始在统一的标准上对话了。这就是把评估工程化的最大价值——它让每一个参与者都变成了更有判断力的设计决策者。