Question 1

挑一个作品集案例讲讲，你的设计决策依据是什么？

Accepted Answer

我讲一个把注册转化率作为目标的改版。问题与目标：注册流程六步、完成率偏低，目标是提升完成率但不能降低后续留存质量。约束有三个：合规要求的信息不能删、后端接口短期不能改、开发资源只有两周。我先看漏斗数据定位流失最大的两步，再做了六个用户访谈确认原因——不是步数多，而是第三步要求填写用途时用户不理解为什么要填。方案取舍上我做了两版：A 版把六步压成三步、B 版保持步数但把「为什么需要」讲清楚并把非必填项后置。可用性测试里 A 版单页信息过载、B 版完成率更高，所以我选了 B，这也是被我否掉 A 的原因。上线后完成率提升可观且后续七日留存没有下降——我特意跟踪了后者，因为单纯压缩流程很容易换来低质量注册。

Question 2

产品给你一句「让这个页面更好看」，你怎么推进？

Accepted Answer

我不会直接开 Figma，而是先问三个问题：这个页面现在哪个指标不满意？用户抱怨的具体是什么？有没有必须保留的东西？「更好看」通常是症状不是问题，追问后往往落到三类：信息层级不清（用户找不到主操作）、信息过载（什么都想强调）、或视觉与品牌不一致。定位清楚后我会给出可衡量的目标，比如「主操作点击率」或「首屏理解成本」，再出两版方案：一版保守（只调层级、间距和对比度，一天内可上线），一版彻底（重排信息架构，需要两周和后端配合），把成本和预期收益一起摆出来让业务方选。这样做的好处是设计从审美讨论变成决策讨论——我用这个方法把「好看」需求的返工率降了很多，因为验收标准在动手前就对齐了。

Question 3

设计稿被开发说「实现不了」或还原度打折，你怎么处理？

Accepted Answer

我先区分性质：如果是平台能力限制那确实要改设计；如果是「成本高」，那就是排期问题，可以谈分期实现。谈的时候我不会逐个像素争，而是提前把设计意图分级：交互逻辑和可用性是底线不能砍，比如错误提示必须就近显示、键盘可达；动效和精细视觉是加分项，可以先上简版后续迭代。这样开发知道哪里能省。更根本的做法是提前介入——我会在方案阶段就拉前端一起看，问清组件库现状和实现成本，很多不可实现的问题在画之前就避免了。交付时我给的是设计说明加状态清单（空态、加载、错误、极值、响应式断点），而不是只有一张理想态视觉稿，这是还原度打折最常见的原因：不是开发不认真，而是我没交清楚。

Question 4

你怎么用数据驱动设计？A/B 测试结果和你的判断冲突怎么办？

Accepted Answer

我的分工是：定量数据告诉我哪里有问题、改动有没有效果；定性研究告诉我为什么，两者缺一个都会瞎。结果和我判断冲突时，我的顺序是先认真怀疑自己，再检查实验本身：样本量和显著性够不够、有没有新奇效应、细分人群是否结论相反（新用户和老用户经常反向）、以及最关键的一点——被优化的指标是否代表长期价值。我遇到过一次：一个更强的引导弹窗让转化短期涨了，但两周后留存和投诉率都变差了，我拿这组数据说服团队回滚。所以我的立场是尊重数据但不迷信单一短期指标，同时我也接受「我审美上更喜欢的版本输了」——这种情况下我改的是设计，不是数据。

Question 5

设计系统怎么建、怎么让团队真的用起来？

Accepted Answer

我不会从「设计一套完整体系」开始，而是先盘点现有界面，把真实重复出现的模式抽出来——通常颜色、间距、按钮、表单、反馈提示这五类就能覆盖大部分复用。原则上我优先做 token（颜色、间距、字号、圆角）而不是先做复杂组件，因为 token 收敛最快且和代码变量一一对应。关键是设计侧与代码侧必须同步，我坚持组件名、变体名、token 名三者一致，否则很快会出现「设计稿里有但代码里没有」的腐化。让团队真用起来靠三件事：一是降低使用成本，Figma 库直接可拖、代码侧有对应组件，比查规范文档现实得多；二是治理机制，新组件要走轻量评审避免重复造件，同时留一条「先做特例、稳定后收编」的口子，否则设计师会绕开系统；三是持续维护有明确 owner。我参与建设的一次结果是新页面搭建时间明显缩短、跨端视觉一致性问题大幅减少。

Question 6

可访问性你会怎么落实？哪些是必须做的？

Accepted Answer

我把可访问性当基础质量而不是加分项，因为它同时受益于普通用户（强光下的手机屏、临时单手操作）。我的底线清单有五条：正文对比度至少 4.5:1、大字与图形 3:1；不用颜色单独传达状态，必须配图标或文字；所有交互元素键盘可达且焦点可见，不允许 outline: none 不给替代；表单标签与输入框显式关联、错误提示就近且用文字说明怎么改；图片有有意义的替代文本，装饰性图片标记为可忽略。暗色模式我会单独核对一遍对比度，因为设计稿在亮色下达标、暗色下常常不达标。检测上我不只靠肉眼：自动化工具跑一遍拿硬指标，再手动只用键盘走一遍主流程、开读屏听一遍关键页面——自动化能查出的大概只是一部分，焦点顺序混乱这类问题只有实测才发现。

Question 7

B 端复杂流程（比如后台配置、审批）怎么设计？和 C 端有什么不同？

Accepted Answer

最大的差异是目标：C 端常常要降低首次使用门槛、制造愉悦感；B 端用户是被工作驱动的重复使用者，追求效率、可预期和不出错，花哨反而是负担。具体做法上我有几条：一是按角色和熟练度分层——新手要引导和默认值，专家要键盘操作、批量处理和保存的筛选视图，两者不能只做一套；二是高风险操作必须可预览、可撤销、有影响范围说明，比如改一条审批规则要先告诉用户「会影响现有 37 个流程」；三是信息密度可以比 C 端高，专业用户宁愿一屏看全也不愿翻页，但要靠分组、对齐和留白维持可读，而不是压缩间距；四是状态和错误设计比视觉更重要，复杂流程里用户最怕的是不知道自己卡在哪一步、为什么被拒。我做后台设计时会专门画状态流转图和权限矩阵，这两张图比视觉稿更能暴露设计漏洞。

Question 8

怎么证明你的设计有价值？设计成果怎么量化？

Accepted Answer

我分三层量化。业务指标是最硬的：转化率、完成率、客单价，有 A/B 条件时直接归因；但我会诚实说明设计只是变量之一，同期文案、算法、渠道都可能在动，我只声称设计可归因的那部分。体验指标补充业务指标看不到的部分：任务完成时间、错误率、可用性测试的成功率、NPS 与差评关键词分布，我特别看客服工单里的「找不到」「不知道怎么」类问题数量，这类数据很直接。效率指标常被忽略但对内部很有说服力：设计系统上线后新页面搭建时间、设计到开发的返工次数、还原度问题数。没有 A/B 条件的场景（比如 B 端后台）我用前后对比加可用性测试的定量结果替代。我不会说「改版后更好看了所以更好」——不能被衡量的部分我如实标为主观判断，这反而让能量化的部分更可信。

UI/UX 设计师高频面试题：8 道必考题与作答要点