从招聘视角看UI设计作品说明

招聘方查看UI设计作品时，最终画面只是入口。真正需要判断的是设计者面对了什么问题、负责哪一部分、为什么这样处理，以及方案能否落到真实界面中。作品说明如果只有“整体采用简约风格，提升用户体验”，几乎无法区分不同项目，也无法证明具体能力。

项目背景要交代限制，不写长故事

背景部分说明产品或页面用于什么场景、主要使用者是谁、当时最需要解决的问题是什么。没有可靠数据时，不要补写用户数量、增长比例或市场结论。可以写已知限制，例如信息很多、操作频繁、移动端空间有限、需要兼顾后台维护，但这些限制必须来自项目资料或界面本身。

一句有效背景通常能让后面的设计选择有依据。若后文重点是表单效率，背景就应说明填写场景；若重点是视觉升级，应说明原界面的识别或层级问题。无关的行业介绍可以删掉，避免读者看了很久还不知道项目与设计工作的关系。

负责范围必须清楚

团队项目中，个人贡献和团队成果要分开。可以列明参与了信息梳理、线框、视觉设计、交互状态、前端配合或交付规范中的哪些环节。没有参与的部分不需要包装成全流程负责。个人项目则要区分设计判断与技术实现，避免把使用现成能力写成独立研发成果。

工具名称不是负责范围。会使用某款设计软件，只能说明完成工作的手段。招聘方更关心产出了哪些页面、处理了哪些状态、怎样与开发或内容需求对齐。把“熟练使用软件”换成可查看的设计任务，信息会更可信。

设计过程要呈现取舍

过程不等于把每张草图按时间排列。优先展示影响结果的关键节点：信息层级怎样调整，导航为什么重组，核心操作为什么放在当前区域，复杂状态怎样拆分。若有多个方案，可以说明比较维度，而不是简单写“经过多次尝试选择了最佳方案”。

有效的说明应把问题、判断和结果连起来。例如，列表需要频繁比较多项数据，因此保持表头清楚、控制列宽并让筛选状态可见；移动端空间不足，因此把低频信息移入详情，而不是压缩到难以阅读。这样的描述可以被追问，也能让界面截图获得上下文。

不要只展示理想状态

真实产品会遇到空数据、内容过长、加载中、操作失败、权限不足和危险操作确认。作品只放一张数据完整的首页，会让人看不到交互考虑。适合展示的状态不必很多，但应覆盖与项目核心任务直接相关的异常和边界。

组件状态同样重要。按钮是否有禁用与加载状态，输入框错误提示是否靠近问题位置，弹窗能否明确取消，表格在窄屏怎样处理。把这些内容放进局部放大图或状态对照，比重复放几张相似页面更有信息量。

结果描述保持可核实

没有真实统计时，不写“效率提升百分之多少”或“用户满意度显著增加”。可以描述实际交付内容，例如完成了哪些界面、建立了哪些组件规则、形成了怎样的文件结构，或者项目当前处于设计、开发、上线中的哪个阶段。若结果无法公开，明确说明展示范围即可。

复盘也不需要自我表扬。可以指出仍需验证的部分、后续版本可能调整的地方，以及这次工作暴露出的限制。这样的内容不会削弱作品，反而说明设计者知道效果图与真实产品之间还有距离。

让图和文字互相证明

每段说明旁边的图片应承担证据作用。谈信息结构时放结构前后对照，谈组件状态时放状态图，谈响应式时放不同宽度的实际布局。图片下方用简短说明指出观察重点，不让读者自己猜。敏感资料、客户数据和不公开源文件需要遮挡或省略，不能为了作品完整而突破公开边界。

从招聘视角重新读一遍作品说明，重点检查：是否能快速识别项目目标，个人职责是否明确，设计决策是否有依据，图片是否对应文字，结果是否真实。满足这些条件后，作品就不再只是画面集合，而是一份能够说明分析、表达与落地能力的证据。