把一篇UI案例里的项目名称和Logo遮住，如果剩下的只有几十张漂亮截图，它很难证明设计能力。审美可以从画面看出来，但业务理解、问题判断、流程取舍、复杂状态和推动落地，需要通过叙事与证据才能被看见。案例不是项目相册，而是一份“为什么这样做”的说明。
01 一篇案例只需要证明一个核心能力
不要试图把半年项目的每个会议、每张流程图和每次修改都塞进去。先确定读者看完后应该记住什么：你擅长复杂B端、增长转化、设计系统、用户研究，还是从0到1产品。围绕一个核心能力选取材料，案例会更清楚。
02 推荐使用这八段结构
| 段落 | 必须回答的问题 | 可使用的证据 |
|---|---|---|
| 1. 项目背景 | 产品处于什么阶段，为什么启动项目 | 产品截图、业务背景、时间线 |
| 2. 范围与职责 | 团队有哪些人，你具体负责什么 | 角色表、交付范围、合作节点 |
| 3. 核心问题 | 最值得解决的问题是什么 | 用户反馈、数据、流程或业务限制 |
| 4. 判断依据 | 为什么认为这是问题来源 | 访谈、行为数据、竞品与专家输入 |
| 5. 方案与取舍 | 比较过哪些方向，为什么放弃某些方案 | 草图、原型、决策表、约束 |
| 6. 复杂落地 | 异常、权限、长数据和响应式如何处理 | 状态矩阵、组件、开发走查 |
| 7. 结果与边界 | 上线了什么，改善了什么，哪些未验证 | 指标、任务测试、上线范围 |
| 8. 复盘 | 下次会保留或改变什么 | 后续计划与方法总结 |
03 先写清个人职责，别把团队成果全部算在自己身上
项目可能由产品、研究、UI、内容、开发和运营共同完成。案例应明确你负责的部分、参与程度和最终决策权。诚实说明协作不会削弱能力，反而能证明你知道设计如何在真实团队中落地。
04 不要从“我们进行了用户研究”开始
研究方法本身不是成果。读者更关心：你为了回答什么问题选择了哪些样本，得到了什么证据，这些证据改变了哪项设计。没有影响决策的便利贴、访谈照片和竞品截图，可以删掉。
案例里的每张过程图，都应该能回答一句话：它改变了哪个决定？
05 展示一个被放弃的方案，比展示十张完美终稿更有价值
真实项目一定有冲突：效率与安全、品牌与可读性、功能完整与上线时间、业务目标与用户负担。把候选方案、限制条件和放弃理由写出来，读者才能看到判断能力。若案例从问题到最终稿一路顺滑，反而像事后编写。
06 图片要承担证据，而不是填满版面
| 图片类型 | 它应该证明什么 | 常见问题 |
|---|---|---|
| 旧版与现状 | 问题确实存在，且影响任务 | 只做视觉对比，不说明业务差异 |
| 流程与信息架构 | 方案改变了路径和内容关系 | 图很大，但看不清关键节点 |
| 原型与测试 | 某个假设被验证或推翻 | 放出全部原型，没有结论 |
| 高保真页面 | 视觉与交互如何承载策略 | 只展示理想成功状态 |
| 状态与权限 | 设计考虑了真实复杂度 | 忽略空、错、加载、长数据和权限 |
| 开发与上线 | 方案被实现并进入真实环境 | 效果图冒充上线结果 |
07 没有商业增长数字，也能写出可信结果
并不是每个项目都能获得转化率、收入或留存数据。可以写清已上线范围、任务完成时间、错误减少、客服问题变化、设计系统覆盖、开发返工和用户反馈。无法核验的“提升30%”宁可不写。若结果尚未验证，也应直接说明。
08 保密项目可以匿名，但不能因此失去具体性
可以隐藏客户名称、金额和敏感数据，同时保留行业、产品阶段、角色、流程复杂度和关键约束。把所有细节都改成“某平台”“某用户”，案例会失去可信度。匿名不等于抽象。
09 一个可直接使用的案例写作模板
- 一句话背景：我们在什么阶段，为哪类用户，解决什么业务问题。
- 我的职责：我负责哪些决策、交付物和协作环节。
- 问题证据：哪些事实让团队确认问题值得解决。
- 关键取舍：至少展示一个被放弃方向及原因。
- 方案落地：用流程、页面、状态和组件说明完整度。
- 结果边界：哪些结果已验证，哪些仍是后续假设。
- 复盘：如果重新开始，最先调整什么。
10 案例第一页先交代三件事
读者不会先花十分钟理解项目背景。开头应在一个屏幕内说明：这是一个什么产品、你具体负责什么、最难的约束或结果是什么。随后再展开过程。把“负责整个项目”改成可核验的范围，例如“负责信息架构、核心流程、视觉系统和两轮开发走查”；把“提升体验”改成具体任务，例如“将三类角色的审批入口统一到一个工作台”。
| 开头信息 | 弱表达 | 更有证据的表达 |
|---|---|---|
| 项目类型 | 某大型平台改版 | 面向区域销售与财务审核的B端订单系统 |
| 个人职责 | 负责全部UI/UX | 主导流程梳理、原型、视觉系统与开发走查 |
| 核心难点 | 需求复杂、时间紧 | 三类权限、七种订单状态，六周内完成首期上线 |
| 结果边界 | 项目获得一致好评 | 首期上线12个核心页面，商业指标尚未完整验证 |
11 发布前做一次“删图测试”
暂时隐藏所有大图，只读标题、正文和表格。若案例仍能让人理解问题、判断和结果，说明叙事成立；若只剩“我们进行了调研、做了原型、最终获得好评”，就需要重新写。
常见问题
UI设计案例应该写多长？
按问题复杂度决定。简单视觉改版可以短，复杂B端或0到1产品需要更多证据。重点不是字数，而是读者能否理解职责、判断和落地。
案例必须放完整设计流程吗？
不需要。只保留影响决策的过程。固定套用“调研—画像—旅程图—原型—UI”会让案例像模板，也可能与真实项目不符。
没有上线的概念项目能当案例吗？
可以，但必须标明是概念项目，并说明假设、限制和验证程度。不要把高保真概念图写成真实商业成果。
案例里能使用客户评价吗？
可以使用经过授权、身份和语境真实的评价。不要编造匿名五星好评，也不要让评价替代可核验的项目过程与结果。
相关服务与进一步咨询
链接复制成功
